Foundation of New Governance Model

[afshin]

Votes

@afshin

• YES
• NO

@blink1073

• YES
• NO

@Carreau

• YES (after deadline)
• NO

@damianavila

• YES
• NO

@ellisonbg

• YES
• NO

@fperez

• YES
• NO

@ivanov

• YES
• NO

@jasongrout

• YES
• NO

@jhamrick

• YES
• NO

@minrk

• YES
• NO

@mpacer

• YES
• NO

@parente

• YES
• NO

@rgbkrk

• YES
• NO

@Ruv7

• YES
• NO

@SylvainCorlay

• YES
• NO

@takluyver

• YES
• NO

@willingc

• YES
• NO

Contents of the PR

Decision Making and Bootstrapping New Governance Model

The scope of this PR is to establish the foundation of our new governance model. It describes the decision making process and the bootstrapping of the individual Subprojects for the new model.

Note that this does not address the proposed Software Steering Council or the Board of Directors side, which is still being worked on.

The process

The process for changing the governance pages is as follows:

• Open a pull request in draft state. This triggers a discussion and iteration phase for your proposed changes.
• When you believe enough discussion has happened, move the pull request to an active state. This triggers a vote.
• During the voting phase, no substantive changes may be made to the pull request.
• The Steering Council will vote, and at the end of voting the pull request is merged or closed.

The discussion phase is meant to gather input and multiple perspectives from the community.
Make sure that the community has had an opportunity to weigh in on
the change before calling a vote. A good rule of thumb is to ask several Steering Council
members if they believe that it is time for a vote, and to let at least one person review
the pull request for structural quality and typos.

Voting period

This PR was taken out of draft mode on 18 June 2021 and voting will end 16 July 2021.

[Carreau]

Minor comments questions; I have no objections to anything said here.

[willingc]

Thanks for posting @afshin

[willingc]

The JEP process should really be governed by a standards body/subproject.

[ellisonbg]

We (@fperez @afshin @ellisonbg) envision the JEP process being used for a broader range of cross-project matters than standards. The primary purpose of the SSC is to make cross-project software decisions with JEPs as their primary mechanism. The SSC could delegate certain aspects of the management of the process to other groups or individuals at their discretion – in these governance documents we are attempting to give the SSC a scope and mandate (JEPs) and leave it up to them to figure out how that works.

[willingc]

Can we add that the JEP repo will be maintained by the Jupyter Standards subgroup. The SSC will be responsible for creating a transparent, participatory, and inclusive process for the evaluation of PEPs that is documented in the JEP repo.

[choldgraf]

I think of it in terms of skill set. The people that oversee the JEP process will need to have training and experience in a particular kind of participatory decision making process, so that they can effectively steward and improve the JEP process itself. I don’t think the entire SSC would have these skills, and as such it may be productive to designate specific group of people that oversee the JEP process. The standards group feels like it must also have this skill set (since creating standards means wrangling lots of people to make a decision) so seems like a natural home to steward the JEP process itself

[willingc]

I disagree. I believe the BoD should be responsible for this and the SSC should be responsible along with the BoD that the CoC is upheld in the subprojects.

Further, there should be a Diversity and Inclusion Subproject on the SSC as well as a Diversity and Inclusion standing workgroup of the BoD. As it stands now, this governance structure effectively eliminates gender inclusion. The progress of inclusion on many subprojects has been poor. While we can talk about how important inclusion is to the project, the reality is that the actions of the project have not made it a priority. Creating a governance is the place to bake in inclusion by default. If we only hope it will organically happen, it will not (look at the past five years as evidence).

[fperez]

Thanks @willingc for these - sorry we didn't get last week to this one, but we're going in order :)

I disagree. I believe the BoD should be responsible for this and the SSC should be responsible along with the BoD that the CoC is upheld in the subprojects.

We discussed this on Friday and I think those of us who were there (Steve, Sharan, Darian, me) lean in the same direction as you now... I think this has been part of the back-and-forth on how to best apply divisions of labor/scope between the SSC and the BoD, but it probably makes sense to leave the CoC definition/updates to the BoD. Obviously updates to that document will still be subject to community input/feedback, so there's no loss of access to that discussion for SSC members. But it does help clarify that the SSC's scope is software architecture, while the BoD focuses on community and governance.

Further, there should be a Diversity and Inclusion Subproject on the SSC as well as a Diversity and Inclusion standing workgroup of the BoD. As it stands now, this governance structure effectively eliminates gender inclusion. The progress of inclusion on many subprojects has been poor. While we can talk about how important inclusion is to the project, the reality is that the actions of the project have not made it a priority. Creating a governance is the place to bake in inclusion by default. If we only hope it will organically happen, it will not (look at the past five years as evidence).

The way we'd envisioned topics like D&I was that the working groups on such matters (much like events, trademarks, etc.) ought to be chartered by the BoD, and then for those whose scope would intersect with the SSC, then they would jointly agree to have a representative from that working group in the SSC. So rather than having two separate diversity subprojects (at least that's how I understood your paragraph above), there should be a single one targeting these issues across the entire Project Jupyter, with a representative in the SSC who can focus on Diversity questions in the process of software.

[fperez]

We've updated the document as per this feedback, and will also jointly update the BoD draft (PR upcoming) to match. Thanks!

[meeseeksmachine]

This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/governance-office-hours-meeting-minutes/1480/135

[damianavila]

As a general comment, I see mentions about different working groups through all the PR. There are even some mentions about some working groups being members of the SSC (Diversity and Inclusion, Accessibility, and Internationalization).
I think there is a missing definition of a working group, the list of existing (or pretended to exist) working groups, and how those interact with other "bodies".

[willingc]

I believe that this would be better as a standing working group of the board of directors. The chair of the working group will also have representation as a member of the SSC.

[fperez]

Yup, that's actually the plan! Sorry if it wasn't too clear, but the BoD PR (that we'll try to open as soon as we complete work on this one) will list that as a necessary WG under the Board of Directors. I think in the end we could have chairs delegate representation to the SSC at their discretion, but that's a minor detail that can be worked later. I think your key point is one we're already in agreement on :)

[choldgraf]

In my experience “diversity and inclusion” working groups are often marginalized within organizations. They exist as a token of D&I but do not have actual power to create change. What are ways that the Jupyter D&I group will have tangible authority over sub projects that do not meet Jupyter standards of D&I?

[fperez]

BTW - stopping here for the day, but thanks so much for the feedback!

[willingc]

Thanks folks. The edits are definitely moving the document in the right direction.

[fperez]

Thanks @jasongrout! Indeed - small typographic consistency fixes are OK and welcome, no need to worry about voting clocks for that kind of fixes.

Also - I agree, until the entire new system is in-place, the SC continues to function as before.

As we merge these there will obviously be a necessary bootstrapping/transition period, and those always require some flexibility and "thinking on our feet". But if we're in agreement on where the end state should be (the point of these documents/PRs), then we start from our known state (the current SC/model) and should be able to trace a path between the two points.

[choldgraf]

I think that this is a good foundation to start with and take some next steps. I think there are some important questions to answer still, such as

• when do subprojects need to follow this decision process? (or do they decide when they should and shouldn't have an official vote)
• how does the BoD ensure that projects have the resources they need to carry out this new structure?
• how do we ensure that projects are actually run inclusively? What happens if some still are not run in this way? What happens if people have different definitions of "inclusive"?

However I think that I am on board with this language and hope to iterate and improve upon these ideas in the future with others. Thanks to this team for diligently making progress on this over the months ✨

[meeseeksmachine]

This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/governance-office-hours-meeting-minutes/1480/146

[ellisonbg]

Hi everyone, just a reminder, the voting period for this PR will end ~1 week from today.

[mpacer]

This policy is likely to negatively affect anyone who cannot, for various reasons, participate in all of the votes. Such people tend to come from less-privileged, more marginalized, and underrepresented groups. Merely by observing and speaking, members of underrepresented groups can make a immensely positive difference. These individuals should be able to remain at the table, if only so that they may bear witness to the decision-making process.

[willingc]

M, that's a reasonable point. IIRC, the metric for participation is to encourage engaged individuals in a decision making process. Onboarding and offboarding processes are important for healthy governance. Oftentimes, someone feels guilty about stepping down when too busy.

I believe if we soften the wording to better reflect that we want engaged individuals but recognize that sometimes life happens:

Members that have not met the 2/3 vote participation threshold for a year will automatically be asked to step down at the end of that year.
Members who miss 1/3 of the votes will be asked if they would like to continue to serve the following year. If the individual chooses to step down, Those individuals the individual remains eligible to rejoin the decision-making body in the future.

[mpacer]

Agreed that offboarding processes are important! That feels something that should be available to all members (regardless of their participation in votes).

To make this available to all members, what if every member were encouraged to yearly reaffirm that they wish to remain on the decision making body (with an off-boarding procedure then made available for any member who wishes to no longer work on the project).

Some of the other language here feels like it needs to be softened to match your suggestion’s tone. Drawing from your description of the intent, “encouraged” as a replacement for “required” would make this softer. This would encourage the cultural value of engagement(via voting), without making it a hard requirement.

All members of a decision-making body are required encouraged to participate in at least 2/3 of formal votes of that decision-making body per calendar year (teams can decide how to account for the specifics of this in low-activity projects, etc.).

[mpacer]

There are many ways to engage that would be good to recognise and encourage. Observing and giving voice to one’s perspective can be an excellent way to be engaged. For others, doing so may be difficult (and expecting that would put them at a disadvantage).

To inclusively encourage engagement, it would be good to recognize and encourage members to engage in the ways that work best for them, whatever those be.

[ivanov]

I have been conflicted about voting on this proposal. On the one hand, I do not want to vote "No" so as to not impede any efforts and the hard work that so many people have put forward over the last three years. But I am also uncomfortable voting "Yes" for this, because I don't believe the problems with this body stemmed from a lack of clarity about how it ought to operate, but from a lack of participation, enforcement, or course correction for the governance in practice. It is unclear to me, for as much as the project has grown, if we can reasonably expect to reassemble a coherent whole out of the subprojects marching at different rates and in different directions. I worry that the dysfunctions and failure modes of the current governance model will simply transition in a scale free manner to the newly formalized subproject governance, and we will end up with a fractal version of the current problems.

I'd also like to observe that besides Fernando and Brian, who have been working on the new governance model, the other people with the longest history with the project are abstaining from a vote (Min, Thomas, myself, and Matthias). I cannot speak for them, but for me, this abstention does not reflect a waning interest in the project.

[SylvainCorlay]

I just wanted to be a positive voice and to thank everyone involved in the governance refactor.

This is the outcome of three years of hour-long weekly public meetings. I could not attend all of the calls and I can only be admirative of the perseverance of @afshin, @ellisonbg, and @fperez. (Special kudos to @afshin who has been attending these late meetings on Friday evenings). So much work and thoughts went into this.

I am optimistic this new governance with help the project and the community in countless ways.

[Carreau]

I'd also like to observe that besides Fernando and Brian, who have been working on the new governance model, the other people with the longest history with the project are abstaining from a vote (Min, Thomas, myself, and Matthias). I cannot speak for them, but for me, this abstention does not reflect a waning interest in the project.

Apologies, I tuned out with the shear amounts of comments. I tend to recognize some of the points Paul made in how I feel, though I don't want to block other. If I didn't had the time to participate then it's also my fault and I shouldn't block other to try what they think will be progress.

So Approving.

And like anything once the new process is in place it can be ammended.

[blink1073]

Thank you @mpacer for opening the discussion around the inclusiveness of a minimum required participation. Let's continue the discussion in #106 as a follow up since this vote has concluded and we have not yet finalized the new model in its entirety.

With 11 recorded "Yes" votes and 6 unrecorded votes, let's merge and iterate.

Thank you all!

[choldgraf]

FWIW - I agree with both @ivanov and @mpacer's intuition that this change will not be a magic bullet that fixes governance within the project and it does not address some big challenges around making our decision-making more inclusive. Though, I do think that this is an improvement that does a couple of things:

• More accurately reflects the current governance structure of the sub-projects
• Makes some implicit structure more explicit
• Is a step towards standardizing practices around governance and communication across sub-projects
• Is a step towards making some expectations and responsibilities more explicit so that we all know what responsibilities come with decision-making roles.

I think there's still a lot to do, and ultimately improvements will need to happen over time as these structures are actually put into practice. I'm hopeful we can continue making progress.

[willingc]

Thank you @afshin for persisting and driving for so long. Awesome to see Milestone 1: A Foundation completed.

@ellisonbg @fperez Congratulations on stewarding this document and its principles for formalizing the other documents.

All steps in the right direction. Thanks!

[meeseeksmachine]

This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/governance-office-hours-meeting-minutes/1480/152