Looks pretty good. A few thoughts. I've been looking over other governance docs including matplotlib, numpy, deep lab cut (which is based partly on napari), scikit-learn, and astropy (links are all to their governance docs). They are all similar in many ways.

I would recommend making it more like the scikit-learn one (depending on how you see the governance working).

Almost all start with something like:

The purpose of this document is to formalize the governance process used by the fastplotlib project, to clarify how decisions are made and how the various elements of our community interact.

They all share that (well, the majority). The next paragraph typically outlines what type of decision making you use. Is it a consensus-based community project (DLC/sk-learn/numpy but with wrinkles/), or does it have a bdfl model (matplotlib), where there is a final arbiter in case there is conflict?

Instead of heading 'leadership team' I'd suggest something like scikit-learn 'Roles and responsibilities' starting with contributors up through Maintainers and the steering committee or whatever it's called 😄

There is wayyyy too much stuff about voting on this doc, imo. This reads like a doc for a repo with like 100 contributors distributed across 10 complex modules, each with its own tech lead. I think you could simplify it. Maybe give a promissory note that you will add more details about how to add/remove people to these different 'roles and responsibility' categories in one year.

Also, do you really need this many people on the advisory committee? This also seems pretty heavy for something that is so young. I worry that you are going to crush this little sprout with governance loops.

I like that you defer to 2025 some things, but I'd suggest maybe putting off documenting every governance concern until later too. People visiting might be like "wut?" There are top-down governance strategies and bottom-up governance strategies. This comes off very top-down and while we know that it is good to have governance and not need it (than to need it and not have it), I think it might be a bit overthinking it for such a young repo with so few people involved right now.

I'm just brainstorming and open to further thoughts, and if others disagree I'm definitely willing to listen. I am going to be delving into this more right now so have a pile of things to read about this 😄

Note I'm not pushing against the really big picture stuff here, I think it's great! I'm more suggesting you scale back some of the minutiae and go more into the big picture, and cut some of the low-level details that likely won't matter much until much later when the project matures more.

The purpose of this document is to formalize the governance process used by the fastplotlib project, to clarify how decisions are made and how the various elements of our community interact.

That's a good idea thanks.

They all share that (well, the majority). The next paragraph typically outlines what type of decision making you use. Is it a consensus-based community project (DLC/sk-learn/numpy but with wrinkles/), or does it have a bdfl model (matplotlib), where there is a final arbiter in case there is conflict?

Ours is kinda shared BDFL (at least for now)? We state that there must be a minimum of 2 maintainers, and maintainers have veto rights.

Instead of heading 'leadership team' I'd suggest something like scikit-learn 'Roles and responsibilities' starting with contributors up through Maintainers and the steering committee or whatever it's called 😄

Leadership Team is the official name, that's how we registered with numfocus.

There is wayyyy too much stuff about voting on this doc, imo. This reads like a doc for a repo with like 100 contributors distributed across 10 complex modules, each with its own tech lead. I think you could simplify it. Maybe give a promissory note that you will add more details about how to add/remove people to these different 'roles and responsibility' categories in one year.

I think it's useful to have voting clearly defined?

Also, do you really need this many people on the advisory committee? This also seems pretty heavy for something that is so young. I worry that you are going to crush this little sprout with governance loops.

4 is a decent number? I don't think it's too many? Especially if voting is required.

I like that you defer to 2025 some things, but I'd suggest maybe putting off documenting every governance concern until later too.

Yea we can fill in more later, but I think it's important to have critical basic things in place for now. The most basic thing is having a way to make sure the code of conduct is followed.

I think it might be a bit overthinking it for such a young repo with so few people involved right now.

I disagree, this could grow rapidly over the coming year so better have it in place sooner rather than later.

Note I'm not pushing against the really big picture stuff here, I think it's great! I'm more suggesting you scale back some of the minutiae and go more into the big picture, and cut some of the low-level details that likely won't matter much until much later when the project matures more.

I think it's important to have the low level details with how to deal with potential code of conduct issues, since that's really a basic thing. We can add more big picture and other stuff later. Right now we have a solid minimal roadmap and there isn't really a need for more in the governance. Making sure the code of conduct is enforced is the bare minimum and this provides a mechanism for that.

