Governance Questions 1: Community

Meta Governance
1

Hi everyone!

We’ve been listening to community input (thanks everyone!!) on how to make our process of working through the governance refactor more open and easier to engage with. A while back we’d posted a list (What questions does a new governance model have to answer?) of the main questions we’re using to organize our thinking, but as evidenced by the lack of response to that post, a giant pile of complex questions in one shot isn’t very conducive to useful conversation :slight_smile:

So we’d like to try a different approach: we’ve broken down those questions into 5 broad categories, and we’d like to make a small post each week, alongside with our meeting minutes, that includes just a few tightly related questions for input/feedback, and that includes our own summary of where things currently stand on that area in the project. Note that our summaries are fairly informal and in the interest of not stalling, we’re drafting them together in our weekly calls (that are open to all!) and posting them here right away. That means we may miss important points, other long-standing members of the project may disagree, etc. That’s OK: we want to move forward, open each week a reasonably scoped conversation, and invite all to participate.

If we follow this schedule, through the next 5 weeks we’ll be able to go through all 16 organizing questions. This will both help us organize our own thoughts and gather community feedback, which along with other mechanisms we are using (such as in-depth interviews with some community experts from other projects) will help us assemble initial materials for a draft.

We hope this helps everyone feel more included and welcome to participate, and we continue to listen for ways in which we can make progress while engaging all. The first few questions are listed below, roughly categorized as “community engagement”. Below is a summary of our status and thoughts on these. Next week we’ll continue with a different topic.

We would love your input, and we would especially love to hear your thoughts about successes and failures you’ve seen in other organizations in these areas. In your experience, what works and what does not in these areas of a project?

The notes here are the collecting thoughts of the people on this week’s call and we haven’t attempted to consolidate, summarize, or unify the thoughts. This is to encourage exploration, so having a diversity of thoughts and experiences is helpful.

Governance Refactor Editors in Chief, Brian and Fernando

Community Engagement Questions

How do we make governance transparent to the community?

  • Currently, governance documents are public documents on GitHub, and governance changes are discussed and approved on public GitHub issues.
  • The steering council mailing list is somewhat of a black box to others. At times we have attempted to regularly summarize the sort and number of discussions happening on the steering council list for the community, but we haven’t maintained these updates. In general, there are far fewer steering council discussions that most people imagine, and mostly mundane things like notifying the council of public blog posts or public governance issue votes, every now and then a trademark issue, etc.
  • We want to significantly improve our mechanisms for community engagement and open communication. For example, we’ve discussed often switching away from a private mailing list for the Steering Council, but inertia and lack of time/resources kept things as they are. The recent use of Discourse has helped in that front, as more and more governance-related conversations now happen there instead of on the steering council mailing list.

How do we include and protect minority voices in governance decisions?

  • We currently have a code of conduct that strives to set the standard for an inclusive discussion. We have an email account for reporting incidents, and we nominally have a several people checking that email box and bringing things to the steering council as needed. However, we don’t have a formal regular reporting mechanism for the code of conduct committee to report to the steering council regardless of CoC requests.
  • The current steering council has some diversity, but could use a lot more diversity of people and viewpoints.
  • Most decisions in the project are not made by voting, but through consensus, which in some cases can be more inclusive than pure majority voting.

How do we actively prevent implicit power dynamics or availability of resources from bubbling up and overtaking official governance?

  • Most technical decisions on repos and orgs are made by the informal consensus of the contributors who are involved in that area of the project. These decisions include:
    • Code review, security, and testing procedures
    • Collaborators on a project
    • Release decisions and timelines
  • We have over 100 GitHub repos across ~6 Github orgs. These orgs and repos mostly self-govern through consensus. While this works locally, it makes cross org/repo work and communication challenging.
  • We don’t have explicit mechanism for addressing implicit power dynamics or preventing a group with high availability of resources from overtaking official governance.
  • Some of the most influential and powerful people in the project don’t have formal, commensurate roles.
  • We appoint people to the steering council, not reserved seats for organizations. This ensures that we have personal trust and vetting of individual people and their vision of the project, rather than outsourcing our trust and vetting to an organization.
  • We have a very high bar for consensus for governance document changes (80% quorum, ⅔ approval) - this implicitly helps prevent a small group taking over the governance. In practice, sometimes this bar is relaxed, with the understanding that if there is an issue, we can revert the relevant changes.

