feat: create eslint-community GitHub organization

[MichaelDeBoey]

Summary

Facilitate a GitHub organization (eg. @eslint-community) where community members can help ensure widely depended upon ESLint related packages stay up to date with newer ESLint releases and doesn't hold the wider community back.

Related Issues

This was originally put together in eslint/eslint#15929 (reply in thread)

Related discussions

• Roadmap planning 2022 eslint#15383
• Set up `eslint-community` GitHub organization eslint#15929
• feat: support ESLint 7.x mysticatea/eslint-plugin#29 (comment)
• eslint 8 compatibility standard/eslint-config-standard#192 (comment)
• Long term home of eslint-plugin-n eslint-community/eslint-plugin-n#8

---

Rendered version: https://github.com/eslint/rfcs/blob/main/designs/2022-community-eslint-org

[ota-meshi]

This may be off topic, but I received a reply from @mysticatea only once in April. What I found out was that he was so busy with his work right now that he couldn't do it even if he wanted to maintain OSS.
I think it may be possible to take over the maintenance of @mysticatea's package by presenting him a reliable transfer destination.

[munierujp]

Please check my comments.

[bradzacher]

Question - what would be the the policy for things like typescript-specific plugins/rulesets?

[nzakas]

Thanks for putting this together. From what I gather, you are envision the eslint-community org as being completely separate from the eslint org and run by a different team? So the ESLint team would be completely hands off?

My thought was that the ESLint team should curate and manage the org, but you make a compelling case that it can be run independently.

If that’s the case, and there’s interest, we can just transfer the eslint-community org to you and you can do what you’d like with it. :)

Let me know what you think.

[voxpelli]

My thought was that the ESLint team should curate and manage the org, but you make a compelling case that it can be run independently.

@nzakas I think the idea is that the ESLint team is the ultimate caretakers, the assign a core team of people to take care of the effort and they ran the day to day business so that the ESLint team rarely have to involve themselves.

[voxpelli]

Question - what would be the the policy for things like typescript-specific plugins/rulesets?

@bradzacher They would be as eligible as everything else I think?

[MichaelDeBoey]

What would be the the policy for things like typescript-specific plugins/rulesets?

@bradzacher I agree with @voxpelli that TypeScript-specific ESLint related packages would also be welcome in the new org.
Having a separate @typescript-eslint-community org would only fragmentize the community more without any benefit I think.

[nzakas]

I think the general direction here is clear, so Im comfortable moving forward.

[nzakas]

@eslint/eslint-tsc please review this so we can discuss at the meeting.

TSC Summary: This RFC proposes an eslint-community org managed by a separate team but overseen by the TSC. This org would be a repository for important ESLint ecosystem projects and would be able to step on to maintain those projects I’d they fall out of maintenance.

TSC Question: Do we want to proceed with this proposal?

[nzakas]

Moving to final commenting 🎉

[bmish]

It seems like there's ambiguity around when we should move an NPM package to the @eslint-community NPM scope.

On the one hand, it would be nice to keep the existing NPM package name whenever possible to avoid churn so the thousands or millions of users of the package don't have to manually switch from the old name to the new name (the majority of users might never even get around to doing this, resulting in substantial fragmentation). This is my preference.

On the other, there might be organizational benefits to moving packages to scopes?

[ljharb]

I don't think there's much benefit to moving an npm package name. I agree whenever possible we'd want to avoid churn, so the only use case there would be when the original name was somehow unrecoverable.

[voxpelli]

Was about to write the same as @ljharb 👍 Only move when it needs to move

[MichaelDeBoey]

We should aim to get the original repo/npm package, if that's not possible, we should go with a fork and/or publish it under the org namespace

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 into the new org. However, the ultimate goal would
always be to transfer the original repo to the new org.
If we had a temporary fork and are able to transfer the original repo to the new
org, we should first create PRs to the original repo to bring it up to date with
the fork before continuing with other tasks.

[nzakas]

One last note: for security purposes, we should set up a separate npm account for ESLint community projects. It's probably not a good idea to share credentials for ESLint core with community projects.

[ljharb]

Credentials shouldn't need to be shared at all - there's automation tokens for CI, and individual accounts can be added to appropriate org teams as needed.

[nzakas]

@ljharb there is still a vector of attack where a secret token is shared to a repo and the name in package.json is changed to “eslint” to publish a malicious package. With a different account, that would fail; if it uses the same account then it would succeed.

[ljharb]

Totally agree, and fair point on the risks of sharing a token :-) I wouldn't expect credentials tho to ever be shared, and separate accounts seems like a great idea.

(Soon npm will hopefully have the ability to make package-specific automation tokens, but that doesn't entirely fix the scenario you describe)

[nzakas]

We are good to go here! @MichaelDeBoey I'll get you set up with the org in the coming days.