search

scverse / governance

Governance docs for scverse
https://scverse.org/about
BSD 3-Clause "New" or "Revised" License
6 stars 0 forks source link

Update governance model #56

Open grst opened 1 year ago

grst commented 1 year ago

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

TODOs

Related PRs

ivirshup commented 11 months ago

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

grst commented 11 months ago

@ivirshup what preparation did you have in mind?

grst commented 10 months ago

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

Things we (sort-of) agreed on

Things that need further discussion

Zethson commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

Yeah, but we don't have gobs of money

giovp commented 10 months ago

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 commented 10 months ago

@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 commented 10 months ago

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 commented 10 months ago

@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:

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 commented 10 months ago

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 commented 10 months ago

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
      1. Events and conferences (-> will be mostly handled by community team in future)
      2. 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
      1. Funding
    • interactions with Numfocus, CZI, ...
    • grants
    • pushing PIs for funding
      1. Community and Outreach (-> will be mostly handled by community team in future)
    • community meetings
    • teaching initatives
    • social media
      1. 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

ivirshup commented 10 months ago

Governance models from similar communities

Bioconductor

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

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

Python

gtca commented 10 months ago

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.