Update TRG proposal and approval process #871
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -1,43 +1,66 @@ | ||||||
| # Release Guidelines | ||||||
|
|
||||||
| Welcome to Eclipse Tractus-X Release Guidelines, known as TRGs. With Release Guidelines, we are defining quality | ||||||
| criteria for our repositories, products and artifacts in general. TRGs are numbered and grouped into sections, to | ||||||
| provide an easy-to-use overview. The git history of the TRGs can be used to browse changes made throughout the project | ||||||
| history. You can also check the [TRG Changelog](release/trg-0) to get a better view on the history of | ||||||
| new/changed/deprecated TRGs. | ||||||
|
|
||||||
| ## Process | ||||||
|
|
||||||
| The process of introducing or altering a TRG is straight-forward. It consists of the following phases and events: | ||||||
|
|
||||||
| 1. A proposal is created | ||||||
| 2. The proposal is improved by providing feedback | ||||||
| 3. The committer group is deciding to accept or deny the proposed changes | ||||||
|
|
||||||
| More details in the following sections | ||||||
|
|
||||||
| ### Proposal | ||||||
|
|
||||||
| A new TRG, or a change to an existing one is proposed by raising a PR. This can be done by any contributor or committer. | ||||||
| The PR is raised against the `main` branch | ||||||
| of [eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/). | ||||||
| Changes can be done by directly updating the existing Markdown files. New TRGs should already be put to a matching | ||||||
| section. In case a new TRG does not fit do an existing section, a new section can be proposed or asked for by reviewers. | ||||||
|
|
||||||
| As soon as a proposal is ready for committer review, it has to be announced | ||||||
| via [Tractus-X mailing list](https://accounts.eclipse.org/mailing-list/tractusx-dev). Additionally, the committer group | ||||||
| is mentioned directly on the PR by tagging `@eclipse-tractusx/automotive-tractusx-committers`. | ||||||
|
|
||||||
| ### Review | ||||||
|
|
||||||
| Feedback to announced proposals is welcome by everybody. It should be provided by using the review functionality of | ||||||
| GitHub. Reviews are especially needed from Tractus-X committers, since they are the ones who are accepting or dropping | ||||||
| proposals. | ||||||
|
|
||||||
| During review, the following things could be paid special attention to: | ||||||
|
|
||||||
| - Does the TRG focus on a single topic? If not, consider splitting to multiple TRGs | ||||||
| - Is it clear, how to comply with the TRG? Avoid room for interpretation, where possible | ||||||
| - Would it be a lot of effort to comply with the TRG? Consider introducing a "mandatory from" date | ||||||
|
|
||||||
| ### Accept / Drop | ||||||
|
|
||||||
| A new TRG, or changes to an existing TRG are __accepted__, if all the following is true: | ||||||
|
|
||||||
| - at least 7 committers did approve the change | ||||||
| - the proposal PR is open for at least 2 weeks, to give everyone a fair amount of time to provide feedback or request | ||||||
|
There was a problem hiding this comment. The case which interests me is when the TRG PR doesn't get much attention from committers and doesn't get enouch approvals within 2 weeks, as per listed requirements does that get dropped? I think it might be a useful to keep traction, reminder of open TRG PRs in the Committers meeting. There was a problem hiding this comment. Yes that is definitely an interesting case and unfortunately the most common one, at least on the recent TRGs. There was a problem hiding this comment. As shortly discussed in our sync today: I think it should be feasable for the project leads to still allow a TRG if there is no Veto. It should also be later on the responsible of the project lead to inform/warn committers that they have a duty and remove them later on if they don't react/act on TRGs or other things in the community. Nonetheless if there is no real veto a TRG with small activty should be allowed as there are often enough approaches which need to be aligned There was a problem hiding this comment. I would like to hear more opinions on that. From my point of view, the rules are still made and discussed by the committer group. Low activity should result in a reminder to the committer group of their duties instead of "just waving through" as PL. |
||||||
| changes | ||||||
| - All requested changes are addressed. Not necessarily every requested change has to be implemented, if there is a | ||||||
| consensus in the committer round, that the original proposal is good enough. | ||||||
|
|
||||||
| If the mentioned criteria is met, the PR is merged and the release guideline is mandatory for all Tractus-X products and | ||||||
| repositories. There might be cases, where complying with a new or changed release guideline takes considerable effort, | ||||||
| so that proper planning should be done. In these cases, a "mandatory from" date should be discussed in the review phase | ||||||
|
There was a problem hiding this comment. Actually I'd simplify that step and put "mandatory from" for each new TRG with a default period (1 month?) , that would save time for discussing what "considerable effort" means in specific proposed implementation, and allow time incorporating into development planning. Also would be a kind of highlight that it's something new.. There was a problem hiding this comment. I don't agree with a default period of 1 month. In such cases, it needs to be possible to plan and prioritize the implementation of the TRG in the next open planning (open plannings occur 4 time/year). If a product increment is already planned out, it's simply not possible to take up such additional effort. Therefore, the TRG needs to be brought to the next open planning, to be implemented then in the next product increment. There was a problem hiding this comment. Hi @evegufy and @tomaszbarwicki!
There was a problem hiding this comment. Hi @SebastianBezold I think if it remains at it's currently is written, it's fine. There was a problem hiding this comment. @evegufy my proposal was to set a default period for each new TRG, 1 month was just example, can be 3 months as well if that helps with open planning schedule. The point was to cut sometimes unneccessary long lasting discussions on the complexity. |
||||||
| and the actual date highlighted at the beginning of the TRG. | ||||||
|
|
||||||
| A release guideline proposal is __dropped__, if there are too many changes requested and a consensus cannot be found | ||||||
| across the committer group on how to alter the proposal to an acceptable state. Dropped, or rejected release guideline | ||||||
| proposals are documented by listing the PR and a short description of the proposed change | ||||||
| in [Changelog & Drafts](release/trg-0/trg-0.md). | ||||||
|
|
||||||
| ### Deprecating TRGs | ||||||
|
|
||||||
| Proposals to deprecate existing TRGs are also introduced via PR. To keep the list of TRGs small and easy to read, | ||||||
| deprecating TRGs is done by simply deleting it and mention the deleting in [Changelog & Drafts](release/trg-0/trg-0.md). | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.