Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial governance suggestion #1

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

Initial governance suggestion #1

Show file tree
Hide file tree
Changes from 7 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
46bf9c0
Initial governance suggestion
voxpelli Apr 11, 2024
690ecc7
Some additional wording
voxpelli Apr 11, 2024
4c30103
Add notes on communication paths
voxpelli Apr 12, 2024
8902808
Apply suggestions from code review
voxpelli Apr 12, 2024
5c35c96
Use same linking style everywhere
voxpelli Apr 12, 2024
1cd6f65
Update note on license
voxpelli Apr 12, 2024
51dc45a
Apply suggestions from code review
voxpelli Apr 18, 2024
000e2bc
Update project list
voxpelli Jul 24, 2024
1fcb836
Add link to Discord chat
voxpelli Jul 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
201 changes: 201 additions & 0 deletions GOVERNANCE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,201 @@
# ESLint-Community Governance
MichaelDeBoey marked this conversation as resolved.
Show resolved Hide resolved

## Core Team
MichaelDeBoey marked this conversation as resolved.
Show resolved Hide resolved

The Core Team are the curators and stewards of the ESLint-Community project . Their key
responsibility is to evaluate new projects that are proposed to join `@eslint-community`
and to help out in offering a base level maintenance for all primary projects within
the organization.

The Core Team should have occasional meetings to discuss the project, with meeting minutes
being added to [eslint-community/governance][].
voxpelli marked this conversation as resolved.
Show resolved Hide resolved

The Core Team are together with the ESLint TSC the organization owners and the only ones
with `admin` access to repositories within the organization.

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

The Core Team and ESLint TSC have a shared `#community-team` chat room, in the ESLint
MichaelDeBoey marked this conversation as resolved.
Show resolved Hide resolved
Discord, to communicate with one another.
voxpelli marked this conversation as resolved.
Show resolved Hide resolved

## ESLint TSC
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ESLint TSC first as they are the ultimate caretakers?


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 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.
Comment on lines +27 to +33
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have these alineas in the doc, so maybe we should remove it or move it to a more general place?


## Collaborators

