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

potential governance models #2

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions