GOV Propose 3 Basic Roles #25670
GOV Propose 3 Basic Roles #25670
Conversation
There was a problem hiding this comment.
This PR is removing the role between "Contributor" and "Core Contributor", which is exactly the same structure we had before the "Triage Team" or the "Contributor Experience Team" was formed. The big difference is that this PR is expanding the role of "Core Contributor" to include all types of contributions.
I'm unsure if this is the way forward to get more people to be involved. For example, the PyMC project has the "Recurring Contributor" which is a step in-between to get involved. If scikit-learn goes back to having two tiers, "Contributor" and "Core Contributor", then it will take longer for one to join the Core Team, because it takes longer to build trust and get the write permission.
I think some would be happy with a tier in-between such as "Recurring Contributor" because of the reduced responsibilities and the lower time commitment.
| which they became active) is public on the scikit-learn website. | ||
|
|
||
| # TODO: remove/replace .. _communication_team: | ||
| # TODO: replace core developer by core contributor in all files. | ||
| # TODO: what to do with members of the contributor experience team, communication team? |
There was a problem hiding this comment.
The "merge pull-requests" right require write permissions, which allows one to control the secrets in the repo: github/docs#1087. Because of the expanded permissions, I prefer to have a nomination + vote for each member of the contributor experience team + communication team to be a part of the Core Contributor Team.
The alternative is to invite everyone to join the Core Contributor Team, but that almost doubles the number of people with write permission.
There was a problem hiding this comment.
I agree with @thomasjpfan, and I think it might be better to perform change indicated by such TODOs in a second PR. What do you think?
There was a problem hiding this comment.
Thank you for adapting the Governance Document, @lorentzenchr.
| be kindly asked to step back by the technical committee. | ||
| As *ultima ratio*, the technical committee is allowed to call for a vote to withdraw | ||
| the core contributor role from a current member. | ||
| A 3/4 majority of all current core contributors is needed that this vote passes. |
There was a problem hiding this comment.
| A 3/4 majority of all current core contributors is needed that this vote passes. | |
| A 3/4 majority of all current core contributors is needed for this vote to pass. |
| - Triage github issues and pull requests | ||
| - Review code | ||
| - Contribute code | ||
| - Create a common development roadmap |
There was a problem hiding this comment.
I think it would be appropriate precising the goal of a development roadmap and its enforcement (I do not think everyone agrees on the relevance of a roadmap).
| active again. The list of core developers, active and emeritus (with dates at | ||
| More details can be found in the :ref:`contributors guide <contributing>`. | ||
|
|
||
| Core Contributors |
There was a problem hiding this comment.
Should we update the rest documentation in other PRs to use Contributor and Core Contributor everywhere?
| how that participation takes place and how to set about earning merit within | ||
| the project community. |
There was a problem hiding this comment.
What do you think?
| how that participation takes place and how to set about earning merit within | |
| the project community. | |
| how that participation takes place and how to set about earning merit within | |
| and participating democratically to the project community. |
| which they became active) is public on the scikit-learn website. | ||
|
|
||
| # TODO: remove/replace .. _communication_team: | ||
| # TODO: replace core developer by core contributor in all files. | ||
| # TODO: what to do with members of the contributor experience team, communication team? |
There was a problem hiding this comment.
I agree with @thomasjpfan, and I think it might be better to perform change indicated by such TODOs in a second PR. What do you think?
|
I like the direction of this change. As I understand the rules right now (on I also think that read access to credentials is a problem (why hide them in the UI but make them available over the API??). It looks like this is one of the few things that people with access can do without leaving a trace/being noticed. Another thing to worry about is having accounts that have elevated permissions but don't use them regularly (I sleep better the less access rights my accounts have because it makes them a less attractive target). Taken together I think that defining a person's status in the project via the access rights on GitHub (or other platforms like Twitter, PyPI, Discord, ...) is a bug. The good thing is that scikit-learn already lists people, project roles and a mapping between them on the website. Anecdote: Within JuypterHub we discussed and had broad agreement (but implementation is slow) on the fact that not every one who could have admin/write access to a repo needs to actually have it at a given moment in time. Similarly for PyPI, cloud provider accounts, etc. You can always ask to be added if you need it for your work or because you decide to be more active on a particular repo (or ask for it to be removed if you become less active). This is after enforcing 2FA for all accounts I think using something like the website as the source of truth for "status in the project" and promoting that will help de-emphasize the "status" of GitHub access rights. Reduced access rights is good for security and, I think, help resolve a blocker for having just one level of membership in the project. |
|
xref #25753 (comment) for those who only get notifications from this PR and not the other one. |
|
@lorentzenchr what do you think of #25753? Adrin would like to call a vote on that PR as an alternative to this PR. I think it would be good if we could converge on one PR and sort out any differences that remain first. |
Governance Change
According to SLEP020, see also #25663, this PR proposes a change of the scikit-learn governance.
Abstract
The governance structure gets more democratic elements and only three different roles are established. This way, all contributions, e.g. "beyond code", are recognized equally and get the same rights and obligations.
Proposed Roles
Three basic roles replace all other roles:
@scikit-learn/core-devs @scikit-learn/contributor-experience-team @scikit-learn/communication-team ping