Update TRG proposal and approval process #871
Conversation
There was a problem hiding this comment.
Thanks to @SebastianBezold for a clearer picture why TRG´s and the change process is so important for our community.
Just added some suggestions for rephrasing the text and a little question if we should also provide an explaination why a trg proposal was rejected or dropped.
SebastianBezold
force-pushed
the
add-trg-approval-process-description
branch
from
d06e29b to
7d6ff6d
Compare
There was a problem hiding this comment.
Thank you very much @SebastianBezold , looks fine for me now...
| ### Update existing TRG | ||
| 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!
Given both your feedback, I'm not sure if the changes I made are good enough, or if we should elaborate on that. There is also a short bullet point with a guiding question in the "Review" section, that is already mentioning the "mandatory from" date
Would it be a lot of effort to comply with the TRG? Consider introducing a "mandatory from" date.
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.
| - Announce the new TRG on the developer mailinglist | ||
| - When the TRG mandatory date is due, remove the hint and move it from PRERELEASE to normal (as all other TRGs) | ||
| - 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.
I was not yet sure, how to state that in our process.
You could say, that dropping is actually the right thing to do, since there does not seem to be a lot of interest across the committer group to align on such a topic.
We could also think about "reminders", that it is a committer duty to vote on project rules, just like it is for committer elections. Just not sure, what we should do, if colleagues are constantly skipping the vote.
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.
Taking this to the committer office hour
Co-authored-by: Tomasz Barwicki <[email protected]>
| - Announce the new TRG on the developer mailinglist | ||
| - When the TRG mandatory date is due, remove the hint and move it from PRERELEASE to normal (as all other TRGs) | ||
| - 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.
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
|
@eclipse-tractusx/automotive-tractusx-committers what about this PR? Still valid? It is quiet old |
There was a problem hiding this comment.
Exactly what @evegufy said. I'm happy to not have the draft section anymore.
| 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. |
There was a problem hiding this comment.
| section. In case a new TRG does not fit do an existing section, a new section can be proposed or asked for by reviewers. | |
| section. In case a new TRG does not fit into an existing section, a new section can be proposed or asked for by reviewers. |
|
|
||
| Create a new PR which already deprecates the TRG without a draft state. Deprecation means updating the post history and marking as much as possible with strikethrough markdown. | ||
| 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.
| deprecating TRGs is done by simply deleting it and mention the deleting in [Changelog & Drafts](release/trg-0/trg-0.md). | |
| deprecating TRGs is done by simply deleting them and mentioning the deletion in [Changelog & Drafts](release/trg-0/trg-0.md). |
|
@stephanbcbauer you can just go a head committing your suggestions. Sebastian mentioned that we can make changes when he left a couple of months ago. |
Description
This PR is a first approach to incorporate committer meeting feedback to our TRG proposal and approval process.
Up until now, it wasn't really transparent, under which circumstances a TRG proposal is accepted.
This update to the process introduces a "mandatory approval count" and a "minimum review period". Other information related to the process is also improved.
Committer meeting discussions: https://github.com/orgs/eclipse-tractusx/projects/61/views/6?pane=issue&itemId=60828572
FYI: @eclipse-tractusx/automotive-tractusx-committers
Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review: