Initial governance suggestion

[voxpelli]

As discussed by some of us on chat, its good if we formalize the governance of this project.

Here's a proposal that's written with inspiration from the RFC, other community governance docs and my own head – trying to be constructive yet not step on anyone's toes.

I would propose setting up an issue template for nominating new projects if this PR is accepted, that would make it easier to gather all relevant pieces, and I can volunteer to do so.

I also took the liberty of setting up https://github.com/eslint-community/collaborators/discussions where all collaborators as well as the ESLint TSC and us in the Core Team can discuss nominations etc in private (which is the respectful thing to do when eg. a person is nominated, one shouldn't evaluate them in the open)

[voxpelli]

Added notes on communication paths

[nzakas]

LGTM. Just left a few suggestions, mostly for cleanup.

[aladdin-add]

I advocate for a decentralized approach to maintenance, where each project has one or more main maintainers with full repository permissions. These maintainers would oversee their project's dedicated maintenance team. Additionally, core team members may also double as maintainers for specific projects.

The core team's primary role would be to manage new project onboarding, establish teams and permissions, and facilitate the search for new maintainers if current ones step down. Their focus lies in organizational aspects rather than day-to-day project maintenance.

This strategy distributes responsibilities effectively, allowing for focused attention on each project. It empowers maintainers and teams to take ownership of their projects while still benefiting from core team support when needed.

With a decentralized maintenance approach and dedicated maintainers for each project, there's no longer a need to differentiate between Primary and auxiliary projects. Each project can have its own team of maintainers, simplifying and streamlining the management process overall.

[voxpelli]

@aladdin-add That essentially would treat all projects as what I described as "auxiliary" whereas the original RFC pretty much described all projects being "primary" and the task of the core team to maintain – so it would be a lot bigger of a change from the initial RFC as I see it.

I think the ownership of the repos and the npm modules needs to be with the Core Team and ESLint TSC (with the community bot being sole owner of the npm modules) to ensure continuity and allow for more easier onboarding of project specific maintainers.

I do think there's lots of room in the original proposal for every project to decide themselves how to maintain their project, "primary" as I intended it just means that the core team provides an additional guarantee and fallback, not that it takes on the leadership.

[aladdin-add]

I'd like to clarify the primary responsibilities of the core team. As the number of projects may increase, I don't believe core team members should be involved in day-to-day maintenance tasks. However, I'm open to it if other members agree. 😄

[nzakas]

I believe the original vision was that projects could have their own maintainers and the core team would remain uninvolved so long as the project was actively maintained. Only when a project fell out of maintenance would the core team step in to maintain the project. I still think that's the right way to go, as I don't think the core team should be responsible for an ever-growing number of projects.

[voxpelli]

the core team would remain uninvolved so long as the project was actively maintained. Only when a project fell out of maintenance would the core team step in to maintain the project

This is how I phrased it and which I think says largely the same:

[The core team] help out in offering a base level maintenance for all primary projects within the organization
[...]
Collaborators maintain the projects of the ESLint-Community organization.

My intention was two-fold:

• Capture the fact that right now less than half of the modules have any non-core-team maintainers at all and most of the others are either led by or have core-team members as big contributors. So right now the core-team is very involved.
• Make a distinction between ("primary") projects that the core-team will step in to help maintain in case original maintainers disappear and ("auxiliary") projects where ESLint-Community will merely serve as a safe resting place for it when unmaintained, until someone steps up to maintain it. I think its good to have a distinction there as then we can still let modules in even when we have no time to help out maintaining it.

Intention is to enable less critical modules like eslint-formatter-table to be part of the project, and quite complex modules like eslint-stylistic as well, while still being clear about which modules the core-team are prepared to step into and help ensure a base level maintenance of – so that it eg. work with new versions of ESLint, Node.js, npm etc.

[voxpelli]

I would like to open a follow up issue for this list afterwards and move eg. maybe the formatters to auxiliary + ensure that the list of maintainers are up to date and ensure that access to the repositories are synced up with that.

[aladdin-add]

I'm slightly inclined to have separate maintenance teams for each project, and not differentiate between primary vs. auxiliary. I think we've created some teams, e.g. https://github.com/orgs/eslint-community/teams/eslint-plugin-es

[voxpelli]

I'm slightly inclined to have separate maintenance teams for each project, and not differentiate between primary vs. auxiliary. I think we've created some teams, e.g. https://github.com/orgs/eslint-community/teams/eslint-plugin-es

Those teams are mentioned in there:

Collaborators are added on a project by project basis by adding them to a team of
the same name as its main project repository, eg. @eslint-community/eslint-plugin.

But maybe you are you essentially suggesting that core-team members should be seen as any individual collaborator and join/leave projects just like any other collaborator and that the core-team itself will make no coordinated maintenance efforts?

I based the proposal here on what was written in the initial RFC, such as eg:

The community core team would help maintain all repos, whereas people in specific teams would only help maintain these repositories.

[aladdin-add]

But maybe you are you essentially suggesting that core-team members should be seen as any individual collaborator and join/leave projects just like any other collaborator and that the core-team itself will make no coordinated maintenance efforts?

👍 core team members may also double as maintainers for specific projects.

[robatwilliams]

I see this 3M/wk example figure comes from the RFC where the majority of the mentioned projects have this level. I'm not aware of how much consideration it's had already, at RFC time, or now in being carried forward to this criterion - hence this comment.

It sounds like quite a high bar at first look, although for context ESLint itself gets 38M (so the 3M is 8%) and the React plugin gets 18M (47%). Other stats that would be more difficult to acquire would be count or % of all plugins on npm (or https://github.com/dustinspecker/awesome-eslint) that would meet this criteria.

Any further thoughts on the figure?

As far as I know, NPM download counts and GitHub stars are the only metrics available.

[voxpelli]

A better number / criteria would indeed be good

Eg. @aladdin-add proposed adding eslint-plugin-markdown and that has 500k weekly, but I guess that was proposed more as an offspring from ESLint core.

Other possible numbers are accessible through eg. ecosyste.ms, such as number of "dependent packages" and "dependant repositories", which for eg. eslint-plugin-markdown is ±4k and ≈150k

At times also interesting to know which version it is that the downloads are from, eg that plugin has most of its downloads happen on the 3.x version and not yet on the latest 4.x version, which if it would be an abandoned aged project would indicate that its the 3.x version that should be adopted maybe.

[robatwilliams]

Some ordered searches for some visibility of the curves:

https://www.npmjs.com/search?q=eslint-plugin-&ranking=popularity
https://github.com/search?q=eslint-plugin-&type=repositories&s=stars&o=desc

I think both downloads and metrics are pretty flawed though. For popular projects I expect the share caused by public mirrors is small. Some companies run NPM mirrors and have hundreds of developers and projects hidden behind a single download count. Others are running hundreds of CI jobs daily without any caching or mirror. And how many people star the projects they use. These aren't problems for us to solve here, but to be mindful of their effect.

[nzakas]

What if we use number of projects that depend on the package? This might give a better idea of "importance" to the community (especially when coupled with downloads).

[voxpelli]

I actually have been working on a tool that enables one to list dependents of a module + filter those dependencies on how old the latest release it, minimum downloads and such: https://github.com/voxpelli/list-dependents-cli

(Will be using it for some canary tests, but is similarly useful here)

On the governance text:

Maybe we just remove any hard numbers and defer it to a case by case basis?

[robatwilliams]

I think dependents count is an useful input, but perhaps when applied to all users, a secondary one. My intuition is that there are many, many more private than public projects depending on plugins, but of course we don't have information about those.

Taking https://www.npmjs.com/package/eslint-plugin-react for example, and generously assuming that every one of the 17k dependents make 10 downloads every day of the week, that would account for 1M of the 18M weekly downloads. Limited information here so I'm clutching at straws and that might be a flawed validation of my intuition.

[robatwilliams]

Just seen the comment about removing hard numbers. I think it would be fine.

For the use case I had today at least, it would have resulted (by the word "widely") in the what I believe to be the correct outcome which is that I wouldn't have submitted my not-very-popular (3-4K/wk) small project.

There is a data gap we've come across here however that I expect is bound to have affected people making decisions (in the NPM ecosystem generally) before us and will continue to in the future.

[voxpelli]

eslint-plugin-react has 2 million dependent repositories: https://packages.ecosyste.ms/registries/npmjs.org/packages/eslint-plugin-react

[robatwilliams]

Ah I see, dependent repositories rather than packages as I used from npmjs.org, and they have a more comprehensive view of other distribution channels for the packages number too. Presumably still not covering private projects however.

[MichaelDeBoey]

I think we included the number because "widely used" is another vague term that could be interpreted differently by different people and just wanted to give an indication 🤷‍♂️

So I would be in favor of just removing the number completely 👍

[MichaelDeBoey]

the original vision was that projects could have their own maintainers and the core team would remain uninvolved so long as the project was actively maintained. Only when a project fell out of maintenance would the core team step in to maintain the project

@aladdin-add @nzakas @voxpelli That's indeed how the original setup of the org was meant to be: keep maintenance with the original maintainers and only step in if nobody else can/wants to
Since the first repos we took over were @mysticatea's packages, we had nobody else to help out, so that's why the Community Core team stepped in

I'm slightly inclined to have separate maintenance teams [...] and not differentiate between primary vs. auxiliary.

I agree with @aladdin-add here to not make a formal distinction between "packages we will keep up to date" and "packages we will only accept PRs for, so it's completely up to the community"
The Community Core team has write access to every repo we add in the org (or at least that's what we should do) and we manage the teams for each specific repo
So if nobody's in the team anymore, I guess the package automatically falls into the "we only accepts PRs for this repo, so it's completely up to the community" category 🤔

That being said: I think it would be a good idea that the Community Core team would watch every repo we have in the org that doesn't have a dedicated maintainer team, so issues/PRs don't get unnoticed

[MichaelDeBoey]

The RFC & announcement blogpost are talking about Community Core team, so maybe we should keep doing that here as well?

Suggested change

	## Core Team
	## Community Core team

[voxpelli]

Since this is a document for the ESLint-Community organization I used Core Team rather than Community Core team. The latter would make sense if this was an ESLint document, but it isn't

[MichaelDeBoey]

Suggested change

	The Core Team are the curators and stewards of the ESLint-Community project . Their key
	The Community Core team are the curators and stewards of the ESLint Community project . Their key

[MichaelDeBoey]

Suggested change

	The Core Team should have occasional meetings to discuss the project, with meeting minutes
	The Community Core team should have occasional meetings to discuss the project, with meeting minutes

[MichaelDeBoey]

Suggested change

	The Core Team are together with the ESLint TSC the organization owners and the only ones
	The Community Core team are together with the ESLint TSC the organization owners and the only ones

[MichaelDeBoey]

Suggested change

	The Core Team are the only members of the `@eslint-community/core-team` team.
	The Community Core team are the only members of the `@eslint-community/core-team` team.

[MichaelDeBoey]

Suggested change

	The Core Team and ESLint TSC have a shared `#community-team` chat room, in the ESLint
	The Community Core team and ESLint TSC have a shared `#community-team` chat room, in the ESLint

[MichaelDeBoey]

What about linking to the Discord server as well?

[voxpelli]

If there's a good link, then sure 👍

[MichaelDeBoey]

We used https://eslint.org/chat/eslint-community in the org announcement post

[MichaelDeBoey]

We always named it without the hypen, so maybe we should keep doing that here as well?

Suggested change

	# ESLint-Community Governance
	# ESLint Community Governance

[voxpelli]

I used ESLint-Community to refer to the eslint-community organization, as ESLint Community can just as well be interpreted as referring to the ESLint community in general

[MichaelDeBoey]

The latter would be with a lowercase c I guess?

I'm just trying to have consistent naming across the RFC, the announcement post and this document we're creating in this PR

[MichaelDeBoey]

A link is missing here I think?

[voxpelli]

Its in the very bottom for eg. readability reasons:

[eslint-community/governance]:
    https://github.com/eslint-community/governance

[MichaelDeBoey]

Suggested change

	The ESLint TSC are the ultimate caretakers of the ESLint-Community, appoints the Core
	Team and holds the ownership of the `eslint-community-bot` npm account that owns all
	the ESLint-Community npm modules.
	The ESLint TSC are the ultimate caretakers of the ESLint Community, appoints the Community Core
	team and holds the ownership of the `eslint-community-bot` npm account that owns all
	the ESLint Community npm modules.

[MichaelDeBoey]

Suggested change

	The Core Team are together with the ESLint TSC the organization owners and only ones
	The Community Core team are together with the ESLint TSC the organization owners and only ones

[MichaelDeBoey]

Suggested change

	The Core Team and ESLint TSC have a shared `#community-team` chat room, in the ESLint
	The Community Core team and ESLint TSC have a shared `#community-team` chat room, in the ESLint

[voxpelli]

I think it would be a good idea that the Community Core team would watch every repo we have in the org that doesn't have a dedicated maintainer team, so issues/PRs don't get unnoticed

Watching for issues / PR:s is part of doing a base level of maintenance I think, and if the core team commits to keep such an eye on all projects within the organization, then we need to include that in the consideration of onboarding new projects.

By making a distinction between primary and auxiliary projects we can safe-keep even the community projects that we don't commit to keeping a base level maintenance of. Eg. safe-keeping a complex module like ESLint Stylistic without the Core Team committing to keeping an active eye on issues/PRs or to provide any other maintenance level on it except from keeping it safe until a new maintainer steps in.

Auxiliary projects also provides an option to archiving / deprecating a module when its outdated and/or of no interest to any core team member to keep an eye on.

Setting clear expectations between us within the core team as well as towards the community about what level of involvement from the core team they can expect is crucial I think.

So far we have three levels suggested I think:

1. Only adding new maintainers
2. Also responding to issues / PR:s
3. Also ensuring base level maintenance to stay compatible with the wider ESLint ecosystem

The current proposal is written with 3. in mind and the original RFC was written like that as well I think, but without the concept of "auxiliary" modules (since it was concerned with creating the community whereas this document is concerned with governing and maintaining it over time)