How do we manage gridlock and inertia so governance does not impede progress?

  • Re “tyranny of resources” and gridlock/inertia: we don’t have great mechanisms to address either of these, but we’ve recognized them to become more pressing issues as the project grows larger, more complex and with more disparate stakeholders who differ greatly in needs, interests and resources. These issues don’t manifest themselves as much in smaller open source projects and can be perhaps ignored for a while, but are now key drivers of our future thinking about governance.
  • Gridlock: We are often gridlocked, in that steering council proposals stall without active discussion. This has particularly become an issue as the steering council has grown larger. We have a very vague notion of “consensus” for decisions, but often we have just a few steering council members participating. We also don’t really have a formal procedure for calling for a vote, and any steering council member can put a decision before the group without any sort of vetting. Sometimes we overcome the gridlock by phrasing questions as “we’d like to do X, please comment if you object”, and if there are at least a few votes in favor with no objections over a few days, we assume there is consensus. We are also inconsistent about what gets brought before the steering council - for example sometimes giving someone commit rights is brought before the council, but often it is not and is just done as a decision between a few subproject maintainers. Basically, if one person feels it is important to get council approval, it goes before the council. But others may feel the same thing does not require council approval, and will just proceed.

Again, we would love your input, and we would especially love to hear your thoughts about successes and failures you’ve seen in other organizations in these areas. In your experience, what works and what does not?

4 Likes
3

Some ideas below. I tried to keep it somewhat brief but failed. Yet a lot of nuance is missing :-/ So take things with a grain of salt and as a starting point not a final position set in stone.

For the purpose of this post I will assume that some form of steering council exists. It consists of a small (single digit) number of elected members. The steering council has authority to make decisions about the project, e.g.

  • enforce and update the CoC
  • work with Numfocus to manage the project’s assets
  • delegate parts of its authority to subcommittees or processes

The council seeks to use its powers as rarely as possible. Seeks consensus amongst its members and with the core team before exercising its powers.

How do we make governance transparent to the community?

If I had to sum it up in a short sentence I’d pick: As much transparency into processes, decisions and general going ons as possible. This is less about policing the decisions or those involved in governance and more about showing that there is active governance and that rules/processes are applied consistently and equally.

I like GitHub - carpentries/executive-council-info: Information from the Executive Council as an example of this in terms of making the process transparent. You can see how things work, that governance is active, what is expected of people, etc.

The council is like the board of a company. They meet regularly but don’t get involved in the day to day. The day to day is handled by the management.

How do we include and protect minority voices in governance decisions?

Create a new entity: the core team. The core team is a group of volunteers who manage the day to day activities of Project Jupyter. Members have authority over Jupyter infrastructure including the websites, the GitHub organisations, the forums, mailing lists, server infrastructure, etc.

New core team members are created by a vote of the core team (simple majority of votes).

The council could delegate its authority to enforce the CoC to a committee. It could also delegate treasury or other tasks. This is a chance for people to get involved. Get more voices heard and spread the large amount of work that needs to be done over more shoulders.

Council members are elected by the core team every ~18months. This creates lots of reasons for people to be actively involved in governance. As a core team member who wants to exercise their right to vote I want to be informed about the going ons. As someone who wants to stand (and get elected) I am interested in showing my good work, figuring out what is in demand (and what isn’t).

In the company metaphor the core team is the management.

How do we actively prevent implicit power dynamics or availability of resources from bubbling up and overtaking official governance?

The project only moves forwards because people spend effort. The amount of effort available to any one individual is limited. Those who choose to invest some of their scarce resource into the project need to be rewarded for doing so. One consequence of this is that those who don’t invest lose influence. Another consequence is that every single person has to work to gain and maintain influence.

It also means processes have to be setup to suit those who invest their effort, not those who don’t. For example a short time limit on votes, expectations around response times and effort required to fulfil a position like council member or serving on a committee.

For the council explicit rules around maximum membership based on the employer of individuals are a good idea. For example “no more than two members from one institution. If this rule is violated because of employer changes during a term council members have to resign.” One thing to ponder is sub-contracting relationships. When does a sub-contractor count as “employed” by their client?

If the official processes can’t be applied consistently they will be overtaken by informal processes. This is why they need to be biased towards those suiting those who are investing effort. It also means they have to be applied without exceptions. This seems bureaucratic but it forces the processes to be useful. Once one starts making exceptions in the interest of “speed” or to accommodate those who don’t have effort available everyone will want to have an exception made for them.

Due to the size a federated model of governance that delegates power to sub teams is what has been happening in the project and is how large organisations (from companies to countries) are run. Authority and responsibility are delegated to scale.

The project is formed of people who trust and respect each other, not code or GitHub organisations, etc. This means that organisations can not be elected or vote or become a member of the core team, only people can.

