Skip to content

GOV introduce rights for groups as discussed in SLEP019 #25753

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Apr 16, 2023
Merged

GOV introduce rights for groups as discussed in SLEP019 #25753

Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
31c8387
GOV introduce rights for groups as discussed in SLEP019
adrinjalali Mar 3, 2023
3dae114
Merge remote-tracking branch 'upstream/main' into slep019
adrinjalali Mar 3, 2023
49bd819
Update doc/governance.rst
adrinjalali Mar 6, 2023
2d45e56
address a few comments
adrinjalali Mar 7, 2023
459ba7e
fix merge conflict
adrinjalali Mar 7, 2023
c74ed5f
Guillaume's comment
adrinjalali Mar 7, 2023
2a0fa3d
reference slep020 for governance changes
adrinjalali Mar 7, 2023
4bf052e
drop 'more than'
adrinjalali Mar 7, 2023
674ccdc
Update doc/governance.rst
adrinjalali Mar 9, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
190 changes: 102 additions & 88 deletions doc/governance.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,95 +20,101 @@ the project community.
Roles And Responsibilities
==========================

We distinguish between contributors, core contributors, and the technical
committee. A key distinction between them is their voting rights: contributors
have no voting rights, whereas the other two groups all have voting rights,
as well as permissions to the tools relevant to their roles.

Contributors
------------

Contributors are community members who contribute in concrete ways to the
project. Anyone can become a contributor, and contributions can take many forms
– not only code – as detailed in the :ref:`contributors guide <contributing>`.
There is no process to become a contributor: once somebody contributes to the
project in any way, they are a contributor.
Comment on lines +34 to +35
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we give examples of (non-technical) contributions?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One goal in the governance has been to keep it short, otherwise it'd be very long if we want to include everything here. The contribution guideline has a list of possible contributions, the same way that SLEP000 explains how we do sleps.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm in favour of keeping it short. Maybe turning "contributes to the project" into a link to the contrib docs is a compromise (though I worry about the link becoming out of date, but maybe it is a "premature optimisation" kinda worry :-/)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already the link to the contributing guide here, right before the lines I added.


Contributor Experience Team
---------------------------

The contributor experience team is composed of community members who have permission on
github to label and close issues. :ref:`Their work <bug_triaging>` is
crucial to improve the communication in the project and limit the crowding
of the issue tracker.

Similarly to what has been decided in the `python project
<https://devguide.python.org/triage/triage-team/#becoming-a-member-of-the-python-triage-team>`_,
any contributor may become a member of the scikit-learn contributor experience team,
after showing some continuity in participating to scikit-learn
development (with pull requests and reviews).
Any core developer or member of the contributor experience team is welcome to propose a
scikit-learn contributor to join the contributor experience team. Other core developers
are then consulted: while it is expected that most acceptances will be
unanimous, a two-thirds majority is enough.
Every new member of the contributor experience team will be announced in the mailing
list. Members of the team are welcome to participate in `monthly core developer meetings
Core Contributors
-----------------

All core contributor members have the same voting rights and right to propose
new members to any of the roles listed below. Their membership is represented
as being an organization member on the scikit-learn `GitHub organization
<https://github.com/orgs/scikit-learn/people>`_.

They are also welcome to join our `monthly core contributor meetings
<https://github.com/scikit-learn/administrative/tree/master/meeting_notes>`_.

New members can be nominated by any existing member. Once they have been
nominated, there will be a vote by the current core contributors. Voting on new
members is one of the few activities that takes place on the project's private
mailing list. While it is expected that most votes will be unanimous, a
two-thirds majority of the cast votes is enough. The vote needs to be open for
at least 1 week.

Core contributors that have not contributed to the project, corresponding to
their role, in the past 12 months will be asked if they want to become emeritus
members and recant their rights until they become active again. The list of
members, active and emeritus (with dates at which they became active) is public
on the scikit-learn website.

The following teams form the core contributors group.


Contributor Experience Team
~~~~~~~~~~~~~~~~~~~~~~~~~~~

The contributor experience team improves the experience of contributors by
helping with the triage of issues and pull requests, as well as noticing any
repeating patterns where people might struggle, and to help with improving
those aspects of the project.

To this end, they have the required permissions on github to label and close
issues. :ref:`Their work <bug_triaging>` is crucial to improve the
communication in the project and limit the crowding of the issue tracker.

.. _communication_team:

Communication team
-------------------
~~~~~~~~~~~~~~~~~~

Members of the communication team help with outreach and communication
for scikit-learn. The goal of the team is to develop public awareness of
scikit-learn, of its features and usage, as well as branding.

For this, they can operate the scikit-learn accounts on various social
networks and produce materials.
For this, they can operate the scikit-learn accounts on various social networks
and produce materials. They also have the required rights to our blog
repository and other relevant accounts and platforms.

Every new communicator will be announced in the mailing list.
Communicators are welcome to participate in `monthly core developer meetings
<https://github.com/scikit-learn/administrative/tree/master/meeting_notes>`_.

Core developers
---------------
Maintainers
~~~~~~~~~~~

Core developers are community members who have shown that they are dedicated to
the continued development of the project through ongoing engagement with the
Maintainers are community members who have shown that they are dedicated to the
continued development of the project through ongoing engagement with the
community. They have shown they can be trusted to maintain scikit-learn with
care. Being a core developer allows contributors to more easily carry on
with their project related activities by giving them direct access to the
project's repository and is represented as being an organization member on the
scikit-learn `GitHub organization <https://github.com/orgs/scikit-learn/people>`_.
Core developers are expected to review code
contributions, can merge approved pull requests, can cast votes for and against
merging a pull-request, and can be involved in deciding major changes to the
API.

New core developers can be nominated by any existing core developers. Once they
have been nominated, there will be a vote by the current core developers.
Voting on new core developers is one of the few activities that takes place on
the project's private management list. While it is expected that most votes
will be unanimous, a two-thirds majority of the cast votes is enough. The vote
needs to be open for at least 1 week.

Core developers that have not contributed to the project (commits or GitHub
comments) in the past 12 months will be asked if they want to become emeritus
core developers and recant their commit and voting rights until they become
active again. The list of core developers, active and emeritus (with dates at
which they became active) is public on the scikit-learn website.
care. Being a maintainer allows contributors to more easily carry on with their
project related activities by giving them direct access to the project's
repository. Maintainers are expected to review code contributions, merge
approved pull requests, cast votes for and against merging a pull-request,
and to be involved in deciding major changes to the API.

Technical Committee
-------------------
The Technical Committee (TC) members are core developers who have additional
responsibilities to ensure the smooth running of the project. TC members are expected to
participate in strategic planning, and approve changes to the governance model.
The purpose of the TC is to ensure a smooth progress from the big-picture
perspective. Indeed changes that impact the full project require a synthetic
analysis and a consensus that is both explicit and informed. In cases that the
core developer community (which includes the TC members) fails to reach such a
consensus in the required time frame, the TC is the entity to resolve the
issue.
Membership of the TC is by nomination by a core developer. A nomination will
result in discussion which cannot take more than a month and then a vote by
the core developers which will stay open for a week. TC membership votes are
subject to a two-third majority of all cast votes as well as a simple majority
approval of all the current TC members. TC members who do not actively engage
with the TC duties are expected to resign.

The Technical Committee (TC) members are maintainers who have additional
responsibilities to ensure the smooth running of the project. TC members are
expected to participate in strategic planning, and approve changes to the
governance model. The purpose of the TC is to ensure a smooth progress from the
big-picture perspective. Indeed changes that impact the full project require a
synthetic analysis and a consensus that is both explicit and informed. In cases
that the core contributor community (which includes the TC members) fails to
reach such a consensus in the required time frame, the TC is the entity to
resolve the issue. Membership of the TC is by nomination by a core contributor.
A nomination will result in discussion which cannot take more than a month and
then a vote by the core contributors which will stay open for a week. TC
membership votes are subject to a two-third majority of all cast votes as well
as a simple majority approval of all the current TC members. TC members who do
not actively engage with the TC duties are expected to resign.

The Technical Committee of scikit-learn consists of :user:`Thomas Fan
<thomasjpfan>`, :user:`Alexandre Gramfort <agramfort>`, :user:`Olivier Grisel
Expand All @@ -125,34 +131,38 @@ and the `issue tracker <https://github.com/scikit-learn/scikit-learn/issues>`_.
Occasionally, sensitive discussion occurs on a private list.

Scikit-learn uses a "consensus seeking" process for making decisions. The group
tries to find a resolution that has no open objections among core developers.
At any point during the discussion, any core-developer can call for a vote, which will
conclude one month from the call for the vote. Any vote must be backed by a
:ref:`SLEP <slep>`. If no option can gather two thirds of the votes cast, the
decision is escalated to the TC, which in turn will use consensus seeking with
the fallback option of a simple majority vote if no consensus can be found
within a month. This is what we hereafter may refer to as "**the decision making
process**".

Decisions (in addition to adding core developers and TC membership as above)
tries to find a resolution that has no open objections among core contributors.
At any point during the discussion, any core contributor can call for a vote,
which will conclude one month from the call for the vote. Most votes have to be
backed by a :ref:`SLEP <slep>`. If no option can gather two thirds of the votes
cast, the decision is escalated to the TC, which in turn will use consensus
seeking with the fallback option of a simple majority vote if no consensus can
be found within a month. This is what we hereafter may refer to as "**the
decision making process**".

Decisions (in addition to adding core contributors and TC membership as above)
are made according to the following rules:

* **Minor Documentation changes**, such as typo fixes, or addition / correction of a
sentence, but no change of the scikit-learn.org landing page or the “about”
page: Requires +1 by a core developer, no -1 by a core developer (lazy
consensus), happens on the issue or pull request page. Core developers are
expected to give “reasonable time” to others to give their opinion on the pull
request if they're not confident others would agree.
* **Minor Documentation changes**, such as typo fixes, or addition / correction
of a sentence, but no change of the ``scikit-learn.org`` landing page or the
“about” page: Requires +1 by a maintainer, no -1 by a maintainer (lazy
consensus), happens on the issue or pull request page. Maintainers are
expected to give “reasonable time” to others to give their opinion on the
pull request if they're not confident others would agree.

* **Code changes and major documentation changes**
require +1 by two core developers, no -1 by a core developer (lazy
require +1 by two maintainers, no -1 by a maintainer (lazy
consensus), happens on the issue of pull-request page.

* **Changes to the API principles and changes to dependencies or supported
versions** happen via a :ref:`slep` and follows the decision-making process outlined above.
versions** happen via a :ref:`slep` and follows the decision-making process
outlined above.

* **Changes to the governance model** follow the process outlined in [
SLEP020](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep020/proposal.html).

If a veto -1 vote is cast on a lazy consensus, the proposer can appeal to the
community and core developers and the change can be approved or rejected using
community and maintainers and the change can be approved or rejected using
the decision making procedure outlined above.

Governance Model Changes
Expand All @@ -177,6 +187,10 @@ Enhancement proposals (SLEPs)
For all votes, a proposal must have been made public and discussed before the
vote. Such proposal must be a consolidated document, in the form of a
"Scikit-Learn Enhancement Proposal" (SLEP), rather than a long discussion on an
issue. A SLEP must be submitted as a pull-request to
`enhancement proposals <https://scikit-learn-enhancement-proposals.readthedocs.io>`_
using the `SLEP template <https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep_template.html>`_.
issue. A SLEP must be submitted as a pull-request to `enhancement proposals
<https://scikit-learn-enhancement-proposals.readthedocs.io>`_ using the `SLEP
template
<https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep_template.html>`_.
`SLEP000
<https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep000/proposal.html>`__
describes the process in more detail.