Set up eslint-community GitHub organization

[voxpelli]

This was discussed in the roadmap for 2022, but didn't make the cut: #15383

Though it's becoming increasingly clear that there are some highly used projects in the ESLint community that are currently lacking a good home, being created by formerly active members of the community and now forked by other individual members to stay up to date.

There has been an expressed desire to move some of these to a GitHub organization where they can be more collectively maintained, see eg. tise discussion in the eslint-plugin-n fork of eslint-plugin-node: eslint-community/eslint-plugin-n#8

According to @MichaelDeBoey there is interest from @xjamundx of moving eslint-plugin-promise to such an org as well: standard/eslint-config-standard#192 (comment)

And recently eg @mysticatea/eslint-plugin has been highlighted as one module that could need to get under collective maintenance: mysticatea/eslint-plugin#29

So – simple question from me is:

Since there is already an idea to do this from the ESLint team itself it doesn't make sense to create a competing ESLint community organization.

But when can the "official" one start to happen? As these modules all would get helped a lot by this happening sooner rather than later. If it won't happen soon, then we're better of creating an independent one.

EDIT:

@aladdin-add made a good clarification in mysticatea/eslint-plugin#29 (comment):

the thoughts behind @eslint-community is not the eslint team to maintain these projects. It is to help the important projects being well-maintained. e.g. find maintainers.

[brettz9]

In the interest of possibly allowing for other more non-ESLint generic JavaScript tools as well, I have sent out invites to yourself, @MichaelDeBoey and @aladdin-add to the @es-joy organization which I earlier set up as an umbrella org. to host such abandoned or unresponsive projects.

Due to flakiness in my energy as a result of some health issues, I'd be happy to elevate someone with more energy to an organizer role, but to avoid chaos, I think we should keep the number of organizers to a minimum.

[MichaelDeBoey]

