potential governance models

[ghost]

discussion about a potential governance model i suppose? should we keep the ctc structure? what kind of working groups should we establish? (should we establish any at all?)

[addaleax]

what kind of working groups should we establish? (should we establish any at all?)

My experience from Node would make me say “no” for now; what I’ve seen is that working groups need either explicit authority or trust from whatever governance bodies are above it, and I don’t think we really have figured either out ;)

(Maybe one: Moderation.)

discussion about a potential governance model i suppose? should we keep the ctc structure?

I’m biased but I actually do like it, or at least think it’s pretty okay.

The main problem with Node’s governance was lack of accountability imho, and I don’t quite know how to improve that with a different model

[zkat]

Personally, my ideal governance model is a cycling BDFL model where you choose different BDFLs every 2-4 years who act specifically as final arbitrators over project decisions, and who can be removed with a vote of no confidence by a community committee. Maybe complete the classic triad by having both a community-committee focused on people (guided by a CoC), and a technical committee focused on technical decisions and direction.

Sound familiar? Probably ;)

I think a BDFL-like figure is important to provide a consistent vision for a project and help align everyone -- you'll still have to do a lot of dealing and compromising at the technical committee level, and that should still do the bulk of the work. But sometimes you really just need someone to break you out of a deadlock.

[nebrius]

I like the ideas so far, including a BDFL like person. What do you all think of making it an elected position? More akin to a prime minister or something?

Another part of governance to consider is how people get added as collaborators. I'm actually pretty fond of the open open source model that Node.js uses.

[zkat]

@nebrius that's the idea, yes. Probably make it more like a PM where where they'll be chosen by the committees themselves rather than having to hold some fuzzy concept of a community-wide election lol

[zkat]

plus, it's those committees that will have to interact with the "PM" most

[Qard]

+1 for elected BDFL. The community and tech committees sound reasonable too, however I'd suggest community be above tech in power structure to avoid focus on tech over inclusivity. I feel like that's still susceptible to what happened today, without committee having power over tech.

As for working groups, I think we'll want to put a bit more thought into how to define those this time around. In Node.js, some groups like moderation or security are perpetually needed, while others changed their focus overtime--some to the point of no longer covering their original intent. For example, the docs working group began as a way to reorganize the docs, but never were granted the power to actually do what it sought to do and ultimately turned into a maintenance group overtime, which was really more a team than a working group. 😑

[varjmes]

I too say no WG for now. Let them pop up when there is a need.

[lewiscowper]

Is 2-4 years a reasonable lifecycle for a BDFL type person? Can someone who has been BDFL be elected as BDFL in the future, or is it a one-time thing?

[zkat]

@lewiscowper tbh I think it's fine as long as they're elected, and they have no back-to-back sessions? The point is to take advantage of the direction a single person can provide, but still benefit from re-aiming that energy with fresh leadership.

[zkat]

@Qard as far as WGs go? I think that's another example of the TSC/CTC failing to do what they said they intended to do: chartering WGs was... a process, and the TSC/CTC often tried (and succeeded) at retaining way more power than they were intended to have. The process, as has been described to me, was intended to make WGs near-full authorities over their corner of the project, with the TSC/CTC just crossing the I's and dotting the T's. They TSC/CTC are supposed to be handing over power to them.

To me, the ideal WG structure is similar to the relationship npm has with Node Core: It's our project, we use our own guidelines to develop it, we do the best job we can and very much are in the service of the Node and npm communities, with full good intentions in that regard -- but we operate purely by making PRs to the core project. TSC/CTC are free to reject or patch those PRs, we have discussions about what they'd like to see, etc.

It's not the smoothest road ever and there's occasional bumpiness, but I think it's allowed both projects to be maximally productive in our own little corner, without having to argue about every little thing (and, for us, not having to be constantly beholden to a committee that would insist on micromanaging our decisions). We even have completely different LTS policies and different resource availability, and we make it work. Small, independent packages are great. WGs as small, independent projects would also be great, imo.

If the docs WG had been its own, fully independent organization that managed everything involving documentation, even the website perhaps, and it operated purely on a release-PR basis: do you think that would have helped in that case?

[ghost]

the BDFL model sounds good to me. i'm fine with not creating any working groups (except for moderation maybe) for now and just seeing how things go. what would be important to me is the capability to change things about this governance model in the event that it doesn't work out, not like the nodejs tsc, which people have been trying to deestablish for like 2 years now

[addaleax]

Is 2-4 years a reasonable lifecycle for a BDFL type person?

It does seem a bit long to me.

If the docs WG had been its own, fully independent organization that managed everything involving documentation, even the website perhaps, and it operated purely on a release-PR basis: do you think that would have helped in that case?

Yes and no; it would have helped if it weren’t for the fact that, very often, doc changes need to happen at the same time as code changes, so working on a release-PR basis would have been hard.

[Fishrock123]

I would much prefer a committee to a BDFL, even if the BDFL elected, even for a short term.

Particularly for technical decisions I feel Node (or Node spin-offs) represent(s) too many people for one person to make accurate decisions for.

[nebrius]