Good points: I agree it is better to have these structures in place before they are needed rather than need them and not have them. It is also realistic to think think fpl will grow quickly in the coming couple of years, so now is a good time to get them sorted. In terms of numbers, I'll defer to you and Caitlin (though having an even number of people on the advisory committee could be problematic 😄 ).

At any rate: there's a picture of how FPL will grow and you've written this for the future not the current state, and that's perfectly reasonable. Also, you are explicitly shifting parts of this to take effect in a year, which is very reasonable.

Let me redial my concerns a bit in light of all that. One of my main reactions was "this isn't very welcoming" and I was thinking that governance should read like a CoC or contributors doc (it should make people want to be take on one of the roles from contributor up through maintainer up through whatever).

However, looking over the different docs, I think I'm probably off in that. None of the governance docs are particular warm and fuzzy: they get down to business pretty fast (the most welcoming is probably Deep Lab Cut but even that is pretty businesslike). Browsing through the different docs, I think the current document follows astropy most closely, which puts it in very good company.

A couple of minor things:
Maintainers: "complete understanding of the codebase" is likely an unrealistic bar, if you want maintainers or aspiring maintainers, moving forward. Maybe something about people who have displayed deep understanding of the codebase, and continued contributions through multiple channels or something? People will get that they don't become maintainers by making a PR to remove some whitespace 😆

Some votes are specified as requiring 60% vote of the maintainers. This would usually be fine for two maintainers (they can vote together), but one of the votes is for removing a maintainer. 🙃

Good document here:
https://opensource.guide/leadership-and-governance/

I've been reading a lot of these docs more closely. The ones I really like have, in addition to an overview of the roles, a separate discussion of the Decision making process that is actually made by these entities (e.g., 'lazy consensus model').

Whatever model that is chosen, I think that since you are discussing this now anyway, that it is probably a good idea to also get something about this squared away. The projects I mentioned provide a useful model of the different strategies. Almost all use a "lazy consensus" strategy (marked by lack of disagreement/lack of veto, not endless discussion and voting). Your current model seems to have lots of voting and explicit discussion, at least for certain types of decisions.

Note also having a bdfl is consistent with a lazy consensus strategy, since as a project grows the leaders typically don't want to be involved in every little decision (e.g., fixing a typo). I think the DLC discussion is pretty good about differentiating different types of changes where different types of decision-making can come into play. There, they say:

 Decisions (in addition to adding core developers and SC membership as above) are made according to the following rules:

Minor documentation changes, such as typo fixes, or addition / correction of a sentence, require approval by a core developer and no disagreement or requested changes by a core developer on the issue or pull request page (lazy consensus). Core developers are expected to give “reasonable time” to others to give their opinion on the pull request if they’re not confident others would agree.

Code changes and major documentation changes require agreement by one core developer and no disagreement or requested changes by a core developer on the issue or pull-request page (lazy consensus). For all changes of this type, core developers are expected to give “reasonable time” after approval and before merging for others to weigh in on the pull request in its final state.

Changes to the API principles require a dedicated issue on our issue tracker and follow the decision-making process outlined above.

Changes to this governance model or our mission, vision, and values require a dedicated issue on our issue tracker and follow the decision-making process outlined above, unless there is unanimous agreement from core developers on the change in which case it can move forward faster.

If an objection is raised on a lazy consensus, the proposer can appeal to the community and core developers and the change can be approved or rejected by escalating to the SC.  

Anyway I'm on a flight just some impressions. I'll approve whatever at this point 😄 .

This project is young and I think if you just allow the project to fluorish, and then in a year or two you do your best do codify the idealized governance and decision-making practices you have been following all along, then that is also a reasonable strategy. But since you asked.... 🙃

Hello, coming a bit late to the party. I will start with the disclaimer that I never wrote a Governance document, but I hope my suggestions could be of some help:

1. I would try to simplify the language and streamline using indentation as an organizer. One gets a bit lost in the many sections and in the information sometimes too detailed. Example:

Leadership

