Initial governance suggestion #1
Conversation
voxpelli
requested review from
a team,
nzakas,
MichaelDeBoey,
aladdin-add and
ota-meshi
|
Added notes on communication paths |
Co-authored-by: Nicholas C. Zakas <nicholas@humanwhocodes.com>
There was a problem hiding this comment.
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.
|
@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. |
|
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. 😄 |
|
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. |
This is how I phrased it and which I think says largely the same:
My intention was two-fold:
Intention is to enable less critical modules like |
README.md
Outdated
| ## Projects | ||
|
|
||
| ### Primary projects | ||
|
|
||
| * [eslint-plugin-es-x](https://github.com/eslint-community/eslint-plugin-es-x) (Collaborators: [@brettz9](https://github.com/brettz9)) | ||
| * [eslint-plugin-eslint-comments](https://github.com/eslint-community/eslint-plugin-eslint-comments) (Collaborators: ) | ||
| * [eslint-plugin-eslint-plugin](https://github.com/eslint-community/eslint-plugin-eslint-plugin) (Collaborators: [@bmish](https://github.com/bmish), [@bradzacher](https://github.com/bradzacher)) | ||
| * [eslint-plugin-n](https://github.com/eslint-community/eslint-plugin-n) (Collaborators: [@scagood](https://github.com/scagood)) | ||
| * [eslint-plugin-promise](https://github.com/eslint-community/eslint-plugin-promise) (Collaborators: [@xjamundx](https://github.com/xjamundx), [@bmish](https://github.com/bmish)) | ||
| * [eslint-plugin-security](https://github.com/eslint-community/eslint-plugin-security) (Collaborators: [@nzakas](https://github.com/nzakas), [@nlf](https://github.com/nlf)) | ||
| * [eslint-utils](https://github.com/eslint-community/eslint-utils) (Collaborators: ) | ||
| * [eslint-formatter-codeframe](https://github.com/eslint-community/) (Collaborators: ) | ||
| * [eslint-formatter-table](https://github.com/eslint-community/) (Collaborators: ) | ||
| * [eslint-plugin-mysticatea](https://github.com/eslint-community/) (Collaborators: ) | ||
| * [regexpp](https://github.com/eslint-community/) (Collaborators: ) | ||
|
|
||
| ### Auxiliary projects | ||
|
|
||
| * [eslint-stylistic](https://github.com/eslint-community/) (Collaborators: [@Shinigami92](https://github.com/Shinigami92), [@antfu](https://github.com/antfu), [@kecrily](https://github.com/kecrily)) | ||
| * [eslint-stylistic-repro-template](https://github.com/eslint-community/) |
There was a problem hiding this comment.
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.
|
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:
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:
|
👍 core team members may also double as maintainers for specific projects. |
Co-authored-by: Yosuke Ota <otameshiyo23@gmail.com>
|
|
||
| The project should also: | ||
|
|
||
| * be widely depended upon throughout the community (eg. 3M downloads/week or similar) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
eslint-plugin-react has 2 million dependent repositories: https://packages.ecosyste.ms/registries/npmjs.org/packages/eslint-plugin-react
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 👍
There was a problem hiding this comment.
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
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:
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) |
| Primary projects are maintained by Core Team in collaboration with project Collaborators | ||
| and will be ensured to be kept up to date at a best effort pace by the Core Team. | ||
|
|
||
| Auxiliary projects are maintained by its project Collaborators and is kept up to date at | ||
| whatever pace those Collaborators chose. The Core Team merely fascilitates nominations | ||
| of new Collaborators to such projects, ensuring there's a path to keep it maintained, | ||
| without making any promises. |
There was a problem hiding this comment.
I would maybe want a third level here:
- Archived projects
And a project can move up and down – from primary, to auxiliary to archived and the other way around – and its clear to everyone what the status of the project is and that makes the threshold for accepting new projects lower.
There was a problem hiding this comment.
I think the wording used here is a bit vague and could use some clarification. For instance, what does "kept up to date" mean?
Here's what I'd suggest:
- Active Projects - these are projects under active development, meaning they continue to add new features in addition to bug fixes. These may be maintained either by the core team or separate maintainers. The expectation is that these projects have regular releases.
- Maintenance Projects - these are projects not under active development, but they receive critical bug fixes and security updates (i.e., dependency upgrades), as well as any changes to remain compatible with new releases of ESLint. The expectation is that these releases happen infrequently. In most cases, the core team will be handling these projects.
- EOL Projects - these are projects that receive no further updates of any kind. They are not maintained, the repo is archived and the npm package is marked as deprecated. These projects are kept purely for historical purposes.
There was a problem hiding this comment.
I like that suggestion! The wording is much clearer than my suggestion 🙏
| Both Collaborators and non-Collaborators may propose changes to the source code | ||
| of the projects of the organization. The mechanism to propose such a change is a | ||
| GitHub pull request. Collaborators review and merge (_land_) pull requests | ||
| following the [CONTRIBUTING](CONTRIBUTING.md) guidelines. |
There was a problem hiding this comment.
Can mention be made here, or in a stub CONTRIBUTING.md document, that breaking changes should be reviewed by team members, if that is indeed the case? That seems to be a reasonable policy. I think it would be good to also explicitly mention that other merges can be handled by a collaborator who is different from the person submitting the PR.
There was a problem hiding this comment.
Makes a lot of sense 👍
I would also like it if we would do some general guidance decisions on things like new engine ranges, so that contributors can reference that
|
@aladdin-add @MichaelDeBoey Would removing the wording about auxiliary projects for now make this document acceptable to you? Then we can more easily iterate on it through PR:s etc. I really think we should ensure that we have a proper governance document, and recent questions in the community supports that eslint-community/eslint-plugin-promise#241 (comment) |
|
no objections from me👍 ! |
| Primary projects are maintained by Core Team in collaboration with project Collaborators | ||
| and will be ensured to be kept up to date at a best effort pace by the Core Team. | ||
|
|
||
| Auxiliary projects are maintained by its project Collaborators and is kept up to date at | ||
| whatever pace those Collaborators chose. The Core Team merely fascilitates nominations | ||
| of new Collaborators to such projects, ensuring there's a path to keep it maintained, | ||
| without making any promises. |
There was a problem hiding this comment.
I think the wording used here is a bit vague and could use some clarification. For instance, what does "kept up to date" mean?
Here's what I'd suggest:
- Active Projects - these are projects under active development, meaning they continue to add new features in addition to bug fixes. These may be maintained either by the core team or separate maintainers. The expectation is that these projects have regular releases.
- Maintenance Projects - these are projects not under active development, but they receive critical bug fixes and security updates (i.e., dependency upgrades), as well as any changes to remain compatible with new releases of ESLint. The expectation is that these releases happen infrequently. In most cases, the core team will be handling these projects.
- EOL Projects - these are projects that receive no further updates of any kind. They are not maintained, the repo is archived and the npm package is marked as deprecated. These projects are kept purely for historical purposes.
|
|
||
| ### Primary projects | ||
|
|
||
| * [eslint-plugin-es-x](https://github.com/eslint-community/eslint-plugin-es-x) (Collaborators: ) |
There was a problem hiding this comment.
Not sure if we should mention the collaborators tbh, as that list could become outdated real quick 🤔
| The Core Team and ESLint TSC have a shared `#community-team` chat room, in the [ESLint | ||
| Discord](https://eslint.org/chat/eslint-community), to communicate with one another. | ||
|
|
||
| ## ESLint TSC |
There was a problem hiding this comment.
ESLint TSC first as they are the ultimate caretakers?
| The Core Team are together with the ESLint TSC the organization owners and only ones | ||
| with `admin` access to repositories within the organization. | ||
|
|
||
| The ESLint TSC are the only members of the `@eslint-community/eslint-tsc` team. | ||
|
|
||
| The Core Team and ESLint TSC have a shared `#community-team` chat room, in the ESLint | ||
| Discord, to communicate with one another. |
There was a problem hiding this comment.
We already have these alineas in the doc, so maybe we should remove it or move it to a more general place?
| * Contributing code and documentation changes that improve the project | ||
| * Reviewing and commenting on issues and pull requests | ||
| * Merging pull requests | ||
| * Release plugins |
There was a problem hiding this comment.
The org is responsible for more than just plugins
| * Release plugins | |
| * Release packages |
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)