Introduce ADRs for the project #365
Conversation
Added a process description, an ADR template and a first draft of an ADR which describes how we should handle exceptions with regard to Java interoperability.
andregasser
added
documentation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #365 +/- ##
=========================================
Coverage 48.00% 48.00%
Complexity 501 501
=========================================
Files 137 137
Lines 3704 3704
Branches 242 242
=========================================
Hits 1778 1778
Misses 1734 1734
Partials 192 192 |
| # ADR Process | ||
|
|
||
| ## Overview | ||
|
|
||
| In the BigBone project, we use ADRs to log the outcome of design and decision making activities. Hence, we can view them |
There was a problem hiding this comment.
We should write down in full what “ADR” means at least once here at the start of the document. At least I didn’t know that abbreviation.
There was a problem hiding this comment.
Good point. I had it written out somewhere but it seems it did not make it into this PR. Will fix it. 👍
|
|
||
| ## Status | ||
|
|
||
| The status of this ADR. It can be either Proposed, Accepted, Rejected, Deprecated, Superseded. |
There was a problem hiding this comment.
I assume that any existing ADR could be deprecated/superseded by the outcome of a new discussion thread but I think it is still worth explaining Deprecated and Superseded including the differences between these two, or rather the process that leads to these statuses, somewhere.
If we propose changes via a separate discussion thread and an ADR is only written after that discussion has ended, we should never have an ADR in the status Proposed.
Similarly, what is the purpose of documenting something as Rejected? If a discussion leads to something else than the originally suggested design, can't we just record this as a different design being Accepted?
Explanations for these terms should probably be added to adr-process.md as necessary.
| ## Context | ||
|
|
||
| What is the issue that we're seeing that is motivating this decision or change? | ||
|
|
There was a problem hiding this comment.
"Context" should probably include a link to the discussion thread that led to the ADR.
Description
With this PR, I would like to introduce ADRs for this project, as discussed this morning on Slack. Based on the discussion outcome I have created the following:
Happy to get some feedback on this. Let me know what you think.
Type of Change
Breaking Changes
None.
How Has This Been Tested?
Not tested.
Mandatory Checklist
gradle checkand there were no errors reportedOptional Things To Check
The items below are some more things to check before asking other people to review your code.
*Methodsclasses: Did you also reference it in theMastodonClientmain class?/docsfolder (e.g. API Coverage page)?