Please take a look at the following questions and answer them however you see fit. You can answer all or part of them, and either as a response to this thread or as a separate post to link to.
Community questions: Office holders
What are the terms (of office) for office holders?
How are office holders of each governing body added or removed, whether automatically, by choice, or by intervention?
What are the eligibility requirements for office holders? How are conflicts of interest handled?
Note - this post was edited by @choldgraf for structure and clarity
Individual contributors on repos/orgs have informal or semi-formal roles that typically do not have terms.
Members of working groups such as Inclusion and Diversity or Events tend to serve until they are unable to (no formal terms).
One negative of this is that people are often over-extended for some time before they take the initiative to step down from these working groups. There’s not a great, ‘graceful exit’ option on these teams.
How are office holders of each governing body added or removed, whether automatically, by choice, or by intervention?
For the steering council, we have a process that’s not automatically triggered for removing as mentioned above. The text of that reads as follows:
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 by the BDFL 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.
Moving to emeritus not being automatic allows for some human discretion, but also means that it is a little awkward to bring up and is not applied uniformly.
The current mechanism of retaining inactive steering council members can contribute to difficulty in achieving quorum and passing resolutions.
For subprojects, all positions are managed by the teams themselves. This gives teams autonomy, and doesn’t add any governance burden to the steering council.
It does create some divergence of practice - it’s not clear yet whether this divergence is useful, problematic or simply neutral.
It might be valuable to survey some of this across teams/orgs in a more structured manner and gauge with the teams to what extent it would be viable/useful to formalize and uniformize more these practices.
We haven’t created a uniform, predictable channel for reaching out to the community regarding participation in governing bodies, working groups, etc. So far these processes have been rather ad-hoc and guided by direct connections in the various teams (Steering Council and repos/orgs). It may be useful to make this more predictable; in particular the current ad-hoc practice is likely to reinforce all the biases of our existing networks/connections, making it harder for our community to grow in new directions.
Individual Contributors on repos/orgs. Different Jupyter orgs and repos add or remove contributors using a relatively informal approach that varies somewhat across repos/orgs. There tends to be multiple informal tiers of contributors that range from occasional contributor, frequent contributor, committer, leader. The more active repos/orgs (JupyterHub/JupyterLab) tend to have a more formal approach to this. Removing individual contributors from orgs/repos isn’t something that tends to happen. Instead, people go in and out of being active.
Working groups. We have a number of working groups on non-code areas of the project, such as Governance Working Group, Inclusion and Diversity, NumFOCUS committee, and Events (JupyterCon, JupyterDays, Community Workshops). The officers on these working groups tend be elected using an informal process that mostly amounts to “who wants to work on this" and sometimes steering council approval. Once the initial group is formed, the groups tend to operate with that initial group of officers. We have had individual volunteer to step down due to other commitments and we are inconsistent in how people are replaced.
What are the eligibility requirements for office holders? How are conflicts of interest handled?
We have a practice (not sure we have a written policy anywhere?) of disclosing COIs, job changes and similar matters in the Steering Council list, though that hasn’t been formalized across orgs, and probably should. Folks have always stated that they would recuse themselves from any decision that potentially involves their organization/responsibilities causing the COI.
We have never felt the need to enact any detailed COI management plan (akin to what states/federal govt have), thus far this model of explicit, early disclosure and awareness has been sufficient. This model matches what formal COI (state/federal) management plans often apply when the COI is considered reasonably mild.
Thus far, we have considered mostly a record of active participation in the project’s activities, together with a willingness to put in time, as the primary requirement. However, one of the key issues identified with our formal governance model is that the Steering Council in its current form conflates honoring highly productive project contributors with roles that require work and entail responsibility. Honoring/rewarding someone shouldn’t require much time commitment on their part, while asking them to do work for the project does, and this conflict of requirements is an issue we need to address as we revamp our governance.
For individual contributors to repos/orgs, there are few, if any, formal requirements. There are informal requirements, mostly focused around the potential contributor building trust with the team, making solid contributions, and being a good team player. Without a project wide, well documented mission, vision and values, the risk of this approach is that new contributors are brought on without us or them being aligned on the bigger mission, vision, values of the project.
Having a well-defined direction gives anybody holding a position in governance something to lean on when making difficult decisions. It’s very difficult to optimize without being explicit about what we’re optimizing for.
What are the terms (of office) for office holders?
This should depend somewhat on the position and sub-team that is being served by the office. What I’ve seen other projects do is to define the “cadence” for that particular team (e.g., if it’s a technical team, then a major release cycle, if it’s an ‘event team’, then some milestone for events) and circulate leadership and office-holders according to those natural checkpoints.
Either way, any official office should have a fixed term whereupon the person should either formally re-accept that position, or formally re-run for that position. This helps prevent the chance that somebody burns out or that the organization becomes too-dependent on a single person.
How are office holders of each governing body added or removed, whether automatically, by choice, or by intervention?
For a cross-cutting “steering council”-style office, they could be elected in staggered groups (e.g. if the SC is 6 people, cycle 3 people each year). For team-specific office holders the teams can decide what’s the best way to change office holders, with the constraint that they must have a process.
What are the eligibility requirements for office holders? How are conflicts of interest handled?
For the main project - something like an election could act as a means of vetting people based on the trust they have from the community (ultimately that’ll be a very important thing). Also, a past/current/commitment to future adherence to the Jupyter CoC, as well as a constraint on the number of people from a single institution that can serve on certain governing bodies.