Gridlock

Creating expectations around the effort required to hold a post and rewarding those who invest effort in the project will encourage people to do just that. For example if a frequent cause for friction is that people who need to decide something can not do so within the time frame allocated then work stalls or informal decisions are made. A consequence of having clear expectations and giving people feedback on how they are doing with regards to them is that it will be obvious to everyone involved when someone should seek to find a replacement for themselves (e.g. council member who doesn’t find time to vote while a vote is open) or when authority&responsibility should be delegated (council notices they are overwhelmed with requests of a certain type).

Clear processes that are used without exception reduce the variation in some things being decided by one body one day and someone else another day. There are also many things for which the “clear process” can be “there is no process, just do it somehow” because it doesn’t matter. Other tasks need a more rigid process because mistakes are harder to fix or of great consequence.

Processes that are transparent, create expectations and are applied with no exceptions.

5 Likes
5

Tactical

  • Maintain a meeting calendar
  • Post agendas for meetings > 24 hours ahead
  • Post minutes/reports out of meetings in a timely manner

Strategic

  • Document which types of decisions will made by which entities
  • Document the finances, funding, and projects which the governing groups have accountability and stewardship for
  • Create and use a JEP process for changes to standards and foundational projects (messaging spec, APIs)
3 Likes
6

Tactical
(These are critical for participation by members who represent a minority since free time is often very limited due to other external expectations as advocates and role models for the minority group.)

  • Provide meeting agendas in advance of meetings
  • Publish minutes
  • Proactively solicit feedback from minority voices
  • Understand why minority groups are not participating

Strategic

  • Choose a governance structure that encourages and includes minority voices and intersectionality in leadership
  • Recognize that, for a minority group, decisions made by consensus often have the same outcome as majority voting
3 Likes
7
  • Tightening up meeting processes (regular meetings, agendas, minutes, and public calendars)
  • Time and effort must be devoted to keep the meeting processes running
  • Administrative support for meeting agendas and minutes reduces the burden on governing members
  • Recognize and accept that Jupyter has outgrown the ad-hoc governance of a small open source project.To be sustainable at Jupyter’s size, look toward more predictable and mature processes
4 Likes
8

Just reading through the responses so far from @willingc and @betatim, just wanted to note that I totally agree w/ what they said :slight_smile:

I’ll just give a quick response from my perspective for each section.

How do we make governance transparent to the community?

As Carol mentioned, I think putting effort into making agendas and meeting notes high-quality and public would go a long way. A very minimal thing is to simply tell the community when a decision is made, and what that decision was generally about. I’ve had a lot of conversations w/ steering council members who say “there isn’t much that happens on the SC mailing list” but folks who aren’t on the list still don’t know that. It would even be helpful to have a weekly heartbeat of “no decisions were made this week, the SC mailing list did not discuss anything this week”.

For most decisions, a process like RFCs or JEPs would be great IMO.

How do we include and protect minority voices in governance decisions?

Beyond what others have said - another idea is to raise funds to pay for people’s time to work on the Jupyter Project, and prioritize those funds for individuals who aren’t usually represented in open source communities.

More generally - put resources towards creating a community culture that is not exclusionary of others, particularly with regards to public discussion and decision-making. Expand the CoC so that it’s not just about reporting major violations, but also about managing the tone and collegiality of interactions in the community.

Raise funds to pay for people’s time to do community work. In my experience, doing work that doesn’t result int PRs is less-visible, less-rewarded, and less-tied to your employers’ interest in the Jupyter project.

How do we actively prevent implicit power dynamics or availability of resources from bubbling up and overtaking official governance?

Make authority explicit, delegate it, and ensure that it is enforced. An early thing that a new governance body should do is decide on a process for creating new teams and giving them authority within their domain.

Ensure that the leadership of any new governance group meets a minimum level of diversity.

How do we manage gridlock and inertia so governance does not impede progress?

Delegation of authority also seems important here. The main governing body of Jupyter should not be making most decisions. Most decisions should be made by a sub-team that is given the authority to make decisions within a domain defined by the governing team and by following a process that the community accepts.

Put resources (people, or $ to pay people) into a role that has the responsibility to move projects / JEPs / etc forward, and to ensure sharing information about these processes, rather than implementing technical features. If resources for this aren’t available at the least would be describing a role that like this and asking each sub-team in Jupyter to fill it in a rotating basis.

4 Likes
9

I think you’ll like this PR :wink:

5 Likes
10

Fantastic!

4 Likes