anuket-specifications
anuket-specifications copied to clipboard
anuket-project
[GOV]: Update CONTRIBUTING file
Based on the TSC discussion on 2022.09.13 (https://wiki.anuket.io/display/HOME/2022-09-13+TSC++Agenda+and+Minutes)
Adding exceptions for the PR merger rules for trivial and compilation related changes.
I would rather make clear that it's only about recommendations/best practices and that it's up to the project to decide its own processes depending its skills, its contributions, its management and its best way of working. We could only mandate the PR process.
My 2 cents: doing algorithm is endless here.
I would rather discourage any logic which asks for false reviews to please the process. I frankly prefer 1 or 2 true reviews then 3 or more false ones.
Far more important, it must be agreed here or elsewhere that nobody is allowed to judge the process in the stream if he or she is not contributing to the stream. That's a far more bigger issue than the reviewer count!
TSC is in charge to solve issues and not to create new ones when there is any.
At the moment these are not only recommendations. It is a possible way forward to introduce sub-project specific contribution rules, but it should be a decision made collectively not only by specific sub-projects or individuals.
To be honest I do not agree that one should not provide feedback to any sub-strem. We should maintain an inclusive and open community.
Some rules are ideally perfect, but impossible to apply. We would all like PRs to be reviewed by plenty of active contributors, but unfortunately, in reality, active contributors are few and applying a strict process for changes without big impact, it is just impossible and blocking. For example, who will check that we have an equal number of operators' and vendors' approvals. More flexibility is necessary and the number of approvals required should be left to the judgement of the sub-project leader based on the significance of the changes. Everything is recorded through the PRs mechanism and everyone can access and criticize the changes.
Well said, Karine. Agree 200%. Thanks Walter
On Thu, 15 Sep 2022 at 1:09 am, karinesevilla @.***> wrote:
Some rules are ideally perfect, but impossible to apply. We would all like PRs to be reviewed by plenty of active contributors, but unfortunately, in reality, active contributors are few and applying a strict process for changes without big impact, it is just impossible and blocking. For example, who will check that we have an equal number of operators' and vendors' approvals. More flexibility is necessary and the number of approvals required should be left to the judgement of the sub-project leader based on the significance of the changes. Everything is recorded through the PRs mechanism and everyone can access and criticize the changes.
— Reply to this email directly, view it on GitHub https://github.com/cntt-n/CNTT/pull/3187#issuecomment-1246913044, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMONQFYCMWAALK72SUZSSG3V6HTBXANCNFSM6AAAAAAQLSTTQA . You are receiving this because your review was requested.Message ID: @.***>
To be honest I do not agree that one should not provide feedback to any sub-strem. We should maintain an inclusive and open community.
As I wrote in my previous comment, what we saw in a few PR in RA1 is about judging the process in the stream without any contribution in it before and after. Nothing constructive resulted from it ; just basic policies. I disagree it's about feedbacks as quoted. Else yes any constructive feedback is always welcome!
It's even far more inappropriate when we take into account the quality of RA1 content, its contribution level, its processes, its automation and its management. Yes it's hard to know from outside without any contribution in it... Please rather run at least git log in RA1 and in CNTT + git diff between moselle.
inclusive and open, really ? I would consider that this behavior leads exactly to the opposite. Some sub-project could be considered as in danger in front of a lack of meritocracy and too much policies which forbid contributing; the contributors would find other ways to develop their crucial software in a safer environment.
Again that's a far more bigger issue than the reviewer count algorithm which should rather be at sub-project contributor level as stated by many people here.
TSC must be clear in this topic, about its role and the meeting chair role as the sub-projects and their contributors deserve. Frankly I was hoping it was about transient mistakes.
Some rules are ideally perfect, but impossible to apply. We would all like PRs to be reviewed by plenty of active contributors, but unfortunately, in reality, active contributors are few and applying a strict process for changes without big impact, it is just impossible and blocking. For example, who will check that we have an equal number of operators' and vendors' approvals. More flexibility is necessary and the number of approvals required should be left to the judgement of the sub-project leader based on the significance of the changes. Everything is recorded through the PRs mechanism and everyone can access and criticize the changes.
I think the best approach would be to adjust our processes to the reality of the project, but not abandoning them. (Off course that is also an option if the community agrees to it).