Collaborators maintain the projects of the ESLint-Community organization.

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`.

A project team is given `write` level access to its repositories.

If multiple repositores are needed by the same project they should all be added to
the project team.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


Collaborators can communicate in private with the Core Team in
[private team discussion on GitHub][].

### Collaborator activities

* Helping users and novice contributors
* Contributing code and documentation changes that improve the project
* Reviewing and commenting on issues and pull requests
* Merging pull requests
* Release plugins
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The org is responsible for more than just plugins

Suggested change
* Release plugins
* Release packages


The Core Team can remove inactive Collaborators or provide them with
_Past Collaborators_ status. Past Collaborators may request that the Core
Team restore them to active status.

## Projects

There are two kinds of projects in ESLint Community: Primary and auxiliary projects.

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.
Comment on lines +71 to +77
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that suggestion! The wording is much clearer than my suggestion 🙏


All project npm modules should be owned (and solely owned) by the `eslint-community-bot`
user on npm. If the npm modules are owned by an existing organisation and using its prefix,
then the `eslint-community-bot` should become the sole owner of that organisation.

Additional assets such as domain names, web sites etc should also be in control of the
Core Team and/or the ESLint TSC.

If possible, a project should always be transfered and keep using its original npm module
name and repository. If a new module name needs to be created, it should preferably be
`@eslint-community/<the-old-name>`.

Automatic releases of the modules should be set up by the Core Team using the organization
secret in the GitHub organization.

Auxiliary projects can can be nominated to become a primary project by its Collaborators,
by opening a [private team discussion on GitHub][].

If a primary project is no longer widely depended upon, or have technical reasons to no
longer stay a primary project, the Core Team can decide to convert it into an auxiliary
project in discussion with its Collaborators.

## Project nominations

Projects that are widely depended upon within the ESLint ecosystem may be nominated to
become ESLint-Community projects by anyone by opening a public issue on GitHub in the
[eslint-community/governance][] repository.

The project should fulfill a few criterias:

The project should:

* Preferably be: An ESLint plugin or formatter
* Maybe be: A dependency used by an ESLint-Community project or the main ESLint repo
* Not be: Primarily an ESLint config

The project should also:

* be widely depended upon throughout the community (eg. 3M downloads/week or similar)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Skärmavbild 2024-04-23 kl 18 23 03

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

@robatwilliams robatwilliams Apr 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 👍

* have an OSI-approved license (preferably Apache 2.0, else MIT-style)
* have proposed Collaborators or have possibility to be deemed a Primary project
by the Core Team

If project currently has an active maintainer it should be transfered and then:

* the current maintainer should be willing to transfer the project to ESLint-Community

If it's an abandoned project that needs to be forked:

* It shouldn't have received an update in a substantial amount of time (eg. last 6 months)
or it should present a major obstacle to the adoption of eg. a new major version of ESLint
* A clear notice about the nomination should have been made to the project and its
maintainer at least 30 days before it can be accepted

Projects should typically start out with a status of "auxiliary".

## Collaborator nominations

Individuals making significant and valuable contributions to a project may be
a candidate to join the ESLint-Community organization and that team.

An existing Collaborator needs to open a [private team discussion on GitHub][] and
list the candidates they want to sponsor with a link to the user's contributions. For
example:

* Activities in the ESLint-Community organization
`[USERNAME](https://github.com/search?q=author:USERNAME+org:eslint-community)`

Otherwise, a Contributor may self-apply if they believe they meet the above
criteria by reaching out to a Core Team member privately with the links to their
valuable contributions. That Lead Maintainer will then open a private team discussion on
GitHub regarding that and reply back when a decision has been made.

The consensus to grant a new candidate Collaborator status is reached when:

- at least two of the Core Team members approve
- at least half of the current collaborators in that team approve, rounded up
(and not counting Core Team members)
MichaelDeBoey marked this conversation as resolved.
Show resolved Hide resolved

## Core Team nominations

A Team Member may be promoted to the Core Team only through nomination by a
Core Team member and with agreement from the rest of Core Team as well as the
ESLint TSC.

The ESLint TSC can appoint and revoke Core Team members at their own discretion.

## Consensus seeking process

The ESLint Community follows a Lazy [Consensus Seeking][] decision-making model,
inspired by the [ASF][].

_Lazy_ means that silence is consent if an appropriate amount of time has passed
(most of the time: at least a week) since the suggestion was made and no objections
has been raised.

This only holds true if all relevant parties has been notified of the suggestion
and given the opportunity to take part. Eg. extra care needs to be taken during
holiday and vacation times.

Decision makers should strive to give active consent and not actively wait out
silent consent.

### Votes

In case of a Collaborator objection to a specific change, the Core Team can
vote to override the objection if consensus can not be reached.

For all votes, a simple majority of all Core Team members for, or against, the
issue wins. A Core Team member may choose to participate in any vote through
abstention.

The ESLint TSC can decide to override / veto any decision / objection made by
Collaborators or Core Team. The ESLint Project decides how to arrive at
such decisions.

[Consensus Seeking]:
https://en.wikipedia.org/wiki/Consensus-seeking_decision-making
[ASF]:
https://community.apache.org/committers/decisionMaking.html
[eslint-community/governance]:
https://github.com/eslint-community/governance
[private team discussion on GitHub]:
https://github.com/eslint-community/collaborators/discussions
36 changes: 28 additions & 8 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,18 +1,38 @@
# Governance
# ESLint-Community Governance

Outlines the governance of [@eslint-community](https://github.com/eslint-community) and fascilitates proposals and nominations
## Purpose

## Goal
To have a place where community members can help ensure that widely depended upon ESLint-related packages live and never fall out of maintenance.

As you can read in the
["`eslint-community` GitHub organization" RFC](https://github.com/eslint/rfcs/tree/main/designs/2022-community-eslint-org),
the goal of this organization is to have a place where community members can
help ensure widely depended upon ESLint-related packages live and never fall out
of maintenance.
## Governance

See [GOVERNANCE.md](./GOVERNANCE.md)

## The Community Core team

* [`@aladdin-add`](https://github.com/aladdin-add)
* [`@MichaelDeBoey`](https://github.com/MichaelDeBoey)
* [`@ota-meshi`](https://github.com/ota-meshi)
* [`@voxpelli`](https://github.com/voxpelli)


## Projects

### Primary projects

* [eslint-plugin-es-x](https://github.com/eslint-community/eslint-plugin-es-x) (Collaborators: [@brettz9](https://github.com/brettz9))
voxpelli marked this conversation as resolved.
Show resolved Hide resolved
* [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/eslint-formatter-codeframe) (Collaborators: )
* [eslint-formatter-table](https://github.com/eslint-community/eslint-formatter-table) (Collaborators: )
* [eslint-plugin-mysticatea](https://github.com/eslint-community/eslint-plugin-mysticatea) (Collaborators: )
* [regexpp](https://github.com/eslint-community/regexpp) (Collaborators: )

### Auxiliary projects

* [eslint-stylistic](https://github.com/eslint-community/eslint-stylistic) (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/eslint-stylistic-repro-template)