Core Team (Maintainers)

• Role: Lead development, have a comprehensive understanding of the codebase.
• Responsibilities:
• Members: Kushal Kolar, Caitlin Lewis.

Advisory Committee

• Role: Provide strategic guidance
• Responsibilities: Attend a yearly Roadmap meeting. Be available for conflict resolution.
• Members: Eric Thomson, Guillaume Viejo, Andrea Giovannucci, John Pearson.

Neutral Moderator

• Role: Facilitate conflict resolution without voting power.
• Responsibilities:
• Member: Reagan Bullins.

2. Define Terms: Clearly define key terms used throughout the document, such as "significant stake" or "strong expertise." So that any reader will have a clear understanding and be on the same page.

3. "Veto: Any vote can be vetoed by a unanimous vote within the maintainers." what does that mean?

4. Inclusivity and Diversity. Notice that the leadership is 5-2 males to women. Not that you need to solve it now, but would keep it in the back of my mind. Would you consider appropriate to introduce not only mechanisms for selections, but maybe also mentoring mechanisms of new contributors with the potential to join the leadership team?

5. Decision-Making Criteria. Do you think we may need adding criteria or guidelines on how decision-making could be beneficial, like how to weigh the impact of decisions on different stakeholders or considerations for the long-term sustainability of the project. Especially related to a future roadmap and the relative prioritization? I would say this is discussion for the first meeting, but if you have something in mind, I would draft it down.

6. Emergency Decisions. Outline a process for making decisions in emergency situations where convening the entire leadership team might not be feasible (I speak to myself, sometimes I need 2 weeks to get back to someone...). Specify who has the authority to make such decisions and the process for ratifying them afterward.

7. Transparency and Accountability. I would try to ensure that governance decisions, meeting minutes, and voting outcomes are publicly documented and accessible. This promotes transparency and allows the broader community to understand and trust the governance process. Relatedly, we should have a review and feedback mechanism in place for the community to provide feedback on governance and leadership, with the goal of keeping the governance adaptive and responsive to the community's needs.

8. Deadlocks. How do you solve decisions when there is a deadlock? There should be some tie-breaker mechanism. The neutral moderator can only facilitate the discussion, but is she a tie-breaker?

@kushalkolar Should we try to finish this up this week or next? I like what Andrea is suggesting in terms of simplifying how we define everyone's roles...much easier to read.

I think in terms of what Eric said, maybe we should reconsider how much voting is required. For example, approval by a single core maintainer is appropriate in terms of typo fixes or other small things.

@clewis7
I think next week?

As we discussed internally I think we should adopt a BDFL model with the two of us maintainers as BDFL, and the advisory committee being purely advisory without voting (at least for the next 2 years). The lazy consensus model of deeplabcut that Eric pointed out seems appealing too.

We've changed to a joint-BDFL system where maintainers have ultimate authority, and the advisory committee is only advisory. This makes the most sense since myself and Caitlin are the core developers and the project is young.

I have added @apasarkar to the advisory committee who has been doing amazing work with ImageWidget!

@EricThomson thanks! We adopted several things from DLC w.r.t. decision making and lazy consensus.

@agiovann Thanks for all your points! We've formatted/clarified things according to your suggestions.

Inclusivity and Diversity. Notice that the leadership is 5-2 males to women. Not that you need to solve it now, but would keep it in the back of my mind. Would you consider appropriate to introduce not only mechanisms for selections, but maybe also mentoring mechanisms of new contributors with the potential to join the leadership team?

Yea we will have to try our best to get better involvement when we're at conference etc. Solving this will take time.

considerations for the long-term sustainability of the project... future roadmap and the relative prioritization

At this stage there is a lot of low-level things that must be completed before we can start thinking about this. At this stage it's really best left to myself, Caitlin and Almar. We can start thinking about this next year.

Just checking in here to say that this looks good to me. I think (co-)BDFL makes a lot of sense at this stage, when maintainers have a much larger investment and much more is required of them to move things forward. Other procedures seem fine, especially since there are provisions to learn as we go.

I agree with John. This looks good to me. I have no further suggestions. 🚀