@gunner thankfully pointed me to this forum when asking his opinion of a governance draft we just put up for a (set of) presently still reasonably small FOSS project(s) that we’d like to see grow somewhat. The goal behind our governance draft is to allow the current small team of maintainers (1-2) and committers (5-8) to gradually hand things over to a larger and more commercially oriented organization (Linux Foundation) without immediately alienating or disowning non-corporate maintainers and committers by this change.
So may I ask this group’s opinion(s) and feedback about the proposed GOVERNANCE.md (also under discussion at github) ?
Anything glaringly bad/harmful in the long run? Any suggestions for improvements? Side note: Our aim was to keep it simple – we appreciate that large projects have very detailed governance procedures – but our project still is small and governance should not be larger than our code base
I also recommend having a way to involuntarily remove committers and maintainers in the case where something very bad happens (code of conduct violations, destructive behavior, etc.) Hopefully, you’ll never need it, but now is the time to put it in place just in case. For CNCF projects, we use this language:
Removing a Maintainer
Maintainers may resign at any time if they feel that they will not be able to continue fulfilling their project duties.
Maintainers may also be removed after being inactive, failure to fulfill their Maintainer responsibilities, violating the Code of Conduct, or other reasons. Inactivity is defined as a period of very low or no activity in the project for a year or more, with no definite schedule to return to full Maintainer activity.
A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers.
Depending on the reason for removal, a Maintainer may be converted to Emeritus status. Emeritus Maintainers will still be consulted on some project matters, and can be rapidly returned to Maintainer status if their availability changes.
This looks plausible as a default framework for roles and responsibilities, along an attendant framework for decision-making by vote. I’d be eager to hear how it reads from the perspective of other developers with experience in small collaborative projects.
A couple of quick reactions from this non-developer who sat in a bunch of conversations about this stuff across various SustainOSS events:
What I’d normally expect in a governance framework – and don’t see here (maybe it’s established elsewhere in your documentation?) – is a statement of purpose, scope, etc: what is the project for?
I also tend to look for statements of values + principles of some kind. That said, I don’t assume such statements are strictly necessary for a minimally viable governance model; I would expect they’d be likely to emerge as a project scales (cuz without them, it can be difficult to build consensus around additional agreements as the need arises), but this document contains instructions within it that specify how such statements could be proposed and incorporated in the future.
Last immediate thought is that we often heard at SustainOSS events that projects often need ways to engage and empower non-coders: i.e. users, contributors of valuable inputs-other-than-code, etc. Such needs may be associated with larger projects than you have in mind, so I don’t have any immediate suggestions here.
I just suspect that these latter two points relate to each other and might be worth further consideration. This framework doesn’t seem obviously flawed in the abstract for small scales, it does carry some programmer-centric assumptions that might constrain a project’s evolution at larger scales. Well-articulated values/principles statements could lay the conceptual foundation a project needs to grow into a future when voting-based decisions among code contributors might no longer be sufficient for healthy and equitable decision-making.
The GOVERNANCE.md looks nice and quite complete. I’d say that it’s already better than the majority of indications in an average project
Some ideas that come to my mind while reading (please, take them as such: ideas):
Things that are quite clear are (1) role types, (2) role relationships, (3) how to change roles, and (4) voting mechanisms. While roles are maybe the most common thing found in governance indications, the rest of the elements are rarely defined, so it’s nice to find them there.
As @greggish comments, roles may also be more specific about non-coding stuff.
Time-related indications are a bit hard to get. I think it would be nice to better indicate the time a PR/issue may live until a decision is made. Right now, I think that the reader has to combine info from the “Voting” section and the rest of the document (and also cross data with CONTRIBUTING.md).
I wonder if it would be interesting to describe how the own governance could be changed (kind of meta-governance level). In any case, this could also follow the typical code contribution process.
Some time ago I collected some best practices and recommendations to create projects on GitHub (including a light proposal for GOVERNANCE.md), which may also serve as inspiration.
Great to see more folks thinking seriously about governance for the future!
Another set of guidelines to consider for borrowing from / contributing to is the MVG - Minimum Viable Governance docs setup by Justin Colannino at GitHub. There are hopes to turn that someday into a turnkey “do you want your new repo to come with governance suggestion?” docs.
Thanks, @jlcanovas for the feedback! The “non-coding” stuff is deliberately left out for two reasons: 1) The goal of the file is to be as concise as possible (for self-governed development) and 2) non-coding things are “taken care” of by (very extensive) rules and regulations defined by the Linux Foundation that is about to take over our project (guess who isn’t happy with this Finally, the proposed “meta-governance level” IMO is taken care of by the statement changes to this document is subject to voting.
Thanks for the feedback @geekygirldawn . Your proposal(s) have been incorporated by a github commit (the link of which this UI prohibits me from posting – sorry.) Please let me know if I didn’t catch some of your thinking fully.
@greggish Thanks also for your feedback. Some of the same thinking I wrote before also applies here: The more high-level things (purpose, money flow, funding control, licenses, etc.) are done in (pretty elaborate) separate contract(s) that define(s) the cooperation between the corporate entities taking over the project. This GOVERNANCE.md file is meant to codify the “rules of engagement” for people doing actual work, including, particularly independent contributors not primarily subject to “corporate shareholder value” (“aligned” via salary) but their conscience and/or the wider community benefits of working on FOSS… Yeah, I know, communism at work
@ShaneCurcuru Thanks very much for this pointer. I wish I had this earlier. Are you aware of project(s) that have adopted this or is this still work in progress? The two tier process in principle is exactly what we’re looking for – but then again, the STEERING_COMMITTEE part is something LinuxFoundation already has text/procedures for that I figure will be hard to change (guess who got his nose bleeding from repeatedly proposing changes to “standard LF procedures” that “are too hard to change”?).
