Concept about collective HOT 9 CLOSED

I am unfortunately going to be busy pretty much for the bulk of this week, but basically the gist of what I was thinking corresponds to what's already been suggested here.

• A core team that manages cross-cutting concerns and represents the project at the highest level
• A moderation team that deals with Code of Conduct enforcement across the orgs
• Per-org project committees that act as administrative bodies for that project, can implement their own policies, et cetera
• A democratic and consensus-based way of implementing changes to the project or to orgs. This is the tricky one. Rust has done this by adapting an RFC process, but I'm not sure it'd work that great for us since we have many smaller projects under our umbrella.

I feel like projects (e.g. project committees) should decide on their own on whether they want to adopt a Merger/Releaser type structure. We should aim for a bottom-up, horizontal org structure as much as we can, which in my opinion means that we have to give the orgs freedom to determine how they "do" contributions.

from collective.

Django's idea isn't new.

Sorry, I didn’t add enough context. What I believe they’re doing is to move only have mergers and releasers. No core team. I think that’s interesting. But I think a core team makes sense for us to oversee the 200 projects, whereas Django is smaller.

I like the idea of different organization teams [...] So, I'm for it.

Good good!! 👍

I’m closing this. We can continue discussing in #2.

from collective.

I think it definitely makes sense to have per-project teams in addition to a unified level core team. IMO for now docs/moderation/community can be handled on a per-project level as well as by the overarching core team for the ecosystem.

I like the idea regarding Mergers and Releasers, but I do worry that it's too much process for some projects, especially for those that are split up into so many tiny repos. It seems like that process can be introduced when it becomes required but I'm not sure we're there yet.

💯I really dig the rust governance doc.

from collective.

I think it definitely makes sense to have per-project teams in addition to a unified level core team. IMO for now docs/moderation/community can be handled on a per-project level as well as by the overarching core team for the ecosystem.

I’m 👍 to per-org teams and a core team. I’d like overarching docs/community teams so that that stuff gets normalised across the ecosystem.
I like one community team that is overarching as well (that cannot include core team members or org team leads) to be some form of independent accountability.

I like the idea regarding Mergers and Releasers, but I do worry that it's too much process for some projects, especially for those that are split up into so many tiny repos. It seems like that process can be introduced when it becomes required but I'm not sure we're there yet.

Yeah. I think it works for the main repos: mdx-js/mdx, remarkjs/remark, etc. But not the rest. Too much churn for those.

💯I really dig the rust governance doc.

Right?! 🎉

/cc @oe What do you think? I wanted to get the ball rolling, but I’d love your vision on this!

from collective.

I saw a typo in my comment btw:

I’m 👍 to per-org teams and a core team. I’d like overarching docs/community teams so that that stuff gets normalised across the ecosystem.
I like one communitymoderation team that is overarching as well (that cannot include core team members or org team leads) to be some form of independent accountability.
— @wooorm

...which is the same as @oe suggests

• A democratic and consensus-based way of implementing changes to the project or to orgs. This is the tricky one. Rust has done this by adapting an RFC process, but I'm not sure it'd work that great for us since we have many smaller projects under our umbrella.
  — @oe

Yes, this is hard. RFCs work for big changes and big projects. But not for all the tiny projects under our umbrella. For example: every year or so, I walk through all the modules (including my own, so that’s about 500 projects) to give them a new layer of paint. One such example is here: syntax-tree/unist-util-parents@1.0.0...1.0.1. I can do that for about 10-15 projects a day. I think that’s important to do, but it already takes a bunch of time, and it’ll take much longer to have something like mergers and releases, or RFCs, for this case.

from collective.

@wooorm Yes, one thing I was specifically having in mind is only implementing very generalized policies through the RFC process. For example, say we wanted to change our branding:

• Someone writes up a RFC proposal at unifiedjs/rfcs or other repo
• We (core team) discuss the specifics of that proposal and vote on whether the proposal lands or not
• Once it lands, every project committee has the responsibility of implementing this at their respective levels

There should be distinctions on whether changes are made through the RFC process:

• If it's a project-wide change, then yes
• If it's an org-wide (e.g. only one subproject) change, then also yes, but the respective project committee would need to ratify the RFC
• If it's a repo-wide change under an org, no. In this case, the change is under the related project committee's jurisdiction

Does that make sense? All of this should obviously be written down so we can determine these cases in a more clear and consistent manner.

from collective.

I like the idea regarding Mergers and Releasers, but I do worry that it's too much process for some projects, especially for those that are split up into so many tiny repos.

it’ll take much longer to have something like mergers and releases

I'd offer a different perspective, we already have this setup.
Mergers being people who have access to the repositories.
Releasers being people who have access to NPM.
Adding this to the governance would keep the flexibility we have now, while also documenting it so newcomers can easily understand the organization.

Nobody merges their own work, and nobody releases what they merge

This is above and beyond the Merger and Releaser organization, but I like it.
With something like the note on awesome-awesome has

You have to review at least 2 other open pull requests. Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration.

this could scale out nicely.

from collective.

I drafted something up in https://github.com/unifiedjs/governance/pull/2, please review & comment there!

from collective.

• Django's idea isn't new. I'd consider it a best practice to never merge your own PRs in distributed teams. It's a good practice that we should adopt, if we have the manpower. That will force @wooorm to find other maintainers who are interested in reviewing PRs, too, especially for some of the smaller repositories; hopefully, opening up the field of responsibility a bit for anyone who wants to step up.
• I like the idea of different organization teams, as suggested above (especially by @oe). I'm not entirely sure that we have enough people to make some organization teams entirely self sustaining, but marking some conversations as organization related will enable people to compartmentalize what they look at and review, more, which will help with stopping burnout in the long run. So, I'm for it.

from collective.