[Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

[Travis Oliphant]

>
>
> Here is a list of the current Contributors to the main NumPy repository:
>
> [
> https://github.com/numpy/numpy/graphs/contributors](https://github.com/numpy/numpy/graphs/contributors)
>
>
One of the problems with this list is that my contributions to the project
are extremely under-represented because the large majority of my commitment
of code happened in 2005 to 2006 before github was used.      So, using
this as a list of the contributors is quite misleading --- and there are a
lot of people now looking only at lists like this one and it might confuse
them why I care so much.    So, if you are going to make this list public
in a governance document like this, then I think some acknowledgement of
the source of the original code and the contributors to that needs to also
be made --- or you could just also point to the THANKS document which lists
people up to about 2008.   Between 2008 and 2010 we will lose
contributions, still and this can be acknowledged.


> Consensus-based decision making by the community
> ------------------------------------------------
>
> Normally, all project decisions will be made by consensus of all
> interested Contributors. The primary goal of this approach is to ensure
> that the people who are most affected by and involved in any given change
> can contribute their knowledge in the confidence that their voices will be
> heard, because thoughtful review from a broad community is the best
> mechanism we know of for creating high-quality software.
>
> The mechanism we use to accomplish this goal may be unfamiliar for those
> who are not experienced with the cultural norms around free/open-source
> software development. We provide a summary here, and highly recommend that
> all Contributors additionally read [Chapter 4: Social and Political
> Infrastructure](
> http://producingoss.com/en/producingoss.html#social-infrastructure) of
> Karl Fogel's classic *Producing Open Source Software*, and in particular
> the section on [Consensus-based Democracy](
> http://producingoss.com/en/producingoss.html#consensus-democracy), for a
> more detailed discussion.
>
> In this context, consensus does *not* require:
>
> - that we wait to solicit everybody's opinion on every change,
> - that we ever hold a vote on anything,
> - or that everybody is happy or agrees with every decision.
>
> For us, what consensus means is that we entrust *everyone* with the right
> to veto any change if they feel it necessary. While this may sound like a
> recipe for obstruction and pain, this is not what happens. Instead, we find
> that most people take this responsibility seriously, and only invoke their
> veto when they judge that a serious problem is being ignored, and that
> their veto is necessary to protect the project. And in practice, it turns
> out that such vetoes are almost never formally invoked, because their mere
> possibility ensures that Contributors are motivated from the start to find
> some solution that everyone can live with -- thus accomplishing our goal of
> ensuring that all interested perspectives are taken into account.
>
> How do we know when consensus has been achieved? In principle, this is
> rather difficult, since consensus is defined by the absence of vetos, which
> requires us to somehow prove a negative. In practice, we use a combination
> of our best judgement (e.g., a simple and uncontroversial bug fix posted on
> GitHub and reviewed by a core developer is probably fine) and best efforts
> (e.g., all substantive API changes must be posted to the mailing list in
> order to give the broader community a chance to catch any problems and
> suggest improvements; we assume that anyone who cares enough about NumPy to
> invoke their veto right should be on the mailing list). If no-one bothers
> to comment on the mailing list after a few days, then it's probably fine.
> And worst case, if a change is more controversial than expected, or a
> crucial critique is delayed because someone was on vacation, then it's no
> big deal: we apologize for misjudging the situation, [back up, and sort
> things out](
> http://producingoss.com/en/producingoss.html#version-control-relaxation).
>
> If one does need to invoke a formal veto, then it should consist of:
>
> - an unambiguous statement that a veto is being invoked,
> - an explanation of why it is being invoked, and
> - a description of what conditions (if any) would convince the vetoer to
> withdraw their veto.
>
> If all proposals for resolving some issue are vetoed, then the status quo
> wins by default.
>
> In the worst case, if a Contributor is genuinely misusing their veto in an
> obstructive fashion to the detriment of the project, then they can be
> ejected from the project by consensus of the Steering Council -- see below.
>
> Steering Council
> ----------------
>
> The Project will have a Steering Council that consists of Project
> Contributors who have produced contributions that are substantial in
> quality and quantity, and sustained over at least one year. The overall
> role of the Council is to ensure, with input from the Community, the
> long-term well-being of the project, both technically and as a community.
>
> During the everyday project activities, council members participate in all
> discussions, code review and other project activities as peers with all
> other Contributors and the Community. In these everyday activities, Council
> Members do not have any special power or privilege through their membership
> on the Council. However, it is expected that because of the quality and
> quantity of their contributions and their expert knowledge of the Project
> Software and Services that Council Members will provide useful guidance,
> both technical and in terms of project direction, to potentially less
> experienced contributors.
>
> The Steering Council and its Members play a special role in certain
> situations. In particular, the Council may, if necessary:
>
> -   Make decisions about the overall scope, vision and direction of the
> project.
> -   Make decisions about strategic collaborations with other organizations
> or individuals.
> -   Make decisions about specific technical issues, features, bugs and
> pull requests. They are the primary mechanism of guiding the code review
> process and merging pull requests.
> -   Make decisions about the Services that are run by The Project and
> manage those Services for the benefit of the Project and Community.
> -   Update policy documents such as this one.
> -   Make decisions when regular community discussion doesn’t produce
> consensus on an issue in a reasonable time frame.
>
> However, the Council's primary responsibility is to facilitate the
> ordinary community-based decision making procedure described above. If we
> ever have to step in and formally override the community for the health of
> the Project, then we will do so, but we will consider reaching this point
> to indicate a failure in our leadership.
>
> ### Council decision making
>
> If it becomes necessary for the Steering Council to produce a formal
> decision, then they will use a form of the [Apache Foundation voting
> process](https://www.apache.org/foundation/voting.html). This is a
> formalized version of consensus, in which +1 votes indicate agreement, -1
> votes are vetoes (and must be accompanied with a rationale, as above), and
> one can also vote fractionally (e.g. -0.5, +0.5) if one wishes to express
> an opinion without registering a full veto. These numeric votes are also
> often used informally as a way of getting a general sense of people's
> feelings on some issue, and should not normally be taken as formal votes. A
> formal vote only occurs if explicitly declared, and if this does occur then
> the vote should be held open for long enough to give all interested Council
> Members a chance to respond -- at least one week.
>
> In practice, we anticipate that for most Steering Council decisions (e.g.,
> voting in new members) a more informal process will suffice.
>
> ### Council membership
>
> To become eligible to join the Steering Council, an individual must be a
> Project Contributor who has produced contributions that are substantial in
> quality and quantity, and sustained over at least one year. Potential
> Council Members are nominated by existing Council members and voted upon by
> the existing Council after asking if the potential Member is interested and
> willing to serve in that capacity. The Council will be initially formed
> from the set of existing Core Developers who, as of late 2015, have been
> significantly active over the last year.
>
>
Concretely, I'm asking to be included in this initial council so a simple
"along with Travis Oliphant who is the original author of NumPy".   If
other long-time contributors to the code-base also want to be on this
initial seed council, I think it would make sense as well.


> When considering potential Members, the Council will look at candidates
> with a comprehensive view of their contributions. This will include but is
> not limited to code, code review, infrastructure work, mailing list and
> chat participation, community help/building, education and outreach, design
> work, etc. We are deliberately not setting arbitrary quantitative metrics
> (like “100 commits in this repo”) to avoid encouraging behavior that plays
> to the metrics rather than the project’s overall well-being. We want to
> encourage a diverse array of backgrounds, viewpoints and talents in our
> team, which is why we explicitly do not define code as the sole metric on
> which council membership will be evaluated.
>
> If a Council member becomes inactive in the project for a period of one
> year, they will be considered for removal from the Council. Before removal,
> inactive Member will be approached to see if they plan on returning to
> active participation. If not they will be removed immediately upon a
> Council vote. If they plan on returning to active participation soon, they
> will be given a grace period of one year. If they don’t return to active
> participation within that time period they will be removed by vote of the
> Council without further grace period. All former Council members can be
> considered for membership again at any time in the future, like any other
> Project Contributor.  Retired Council members will be listed on the project
> website, acknowledging the period during which they were active in the
> Council.
>

I would just remove quite a bit of this language and just say that members
who are inactive on the Council may be asked to step down if they are not
planning on returning to active participation.


> The Council reserves the right to eject current Members, if they are
> deemed to be actively harmful to the project’s well-being, and attempts at
> communication and conflict resolution have failed. This requires the
> consensus of the remaining Members.
>
> [We also have to decide on the initial membership for the Council. While
> the above text makes pains to distinguish between "committer" and "Council
> Member", in the past we've pretty much treated them as the same. So to keep
> things simple and deterministic, I propose that we seed the Council with
> everyone who has reviewed/merged a pull request since Jan 1, 2014, and move
> those who haven't used their commit bit in >1.5 years to the emeritus list.
> Based on the output of
>
>    git log --grep="^Merge pull request" --since 2014-01-01 | grep Author:
> | sort -u
>
> I believe this would give us an initial Steering Council of: Sebastian
> Berg, Jaime Fernández del Río, Ralf Gommers, Alex Griffing, Charles Harris,
> Nathaniel Smith, Julian Taylor, and Pauli Virtanen (assuming everyone on
> that list is interested/willing to serve).]
>

I would ask to be on this initial council by having the rule include
"original contributors of the code" which would basically include Robert
Kern and Pearu Peterson in addition to Chuck Harris (though Pearu's main
contribution was numpy.distutils and f2py and he may not be interested any
longer in the rest of it).

Thanks,

-Travis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150923/e73e2a1d/attachment.html>