Feedback on governance

[Carreau]

Hello All,

This follows some conversation that I had at SciPy, as well as some discussion that started on the steering council mailing list but we believe it is important to get this discussion in public.

I heard a lot of good things about our governance policy and our governance documents; at SciPy in particular, but also other event, or even on a day to day basis. In particular you will be happy to know that Matplotlib want to adopt the same governance structure, and is looking to roughly take our documents as is by just replacing Jupyter by Matplotlib:

https://github.com/matplotlib/governance/pull/1

I think though that some wording in the various documents and some details of the governance structure could be improved, mainly to convey better the spirit of the document.

The current governance document require people to have been "involved" in the project for a period of at least a year:

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

This is a perfectly reasonable requirement to be sure that the candidate have shown a long term interest to the project. I'm concern though that this is in practice biases toward technical contributions. We did explicitly make the language in the governance document vague, in order to include more people:

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

I think we can do a better job regarding this point by trying to get in the steering council members from various horizons and with often various vision for the project. I think in that long time user of Jupyter like Greg Wilson, Lorena Barba, Doug Blank, could be of great help in the council as they are regular users of the notebook and are in contact with people using the notebook on a day to day basis. I believe people like Gael Varoquaux, have extremely valid critics of the notebook in part because of they have to stay on Old version of the packages and upgrade often leapfrog in many versions. People have a wider-view of the project like Jamie Whitacre and Carol Willing would be extremely helpful as well,...

Thus I would like to try to emphasise the diversity of the steering council.

My personal though, is also that the steering council might be too large (or on the verge of becoming too large), and adds a lot of noise for each of the members. I would like to think about a "restricted board" that could make more non-sensitive decision without the all council approval. This does not prevent the board to request advice from council advisor, that could more technical in specific domain. I think in particular at people like Adrew Gibiansky Haskell), Philipe A. (R) , that have show longterm regular involvement in the project on highly specific technical points.

This leave also the door open to have a rotating board, which is smaller, and that could be picked changed at regular interval in order to relieve some of the board member from yet-another-task. The reduced board size could also likely resolve things more quickly, as it is often hard to get global consensus. How to select this board might also help address on of the other main comment I had related to the following point of the governance:

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.

This sounded for many as a selective private club.

I would like to see if we can experiment with asking the community to select members. For example on a 6 month basis, ask for an anonymous (?) proposal of someone who they think have an non-negligible impact on promoting helping with Jupyter.

One other point that I have heard a few time is that despite recognizing that the member of the council are extremely valuable to the project, the nomination process and the 1 year of involvement looks a lot like a reward for seniority ; not that it is, but I can completely see the reasoning from a quick glance at the process. The SageMath project does apparently have a specific distinction for long standing member. I would like to consider this as an option as well as it would clearly distinguish long-term technical and regular involvement from actually being part of the governance. I can also completely see people that would be happy to get a distinctions for being a long standing member, without wanting to be part of the governance.

Thanks

[jasongrout]

Thanks for bringing these points up. I've also had some concerns along these lines, so thanks for starting the discussion.

I think we would do well to make sure that recognition as a contributor in the community is separate from steering council membership, for several reasons:

A. there are many more people who deserve special recognition than could serve on a small steering council, and it won't scale as time goes on B. I think attributes that make an effective steering council member are not necessarily the same as the attributes to make an effective contributor (there are definitely overlaps, of course).

