A Protocol for creating ADRs #3243
Replies: 5 comments 7 replies
-
|
Suggested changes I already have for this:
|
Beta Was this translation helpful? Give feedback.
-
|
Comments from technical meeting:
|
Beta Was this translation helpful? Give feedback.
-
|
From the implementation section, I assume we are thinking of ADRs as very hard inviolate rules? If so I would argue we need to keep those to a manageable number. In this case the question of being overwhelmed by suggested ADRs I would think is moot? Also is there space/room for a "highly encouraged" category? |
Beta Was this translation helpful? Give feedback.
-
|
As discussed at the biweekly meeting today, this proposal is moving to the next step and will be sent out to the developers list for further comment. The original body of work will remain with the following changes, based on feedback here and at the meeting:
|
Beta Was this translation helpful? Give feedback.
-
|
This has been approved and is now active as https://github.com/orgs/SasView/discussions/3357 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Using the easyscience ADR protocol as a basis, this suggestion outlines how SasView should propose, review, and implement new Architecture Design Records (ADR). This was discussed at todays technical meeting.
1. Suggestion Phase
ADR Suggestionscategory.Qt GUI element naming convention. The title may includeADR Suggestionif desired, but is not required.2. Accepted ADR
3. Rejected ADR
4. Tracking Implementation
Cross Package Issueto each related issues and, once all are created, edit the issue descriptions to include links to all related issues.5. Revision Process
Revision:and follow it with the ADR title.Beta Was this translation helpful? Give feedback.
All reactions