I think having an ESLint-related org (one that's only handling ESLint configs/plugins) would be better to keep focus instead of having an org that also handles other kind of packages tbh.

[voxpelli]

Kind of agree, can we have it focus on that going forward @brettz9? It already kind of is?

[brettz9]

Some are ESLint-specific but others are not, and one is a mix (jsdoccomment).

The non-ESLint ones, however, are generally pretty basic in their nature as tools, e.g., working with JavaScript AST and JSDoc and types. There seem to end up being a number of projects that benefit ESLint which need maintenance but are not directly ESLint related; I am in fact using two of them within ESLint-related tools (jsdoccomment with eslint-plugin-jsdoc and escodegenwithin an espree PR).

But if you all want hard boundaries for ESLint plugins/configs only, then, I think going with @MichaelDeBoey 's suggestion may be a better route (or starting a new org) as I'd like to keep the space for these other fundamental tools, a number of which had been abandoned (and the others I thought were fundamental enough to deserve inclusion).

[MichaelDeBoey]

As said below (see #15929 (reply in thread)), I think we should have an org that's all about ESLint related packages, just like @jest-community is.
That's why I think having access to the @eslint-community org & being able to transfer some of @mysticatea's packages over there would be a good move forward in this endeavor.

Unfortunately we'll need @nzakas' help to get access to the org.

[voxpelli]

@brettz9 I think your approach makes sense, ESLint plugins are not created in a vacuum, they are part of the rest of the module ecosystem and other modules that are needed to make them work, or are related to them, should also belong in such an organization.

I see no reason to have hard boundaries, as long as there is somewhat of a focus so that one can say whether a module belongs there or not.

@MichaelDeBoey There is no indication that @eslint-community will happen anytime soon, so I don’t think that can be considered an alternative right here and now. @brettz9 is also an ESLint committer, so it’s not totally detached, which I like.

[MichaelDeBoey]

Although the @eslint-community org isn't meant to have the ESLint team maintain these packages, I would still like @nzakas to give access to some of us & connect us to @mysticatea so we can transfer his packages to the org & help maintaining them.

[voxpelli]

Why not @es-joy?

[MichaelDeBoey]

I think having the @eslint-community org name, it resembles more the fact that it's all about community ESLint packages, just like the @jest-community is all about community Jest packages.

Community repos for Jest related projects

[nzakas]

We would still like to do this, but we need a definition for what an eslint-community organization means. It is not intended to be a place where the ESLint team maintains unmaintained plugins…we don’t have the bandwidth to do that. It is intended to be a place where important community packages can live so that if the maintainers are unable to continue, then the ESLint team can step in and find a new maintainer.

Unfortunately, we also have a lot of other higher priority work right now. If you are interested, the best course forward is to put together an RFC explaining what you envision the community to be, including which projects should be involved, what the criteria for acceptance should be, what permissions maintainers should have, what the role of the ESLint team should be, etc.

[MichaelDeBoey]

How do you envision @eslint-community?

It is intended to be a place where important community packages can live so that if the maintainers are unable to continue, then the ESLint team can step in and find a new maintainer.

That's exactly what I also think the @eslint-community org should be, just like the @jest-community org is: a collection of important/widely used ESLint plugins/packages that aren't maintained anymore and are given back to the community.

Which projects should be involved?

I think all of @aladdin-add, @brettz9, @ota-meshi, @voxpelli & myself would be in for helping to maintain at least the following packages: @mysticatea/eslint-plugin, eslint-plugin-eslint-comments, eslint-plugin-es, eslint-plugin-node, eslint-utils (all from @mysticatea) & eslint-plugin-promise (which is used a lot as well and was mentioned by the current maintainer (@xjamundx) that he would like to transfer it to the community org if one was going to exist).

What would be the acceptance criteria?

I personally think that the acceptance criteria for a plugin to go under the @eslint-community org would be:

• Is it a package that is ESLint-related?
  Mostly this will be ESLint configs/plugins, but I can see unmaintained dependencies of such packages or closely related packages (like eslint-formatter-codeframe or eslint-formatter-table, which are now split from the ESLint repo & maintained by @fregante) go into the org as well.

• Is it widely used throughout the community?
  Don't have an exact number in mind, but all mentioned packages have at least 3M downloads/week.
  Only exceptions are eslint-plugin-eslint-comments (1M downloads/week) & @mysticatea/eslint-plugin (1.3K downloads/week), but that's used as a devDependency for all other mentioned packages by @mysticatea.

• It didn't receive an update in the last 12(?) months
  I think we can make an exception for packages that did get a PR merged that a member of the new org's "core" team created (mostly for updating compatibility with newer versions of ESLint).

  Just like we can make exceptions for packages that meet the other criteria, but where the owner want to transfer ownership to the new org.
  I can for instance imagine that @not-an-aardvark would want to transfer ownership of eslint-plugin-eslint-plugin to the new org as well, as it's a recommended plugin for linting custom plugins.
  https://eslint.org/docs/developer-guide/working-with-plugins#linting
  I can also imagine that people like @gajus at some point wanting to transfer ownership of eslint-plugin-flowtype or eslint-plugin-jsdoc if they would feel it would be better maintained by the community instead of putting all workload on their shoulders.

If a package is meeting these criteria, but we can't get into contact with the owner of the repo to transfer ownership over to the new org, we could temporarily fork the repo & publish the package as @eslint-community-fork/<package name> or so.

Maybe @G-Rath & @SimenB could give some insights on the acceptance criteria for @jest-community & we can learn from their findings as well.

What permissions should maintainers have?

I think it would be best to have some sort of a "core" team (of at least 3 people) that's making the decisions in terms of acceptance to the repo, which would all be admin of the org.

We can make a team (with sub-teams if we want) for each package, where we give admin rights on the repo for that specific package.

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

Bonus: I think having our own place in the Discord server where we can discuss some things would be a good idea as well.
This way the "core" team has an open place to discuss some common things like extracting common functionality into a separate package, minimum Node & ESLint target, how to handle disputes between maintainers, ...
Having a channel for each separate package would maybe be a good idea as well, so the community has a change to ask questions to the maintainers as well.

What should be the role of the ESLint team?

I think most important role would be to facilitate at least the contact with @mysticatea, so we can transfer his packages over to the @eslint-community org.

Next to that, I can see the ESLint team talk to the "core" team of the new org regarding creating new community maintained packages that are split out from the main ESLint repo.
Examples of these kind of repos are:

• eslint-plugin-node
  This plugin was recommended because of the deprecation of some rules in v7
  https://eslint.org/docs/user-guide/migrating-to-7.0.0#deprecate-node-rules
• eslint-formatter-codeframe & eslint-formatter-table
  These were both in the main ESLint repo but were removed in v8
  https://eslint.org/docs/8.0.0/user-guide/migrating-to-8.0.0#-removed-codeframe-and-table-formatters
• eslint-plugin-eslint-plugin
  This plugin is (together with eslint-plugin-node) a recommended plugin for linting custom plugins.
  https://eslint.org/docs/developer-guide/working-with-plugins#linting

---

These are just my 2c.
Of course I'm happy to receive feedback from all other persons I mentioned above about this & to discuss this further.

[brettz9]

It looks fine to me but just a few personal notes:

1. There is still a need as @voxpelli well stated, even in the course os ESLint work, for preserving packages which handle other core functionality JS packages that are not plugins or configs, so feel free to make use of @es-joy for these.

2. I want to clarify a bit on my health and how my participation is thus fickle. The fact that I am a committer with ESLint and involved with other ESLint-related projects might be misleading as to my energy (especially tasks requiring mental exertion); @nzakas is aware of my situation; I pretty much just contribute at those times when I am able and also continue work on some projects like eslint-plugin-jsdoc where it is easy enough when already familiar with the terrain--I am not able to regularly help as a regular day-to-day maintainer of ESLint issues, for example. I am simply working toward occasional addition of special features.

As such, I am hesitant to be considered as though I would be having an active role maintaining things in the proposed project. At most, I think I could reasonably be expected to occasionally help ensure a fork of a useful project is renamed and fixed for updates, but that's probably about it. With my proposal for @es-joy, I was more intending to allow other trusted individuals such as yourselves in, not to be a very active co-maintainer, except for those projects I needed in the course of my work.

3. I don't know how helpful I could be in the anticipated role of helping find maintainers, but if ESLint wishes to adopt it officially, of course that's cool by me.

[nzakas]

Please open an RFC :) That’s the official way that we review complex proposals.

[MichaelDeBoey]

Official RFC created: eslint/rfcs#91