I would envision this BDFL as being more like an Executive Director type. Someone who isn't really involved in day-to-day technical decisions. More of a "the buck stops here" person.

[aqrln]

One of the alternatives to having one BDFL for the whole project is having a set of teams with a clear separation of concerns and responsibilities (overall vision and direction of the project, technical decisions, moderation, etc) and equal power, each operating in consensus-seeking decision-making manner, but having its leader who acts as an final arbiter in the lack of consensus. Rust's governance follows a similar model.

I'd find this approach more scalable in the long term, but one-leader model may be more effective at the initial phase of the project.

@nebrius:

I would envision this BDFL as being more like an Executive Director type. Someone who isn't really involved in day-to-day technical decisions. More of a "the buck stops here" person.

Yeah, and I'd say let's find a more suitable name than BDFL :)
I am not that fond of the idea of a real BDFL, to be honest, the impact that it has on the community is one of the reasons I switched to Node.js from Python some time ago.

[nebrius]

Yeah, and I'd say let's find a more suitable name than BDFL

Agreed, there are a lot of connotations to the phrase. Some good, some bad, but it is nonetheless polarizing and implies things that probably won't be true here.

[Qard]

@zkat Yes, I believe the Docs WG needed more say over how the docs were handled. We were forced to keep our work within the code repo and within the existing tooling, which was very limiting for what we wanted to achieve. There was also ideas like code comment doc generation similar to Rust that were blocked immediately seemingly only because of style preference of a few TSC members.

As most of you well know, documentation is a critical need of open source projects and a multi-faceted problem that requires many forms of content to truly cover the needs of the end user. Node.js has always had very poor docs and the power structures in place constantly got in the way of doing anything about that.

[sandfox]

I suspect I might be a little under-qualified to be commenting/thinking-out-loud but nonetheless here I go:

• In general, there's a lot that seems to work with the way Rust organises itself, but I'm not sure how much of this is because of the qualities of the people as opposed to the quality of their process.
• I'm in favour of the least possible governance/structure as a starting point, but there absolutely has to be something, especially around conduct/moderation. Sometimes I felt that the endless WGs in node were pretty baffling to new comers and it was a little difficult to explain why all of them existed and how they helped.
• All of these structure/groups/coordination bring overhead and require peoples time and this places some bounds on what the project is capable of sustaining with the people it has.
• As others have said, a minimal BDFL who acts as a stalemate breaker seems like a good idea. For everything else I'd prefer some plurality of thoughts/views/voices wherever possible.

[Fishrock123]

Officially Chartered WGs: a good way to stall progress ™

---

Maybe complete the classic triad by having both a community-committee focused on people (guided by a CoC), and a technical committee focused on technical decisions and direction.

I would envision this BDFL as being more like an Executive Director type. Someone who isn't really involved in day-to-day technical decisions. More of a "the buck stops here" person.

I think I acted a bit to much in reaction - this sounds like it could turn out well. I think this is certainly a path worth seriously considering. I will think about it more and I hope others also do.

Yeah, and I'd say let's find a more suitable name than BDFL

"Elected Final Arbiter"?

---

Also I don't really want to discuss it in this thread but yes the Docs WG had limitations because they were not the only ones that had to work on the docs. 😕

[aqrln]

@Fishrock123:

"Elected Final Arbiter"?

SGTM

[ghost]

elected final arbiter sounds good to me

if we did elected verified arbiter (EVA) we could pull a nice evangelion reference ;)

[addaleax]

I like it, because even though it sounds like some video game final boss.

[zkat]

The WG stuff made me think of another reason why I'd like "WGs" to just be "external dependency projects" -- it would allow the Node project to get smaller, and I think smaller individual communities are better. They will be better able to serve their contributors and respective subcommunities, they will be able to establish their own governance structure, and it'll make any governance structure in the "central" project (the thing that glues it all together) much less important to get right, because it's overall just doing less and dealing with fewer people.

Perhaps one direction we can take this project is to explicitly start tearing out sub-concerns of the community and deciding we're just not gonna do the work ourselves -- someone else can take it.

Consider:

• LTS WG can be essentially a fork of the core project that is focused only on managing a set of patches to stick to their own LTS schedule. They can coordinate with "central" to make this job easier.
• Docs WG is a completely different repo + build tools + community that just PRs entire blobs of docs as they get updated.
• npm "WG" is literally just the existing npm team, as-is (plus the usual gaggle of collaborators to that project)
• libuv "WG" is already outside of node -- keep going
• v8 "WG" is already outside of node -- keep going

I think some "common ground" can be required of all these, again much like it is on npm: did you know that npm's CoC considers any interaction involving projects hosted on npm to be covered within its CoC? Consider a "central" project that sets some upper-level baseline behavior guidance and negotiates interaction with WGs based on whether they follow a superset of those guidelines. Don't wanna have a CoC at all? We won't merge your docs/ patches.

[varjmes]

If anyone finds they can't post a comment, it's because we had to limit it to contributors only for 24 hours. Normal service will resume tomorrow and I wanna keep this conversation going <3

[zkat]

I'm considering putting together a PR later with an actual draft of my proposed governance structure so we can comment on there. It would be nice if others have ideas and PR their own. Let's workshop this 👍

[stephenburgess8]

Hi - I have been following what's going on with Node and the steering committee (TSC) pretty closely recently.

The current plan on Node TSC is to dissolve the CTC back into TSC. A little background:

Steering committees, which are common in all kinds of organizations, are pretty explicitly not concerned with technical minutiae but instead with overarching organizational direction. Therefore, breaking the Node TSC into two groups, one of which does not participate in cultural discussions, misunderstands the purpose of steering committees. The CTC in fact has always just been part of TSC, but were exempt from having to engage with questions of strategy, culture, morality, or the well-being of members of the organization which they "steer."

Would you be open to a PR which removes references to the CTC and instead phrases it around the concept of a steering committee? I'm also interested in sharing a mechanism by which members of a steering committee could vote to hold other committee members accountable in a progressive way. Thanks and nice to meet you. 👋

[Fishrock123]

Steering committees, which are common in all kinds of organizations, are pretty explicitly not concerned with technical minutiae but instead with overarching organizational direction.

Perhaps but that wasn't the reality or necessarily the purpose of the TSC at its post-io.js merge formation. In io.js, we just called it the "Technical Committee", which is how it operated, and was more or less brought forward into the Node TSC post-io.js merge.

Here however, I'm not sure we have any active concept of "TC", or at least yet - there is simply a founding "admin" or "core" group until ideas around this are better sorted out and agreed upon. :D

I'm not sure there is much value in changing the documents other than the readme until we sort out what everyone wants to do.

[steveklabnik]

I am, as always, happy to discuss what I like and don't like about Rust's governance; I don't plan on contributing to ayo (not enough hours in the day...), so you all should decide for yourselves what you'd like to do, but I'm always happy to talk governance structures 😄

[ShaneCurcuru]

Since you put help wanted... I'm happy to share some ideas from the Apache model of governance, in case some of it fits what your community's vision is.

We have detailed Apache Project Governance description and orgcharts posted.

Very broadly, there are only three levels of governance at the ASF:

• The board, which is the legal board of directors of the corporation. In theory, the board can do whatever it chooses (they run the corporation); in practice, they set very broad policies about how to run things the Apache Way, and otherwise trust that individual projects will self-regulate. The ASF board is wholly independent, and is elected from the ASF Membership - that fact plus our 501C3 status means that corporate politics don't affect board-level decisions at Apache.

• Each Project Management Committee (PMC, kind of like TSC + CTC), which governs a single Apache project (where project == node-core, node-docs, etc.). The PMC votes on formal releases (which means controlling the roadmap), and votes on potential committers or new PMC members (which means controlling who's a committer/maintainer). All PMC members get an equal vote, and the Chair (who is also a VP of the corporation for us) gets the same equal vote. The Chair is primarily there to ensure reports get submitted to the board about project status & operations quarterly. The PMC as a whole is expected/hoped to also deal with conduct or other non-technical issues within their project.

• Every Apache project's committers. They have write access to the repo and can cast some level of votes on day-to-day check-ins. Healthy PMCs also pay attention to the nonbinding votes committers cast on releases or roadmaps but aren't bound by them.

• Projects are expected to work by consensus. Only when that fails would you fall back to voting.

• PMCs need to be right-sized; the ASF doesn't like umbrella projects. It's nothing to do with a roadmap; it has to do with ensuring the bulk of the PMC is aware of what's happening across the project and could have an informed opinion on issues or new committer/PMC member votes. One issue it feels like some projects have is that the governing body that makes most decisions (Apache PMC or Node TSC) needs to be composed of a sample of the people actually working on (or otherwise regularly aware of) all the project's direction.

• When PMCs have insolvable problems or go off the rails, then the board will get involved. The first step is always to say "Hey, you seem to have a serious problem, please tell us how you're going to solve it". PMCs are given a chance to fix things themselves - and that's fine even if it takes time, as long as they honestly and clearly communicate to the board their actions. When PMCs aren't honest with the board, or can't fix things, then the board steps in to make unilateral changes in the PMC. That's almost always messy, because the board isn't involved in day-to-day work on the project. But if the PMC is acting inappropriately or violating core principles, the board will fix the issue, period.

It's more important IMO to get the basics of day-to-day project governance running (so you can show progress and do some actual work), and then define very clearly who the "board" is (to make it crystal clear that after those X people decide on new policies, they're done), and then work on the rest of the details of governance.

Important note: A big part of the governance structure at the ASF is the combination of 1) Maximum PMC self-governance within the broader Apache Way style of working, and 2) a completely independent board. Having that independent board - and a consistent one focused on the ways communities work and core values - is a big difference to many other projects.

Please let me know if you have any other questions about Apache style governance.

[zkat]

Since we've landed #39 and this issue has been relatively quiet, I propose closing this, and having any further adjustments to our governance model happen through the RFC process. Or at least, we should create more fine-grained issues like #73 to talk about specific aspects of our governance.

[sandfox]

Yep, I think this issue has had it's day and served it's purpose. over-eagerly closing!