Update governance model

[grst]

As our team grows, we want to update our governance model to accomodate both developer and community roles in the core team.

TODOs

• @ivirshup: send around examples of other governance systems
• receive infos from numfocus

Related PRs

• Prepare core-team roles for adding more core-team members #47 (initial suggestions by @grst)

[ivirshup]

Lets try and do the actual conversation at the hackathon, but some preparation before.

[grst]

@ivirshup what preparation did you have in mind?

[grst]

@scverse/core, summarizing what we discussed at the munich hackathon

Things we (sort-of) agreed on

• core team members are split in subteams that organize themselves (for now "community" and "developers")
• smaller governance team. Both community and dev-team send representatives to the governance team. Responsibilities:
  • funding
  • keeping the shop running
• We'd like some level of rotation in the governance team
• The steering council remains as a last resort for solving conflicts (maybe find a better name)

Things that need further discussion

• clarify roles of governance vs. community vs. developer teams
• size of the governance team
• rotation cycles of governance team members (term duration? can someone be re-elected?)
• How is the governance team determined?
• Who can attend governance meetings? Is it necessary to restrict voting rights in governance meetings to current incumbents only?

[Zethson]

Some thoughts:

1. It was important to me that people that invest time into scverse get recognized for it somehow. "Job titles" was one suggestion. That's what, for example, Nucleate does.
2. I think that a process where every core member that would be up for a governance team position would be thrown into pool from which we randomly select for 1 year is better than voting people in or out.
3. We could consider having diversity criteria for the governance team if possible.
4. We should consider having 1-2 external people that act as "safety officers". Basically external people that are not council or governance team that deal with harassment reports and similar issues.

[ivirshup]

I think that a process where every core member that would be up for a governance team position would be thrown into pool from which we select randomly for 1 year is better than voting people in or out.

Python does nominations and term limits for rotation.

I don't think someone should be "randomly selected" for this. It's a bunch of work to just randomly assign.

We should consider having 1-2 external people that act as "safety officers".

I think NumFOCUS can help organize/ provide this for us

[giovp]

I agree with all the points above but I wonder if, regardless the implementation of who takes part in the governance model, the time commitment is too long. I would be more in favour of a 6 months time limit, that could nevertheless be renewed. Wdyt?

[grst]

I don't think someone should be "randomly selected" for this. It's a bunch of work to just randomly assign.

You'd still need to be willing to contest to be among the list of potential governance team members. Random choice would just replace the election process.

We should consider having 1-2 external people that act as "safety officers".

I think NumFOCUS can help organize/ provide this for us

That would be amazing!

I would be more in favour of a 6 months time limit, that could nevertheless be renewed.

Happy to go with shorter limits. What do you think about imposing a limit on how many consecutive terms (one or two) one can serve? This is also a guarantee that one gets the chance to step down at some point without feeling guilty.

[Zethson]

I personally think that 6 months is too short. If people join the governance team that weren't as involved as all of us, it'll take them quite some time to get up to speed. That's like only 6 governance meetings!

[Zethson]

I don't think someone should be "randomly selected" for this. It's a bunch of work to just randomly assign.

What @grst answered here. Also, organizing proper votes would be a loooot more work to ensure that it is transparent etc. I'm convinced that picking people randomly (of the pool of people that signed up for it!) is less work.

[ivirshup]

This is also a guarantee that one gets the chance to step down at some point without feeling guilty.

Uhh, pretty sure this is antithetical to our mission and origin. Guilt based motivation is a key driver of open source development.

[Zethson]

Guilt based motivation is a key driver of open source development.

I am confident that there are better sources of motivation :) What you're describing can enforce discipline.

[ivirshup]

I am confident that there are better sources of motivation :)

Yeah, but we don't have gobs of money

[giovp]

I personally think that 6 months is too short. If people join the governance team that weren't as involved as all of us, it'll take them quite some time to get up to speed. That's like only 6 governance meetings!

on the other hand, this fast turnover enables more people to be exposed to such process/task and understand whether it suits them + enables flexibility for sitting governance members. I think faster turnover has really the benefit of increase diversity and exposure to/from the community, and also improve processes (e.g. streamline joining/leaving governance). I can see that it might have a detrimental effect on decision making and vision but I think the chances are quite smallas for big/long term decisions we'd probably want to have a solid community/devs support regardless of the sitting governance members.

[Zethson]

@giovp totally fair arguments, but I still lean more on my side thinking that the benefit of experienced people making decisions (we'll hopefully always have a few newcomers in the governance team) outweighs the "flexibility".

Interested in what the others think.

[ivirshup]

What does the governance team do? They'll do some funding stuff, but I would imagine in practice most funding decisions should be made by the sub teams.

I feel like the biggest value of governance is coordination across sub teams without have members of all teams have to join a meeting every couple weeks.

that the benefit of experienced people making decisions

I think there's also value of institutional knowledge around this stuff.

But, I would like to really figure out what he governance team can do. As an open source community decision making tends to be pretty decentralized. It's ultimately a do-ocracy. So I don't want to overstate the power a governance team would have.

enables flexibility for sitting governance members

Flexibility is good, but I'd also say commitment is even more important for someone in a role with more power.

Ideally we hit some balance

---

Off the top of my head I would propose something like: governance team is the chair and co-chair from each sub team + steering council. One of these positions could cycle more quickly, but tbh probably leave it up to the sub team. We can make some rule about amount steering council and these roles can overlap (maybe a little, maybe none).

[grst]

@giovp totally fair arguments, but I still lean more on my side thinking that the benefit of experienced people making decisions (we'll hopefully always have a few newcomers in the governance team) outweighs the "flexibility".

Interested in what the others think.

I think that higher turnover + term limits is more sustainable long term as it insures more new people getting involved for two reasons:

• newcomers will feel intimidated to take a governance team role and feel they'll never be good enough to "replace" any of the experienced members. If some of the experienced members must step down from the governance team for a while due to term limits, this opens seats for newcomers.
• Some community members might feel more inclined to give a governance role a try if they don't have to be afraid they can never get rid of the job again.

I think there's also value of institutional knowledge around this stuff.

Just because an experienced member is not on the governance team for a while, doesn't mean they can't be asked for advice.

[mikelkou]

All seem valid points to me with pros and cons. I would be more in favor of what Lukas said about yearly rotations. This make sense practically IMO, as it ensures that elections or random selections will consistently occur in a designated month, say July, and outgoing members have until September to transition (I am saying random months). Also having a bit more time to adjust makes more sense I think, even in terms of recognition. Being a governance member for year, e.g. 2023.

I also agree with Isaac. It needs to be very clear what the role and the tasks are. It sounds more scary than it is probably.

[grst]

I also agree with Isaac. It needs to be very clear what the role and the tasks are. It sounds more scary than it is probably.

With some help of GPT4, I reviewed all notes of the past governance meetings. Here's what we have been handling in governance meetings in the past:

1. Discussions about processes and governance structures
   • governance structure
   • processes such as "spending money", onboarding, offboarding
2. Events and conferences (-> will be mostly handled by community team in future)
3. Package development (-> will be mostly handled by dev team in future)
   • API discussions
   • new packages such as anndata-io, IO/dataloader package
   • review of ecosystem packages
   • data structures
   • cookiecutter template
4. Funding
   • interactions with Numfocus, CZI, ...
   • grants
   • pushing PIs for funding
5. Community and Outreach (-> will be mostly handled by community team in future)
   • community meetings
   • teaching initatives
   • social media
6. Misc
   • paper
   • Organize meetings with adisory board and management committee

Given that most of this is delegated to the dev/community teams it essentially boils down to

• general directions ("we should do X/have more Y")
• define processes
• interactions with other institutions and PIs/advisory board
• funding

[ivirshup]

Governance models from similar communities

Bioconductor

• Technical advisory board: https://bioconductor.org/about/technical-advisory-board/
• Community: https://bioconductor.org/about/community-advisory-board/
• Working groups: https://github.com/Bioconductor/BiocWorkingGroups

One thing I would note here is that at least the technical team has resonsibilities about funding in their description.

There is a "core team" which has members from multiple groups, but unfortunately no documentation that I could find.

nf-core

https://nf-co.re/governance

Pangeo

• Governance doc (mostly about steering council)
• Working group schedueles
  • A little unclear to me who is on these working groups or how they are defined

Unfortunately, I don't think there is very centralized documentation on this. I know they are doing a bunch, but unclear to me how it's all organized.

Astropy

• https://www.astropy.org/team.html
• Their coordination committee is I think closest to what we're talking about here

Python

• Governance PEPs
• PEP 8016 – The Steering Council Model

[gtca]

We could frame this governance model update as a purpose-driven change, and my impression is that it makes sense in order to accommodate a larger core team while also keeping the discussions reasonable as not impede the decision-making process. For the latter, binary votes and raising objections don't seem to be the issue as those have been done asynchronously. So the purpose is to handle a potential future influx of people in relation to keeping discussions productive.

The governance/dev/community split seems reasonable as already discussed on multiple occasions however I am wondering about the topic and responsibility split between those entities. For instance, so far it seemed sensible to conduct the governance meetings with the developers/maintainers of core packages as these packages seem to be the kernel of the consortium. The new model should either (a) explicitly move some of those interactions to the dev meetings or (b) keep core packages developers in the governance team. The former would thus repurpose the governance meetings as they are now (probably related to some of the @ivirshup's comments above), the latter would mean we could be inviting people to participate in the core scverse matters with intention, be it development, community, governance, or any combination of those. The former has an added bonus of immediately relieving [at least some of] the core maintainers from the governance overhead however the latter might help us to achieve the same objective in a more sustainable form. Thus I wonder if the latter is a more organic change at this point.

Moreover, this discussion can have more moving parts if we consider people specifically hired through scverse to fill one of the many roles we have, e.g. funding or event management. This might develop into a separate discussion on roles somewhat akin to what @Zethson has mentioned above but I don't think we are there yet.