LaszloGombos
commented
1 year ago Here are some of my thoughts on this:
if a new member has resolved 20 bugs and had 50 merged PR ( or something along those lines )
This is a good starting point for a discussion, but I find this hard to measure and too high of a bar. If the bar is so high that nobody can every achieve it, then we failed to define a good process and a good project.
Lot of commits does not have issues filed for, which makes it hard to measure the number of bugs.
I also think there a number of other ways members can meaningfully contribute that should count
- Finding and filing issues (without resolving them)
- Reviewing and/or correcting other member's PRs according to project goals
I think most important in the process is vote of confidence from existing members, so it is ok to keep the minimum contribution bar somewhat low and expect existing members to keep the bar high when making a decision on write requests.
I would propose the number of minimum contributions to be 20. Commits, filed issues and reviews all counts towards contributions. At least one commit, one new issue and one review is required to demonstrate the understanding of project processes (meaning that one can not just have reviews or new issues without commits).
he can request for write access in which x amount of existing individuals with write access will review total sum of his or hers work and ack or nack such request.
I would propose x=2+ existing active individuals with write access should ack suck a request.
Active member could be defined as any sort of involvement in the project in the last 12 months (could be as simple as one non-trivial comment on a PR to remain active for the purpose of participating in voting).
If there is at least one nack veto for such a request from an existing active individual with write access than majority vote would be required form the group of existing active individuals with write access.
CC all members with write access for visibility: @johannbg @aafeijoo-suse @lnykryn @haraldh @tblume
In light of recent events it became apparent that the project needs additional workflows added to it for both transparency and security reasons.
Workflow(s) are needed for members joining/leaving the project and will new members regardless of their background, education employment etc. start from the same point, in the same role in the project ( no short cuts as in favors I know foo or I work for X or I'm part of X project so I'm auto granted x permissions ) and work their way up from there by completing x amounts of tasks within the project prior to proceeding to next role such as be granted write access.
With access permissions comes a workflow that is needed to handles those permissions within the project when a role is elevated to a next one as in if a new member has resolved 20 bugs and had 50 merged PR ( or something along those lines ) he can request for write access in which x amount of existing individuals with write access will review total sum of his or hers work and ack or nack such request.
The task from these issue falls under the individuals that are in administrators/organization owners role at any given point in time.
The community members that dont need no specific project access or label can just continue to do what they have always done since the git log speaks for itself.
Question if employees should be added as outside collaborators as github suggest.