As @Carreau mentioned, Sage has a prize (http://www.sagemath.org/development-prize.html) to honor longtime contributors. I think having a Jupyter contributor award/prize is a good way to recognize a member of the community for outstanding contributions.

I also share the concern @Carreau has about the size of the steering council. Having a small rotating council also gives added incentive for the council to make issues public, since many former members of the council and many other relevant parties will not be in private discussions. I think staggered terms of one or two years would be appropriate.

Another issue that came up in our conversations at Scipy was transparency with discussions. Those on the steering council mailing list know that there are usually only a few email threads a month, but since the council list is completely opaque to the community, nobody else knows. I think it was @willingc or @Ruv7 that suggested that we have a summary of topics/discussions and/or conclusions every month (eliding sensitive material, of course) so that the community is aware of at least what discussions are happening.

[Carreau]

@willingc, @blink1073 you have both been across communities and across related to Jupyter, maybe you have some feedback ?

@nellev, I know that matplotlib might want to adopt our governance, and that you had to deal with community management. Your thoughts here would be welcome.

[blink1073]

I like the idea of separating governance from "key contributors", as it appears from the outside that the Steering Council is providing both functions at the moment.

Having a long-term team does provide some stability, at the cost of "group-think" and stagnation. I would be in favor of a smaller core team that is more stable, with a wider team that rotates. A year seems like a reasonable term.

I also like the idea of community nomination, which encourages transparency and may yield candidates that would not otherwise have been considered.

[willingc]

@Carreau One area that could be improved (which is an area that we have actively worked on improving in the PSF) is better communication from the council to the greater community. What sort of issues are discussed by the Steering Council? As an outside observer, I can only guess what the functions might be: decision making, project direction, funding, etc?

One downside with the current nomination process is it is likely biased to the majority makeup of the current developer community. It also heavily biases measurable contributions from development over other important, though less easily quantified, aspects of a healthy project (i.e. community engagement, outreach, education, etc.).

FWIW communication outward from the Steering Council could only improve transparency as well as community understanding.

[NelleV]

Hello, I don't have a strong opinion about any of these documents, mostly because I don't understand what the steering committee's goal and role is. I have always been in projects where most (if not all) the decisions were public and involved everyone, either by email on a public mailing list or by discussion on PRs. That has worked well for us so far.

[Carreau]

What sort of issues are discussed by the Steering Council? As an outside observer, I can only guess what the functions might be: decision making, project direction, funding, etc?

Here is a short list of things discussed on the council:

• Questions from company about the Institutional Partner Tier (usually someone that had a question from a company will ask it there if there is a reason to not be public, like saying the company name)
• Trademark questions:
  • someone want to use the "jupyter" name somewhere and request our permission
  • someone is using a confusing name we discuss about it
  • we have trademark questions, we for example post report from lawyer consultation there.
• Domain renewal/acquisition.
• Patents.
• Hiring at institution when we got the funding but not any publicly announcement ready yet, just as a courtesy for other member of the steering to be aware of it.
• Conflict of interest declaration

Most of these threads could have been stated in public, (and should be in the future). Many are "I'm going to say that on the mailing list, any opposition ?"

Hello, I don't have a strong opinion about any of these documents, mostly because I don't understand what the steering committee's goal and role is. I have always been in projects where most (if not all) the decisions were public and involved everyone, either by email on a public mailing list or by discussion on PRs. That has worked well for us so far.

Thanks for the feedback. We don't take much decision on this mailing list, we try to limit to sensitive subjects where some information are better to be kept there in rare occasion. In particular there is no technical decisions taken on this mailing list.

[choldgraf]

Reviving this thread because it is an interesting conversation so far! A few folks seem concerned about the size and/or structure of the steering council (that it is too large, and that it is biased towards its current demographics/fields/organizations/skills/etc). A quick question: did the community ever consider building in some "churn" into the steering council? Something to encourage people to leave the council, making room for others to join, but without feeling like they've "left jupyter".

E.g., 80% of council members could be brought on with one or two year appointments. When a council member leaves, they are replaced by another member of the community. Once your tenure as a council member ends, you must wait at least 1 year before you can re-join the council, at which point the cycle starts over. You can repeat this for as long as you wish.

Just curious if people thought about this at all, or curious if people think it could encourage more diversity (or more engagement) in our council?

[blink1073]

Hi @choldgraf, thanks for the thoughtful revival. I agree with your points, and have been speaking to several people about how we can move forward with the governance restructure. I hope to have something more concrete to say within the next week :smile:.

[Carreau]

A quick question: did the community ever consider building in some "churn" into the steering council?

It was at one point of of my proposition, but flipped on its head with "only X member being on the 'active board'". If you say "X%" and members come on go it is annoying as you need to adjust.