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.

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

Maintenance & Governance of standard #1948

Open
mcollina opened this issue Nov 14, 2023 · 54 comments
Open

Maintenance & Governance of standard #1948

mcollina opened this issue Nov 14, 2023 · 54 comments

Comments

@mcollina
Copy link

After a long twitter thread and looking at the contribution graphs, it seems that to keep supporting Standard users, we need to come up with some new governance.

I maintain hundreds of packages relying on standard, Including the whole Fastify organization (discussion link fastify/fastify#5159). It seems simpler to help maintaining this than moving all of those to a different formatter / linter.

@feross said he would trust me to help with governance and kickstart the work again.

Should we schedule a quick call?

@standard/team @voxpelli @jsumners

@mightyiam
Copy link
Contributor

A mob consisting of @rostislav-simonik , @jay-bulk and I are trying to adopt this project. We are working on it four hours weekly.

I say trying because we haven't yet received npm publish permission for anything other than eslint-config-standard-with-typescript.

Would you be interested in hopping in during one of our sessions?

Schedule here:
https://mobusoperandi.com/mobs/standard.html

@mcollina
Copy link
Author

The mob programming model does not really work for the rest of us. I don't think I would be able to join your mob call anytime soon.

@theoludwig theoludwig pinned this issue Nov 14, 2023
@mightyiam
Copy link
Contributor

Sorry—just to clarify—the rest of us whom, please?

@jsumners
Copy link

Should we schedule a quick call?

Sure. I'll do what I can.

@mcollina
Copy link
Author

Sorry—just to clarify—the rest of us whom, please?

Currently, no one is doing releases for this project, and it has essentially stalled.
I need this linter to be maintained and moved forward as I have hundreds of packages depending on it, and I offered @feross my help to set up a governance model for this project. In that long twitter thread it appeared that quite a few people would be happy to keep moving this forward, and after @feross tweet I opened a discussion.

@voxpelli has been doing releases for the last 2 years, and this initiative has its blessing as well.

Ultimately, I would prefer to move this forward vs forking, but forking is 100% an option.

cc @wesleytodd

@rhettjay
Copy link
Member

@mcollina I'm the newest "member" to join the mob group. I'd be happy to hop on a call and fill in the gaps if the rest of the team is unable.

@mightyiam
Copy link
Contributor

Sorry. Of course I'll be happy to join whatever call you're organizing. I'm also sorry that our mob did not receive @feross' trust by now and that this is happening instead. @feross did, however, let us know that he will look into our past contributions during December in order to assess his faith in us.

@mightyiam
Copy link
Contributor

For context, eslint-config-standard-with-typescript, the package I've authored and have been maintaining for several years and more recently with the help of @rostislav-simonik and @jay-bulk in our mob seems at a level of popularity similar to the standard package.

For more context, here is a message I wrote earlier on Discord. And a copy-paste here:

Expanding Rostislav and mightyiam's contribution, into core

After years of working on eslint-config-standard-with-typescript, and more recently, regularly, in mob format, with the experienced, capable and cooperative @rostislav-simonik, it seems that in order for it to evolve with the ecosystem, the core packages eslint-config-standard and standard must also evolve.

eslint-config-standard-with-typescript is implemented in TypeScript, has a comprehensive test suite, linting of the code (of course), linting of commit messages (semantic commits), automatic dependency bumps (renovate), CI where all this happens, CD which makes automatic releases (including figuring out the version bump using semantic-release), a pre-commit hook and a commit-msg hook and has been developed in a principled manner.

To begin Rostislav's and I's contribution to core, we would like to begin by sharing this infrastructure with the core packages.

The first PR for that is already open at standard/eslint-config-standard#282.

Rostislav (for months) and I (for years) have been happily making arbitrary (read "tough") decisions regarding complex matters in eslint-config-standard-with-typescript and thus making progress persistently. (https://github.com/standard/eslint-config-standard-with-typescript/graphs/contributors).

In expanding our contribution into core, we would love to maintain a similar attitude, albeit with extra care, both because changes in core affect a wider user base and because in core more fundamental changes can be made.

Having communicated this, we are going to proceed in this fashion.

Technicality: Rostislav had admin role in eslint-config-standard-with-typescript for a while. I gave him owner role in the org today.

Technicality: there seems to be a branch protection in place, at least in eslint-config-standard, where at least one review is required. Since Rostislav and I work in mob programming format, we will be approving the PRs that create in this format ourselves.

We couldn't get far on any package other than eslint-config-standard-with-typescript due to lack of npm publish permissions on them.

We are three capable developers who've for the past few months have been blocked from maintaining this package set by lack of faith.

And now someone else who seems to have won @feross faith is tasked to organize governance.

This doesn't make me feel wanted.

@wesleytodd
Copy link

Based on this issue it sounds like official governance to maintain commit/publish access would be very helpful. Even the best individual maintainers cannot keep juggling everything, and the "lack of faith" problem is more about not having a governance model in place for building that trust. Really happy to help out here, especially knowing there are people who want to do the work.

@voxpelli
Copy link
Member

I'm +1 on @mcollina here, but I guess you know my point of view on this @mightyiam

@voxpelli
Copy link
Member

First task of your group @mightyiam should be to at least get ts-standard up to date: standard/ts-standard#291

Before that's done there's nothing showing that you are aware of or in line with the philosophy of this project

@mightyiam
Copy link
Contributor

@voxpelli that was aggressive.

@mightyiam
Copy link
Contributor

I'm not sure I have npm publish permission for that package.

@theoludwig
Copy link
Contributor

theoludwig commented Nov 14, 2023

The issue of maintenance & governance of Standard definitely makes sense, as the maintenance/development is quite inactive outside of eslint-config-standard-with-typescript.

Standard need maintainers volunteers, there are already @mightyiam showing his interest and others.
I'm not against it, and it's really cool that there are still people interested in maintaining Standard, so I'm all for it. 😄

Now... Not everyone agrees, and I can understand that giving npm publish permission to someone is risky and the decision should be taken carefully.

Maybe, the current maintainers having the npm permissions, could at least review the PRs and release new versions when needed, building the trust in collaboration with the ones submitting the PRs.
After a while, the people submitting the PRs could be granted the permissions to publish on npm, and continue forward.

We might also define the list of TODOs and the goals of Standard moving forward, what I see already are the following issues:

And probably lot more TODOs...

@wesleytodd
Copy link

Some example governence docs for reference:

I think it is important to scale the governence process to the project scope. I don't think something as complicated as Node's is needed here, but also express's is a bit lacking imo. I really like the way fastify structures this, and I think a few key things need to be established:

  1. Central TC with final decision making authority, ideally with a majority vote model
  2. Distributed control of the individual packages so that folks can make fast progress in those areas.
  3. A method of managing access right, and a path to go from a new contributor to a maintainer

If having a sustainable model is the goal, we need some more generic governance practices before really digging into the list of todos imo. Not that it should stop folks from working on those, but to keep things going smoothly with a large group there needs to be some small structure around the goals and decision making.

@rostislav-simonik
Copy link
Member

Hello,

All topics mentioned here are essential, but I suggest not deviating too much.

The most pressing issue now is to unblock those willing to spend time on this project because the most precious thing they offer is their time. I understand that new people could have different objectives, and original maintainers are cautious that we won't deviate from the original purpose of this project.

To mitigate this risk, let's try to capture goals and principles a little bit better. So, each contributor can follow them, and PR reviews would become a formality rather than a necessity.

During work on eslint-config-standard-with-typescript, we were following a few rules.

  • Follow the upstream - If there is eslint rule in standard already we just made the typescript one to that image
  • if it's unclear, let's pick the one that makes the code safer but not harms existing users too much.

But there were a few cases where we had the dilemma of what would be the option, not violating upstream concept principles.

So if @feross and the other original maintainers could spend one hour or two to capture those principles into some standard bible, it would make our decision-making much easier.

And then who would have lead decisions or who will own the npm access tokens, would be the least concern.

@anonrig
Copy link

anonrig commented Nov 14, 2023

I'd be also interested in maintaining Standard.

@bcomnes
Copy link
Member

bcomnes commented Nov 14, 2023

I vote for forks, and then if any of them become a clear successor, feross can consider re-merging. My sense is that conflicting interests/priorities have developed over time and are a major factor in lack of maintenance.

I'm also open to an open governance approach, but it also depends on what that turns into.

Generally my priorities would be:

  • A low/no config/debate linting tool in the style of the node.js ecosystem
  • Basic formatting built in with a --fix flag (single tool/rule set linting + formatting)
  • LSP support
  • Configuration around contentious topics (asi min-maxing)
  • Basic zero-config typecript/jsx support (should just run on common non-standard syntaxes without fuss).

@wesleytodd
Copy link

I agree on those priorities I think, but I am not sure why forking is better. Forking means many people need to make changes across hundreds of repos. I have not followed all the convos here, so I can probably brush up on what has been going on, but is there an example of something that is an incompatible opinion among contributors in this ecosystem?

@rostislav-simonik
Copy link
Member

is there an example of something that is an incompatible opinion among contributors in this ecosystem?

Like this one Basic formatting built-in with a --fix flag (single tool/rule set linting + formatting) , it's one of the challenging topics. There are two groups, one that believes standard should abandon all formatting rules and leave it for formatters like prettier, and then the other one that expects that standard should be zero-config tool that gives you everything.

But I was always wondering why both couldn't live. What prevents having a formatless config and then another that lives above that?

@wesleytodd
Copy link

wesleytodd commented Nov 14, 2023

Yeah, these are the kinds of topics you have a TC and governance doc to help guide a decision for. Ideally that governance group represents the diverse opinions of the users of the project, but even if not should strive to resolve the discussion in a way that keeps it healthy. Nothing in that topic (although controversial) seems like something impossible to reconcile. It seems like right now the problem is not even agreeing on a direction but shipping anything. So maybe we unlock the ability to make small uncontroversial changes now and then make the second agenda item listing and deciding on a direction for those more contravertial changes?

@dcousens
Copy link
Member

dcousens commented Nov 15, 2023

If you used a GitHub action with required reviewers to publish, could that help unblock progress?

@voxpelli
Copy link
Member

If you used a GitHub action with required reviewers to publish, could that help unblock progress?

Problem is lack of governance not lack of publishing

@rostislav-simonik
Copy link
Member

@mcollina, so what are the next steps? When do you plan to throw a meeting? Can we please pencil the agenda for that call? Do we have some expectations of what we should prepare before the call?

If I could provide my requirements ahead of time, then those would be mostly related to typescript ecosystem and automated CI

  • to establish clear goals and principles for adding new rules or maintaining existing
  • to establish a RACI matrix between standard and standard-with-typescript. Changes in the standard config have an impact on the typescript config.
  • e2e & unit-tests & automatic releases
  • eslint flat config

@wesleytodd
Copy link

wesleytodd commented Nov 15, 2023

I would push us to have a discussion that is not that in the weeds initially. All of those topics are pretty in the weeds and getting governance in place is more high level. So the meeting should discuss project leadership, decision making guidance, how to manage access and publish rights, etc. And then all those points can be for later discussions or async in issues.

@rostislav-simonik
Copy link
Member

Yes, I agree. I listed them mostly to understand which group I belong to.

Ideally, it would be best if the governance model would incorporate rules for effectively transferring responsibilities from concerning people who become busy with something else. Or effective substitution,

Because that's what is/was the current issue. Not the lack of interest to maintain/govern, but not having enough time to onboard new group.

@bcomnes
Copy link
Member

bcomnes commented May 30, 2024

I see this as an effort to eliminate some indecision paralysis while trying some bolder ideas. Thanks for the hard work from everyone involved and I hope the efforts will benefit the community going forward. FWIW, I'm open to reconciling efforts in the future if that possibility makes sense.

@theoludwig
Copy link
Contributor

Probably time to deprecate standard, if no one want to maintain it anymore.
Should probably update the README to tell people, it is not recommended to use in new projects, and instead recommend other projects like https://github.com/neostandard/neostandard.

@bcomnes
Copy link
Member

bcomnes commented Jun 1, 2024

I think deprecation would be premature at this point.

meyfa added a commit to meyfa/eslint-config that referenced this issue Jul 26, 2024
The governance of eslint-config-standard and -with-typescript is unclear
and causing trouble for this project. This patch pulls in the relevant
code from -with-standard as a first step towards fully owning the
ESLint configuration. A follow-up patch is planned to do the same for
eslint-config-standard.

By doing this, we are able to upgrade `@typescript-eslint/eslint-plugin`
from v6 to v7, which is the current latest version.

Refs: standard/standard#1948
Refs: standard/standard#1957
meyfa added a commit to meyfa/eslint-config that referenced this issue Jul 26, 2024
…195)

The governance of eslint-config-standard and -with-typescript is unclear
and causing trouble for this project. This patch pulls in the relevant
code from -with-standard as a first step towards fully owning the
ESLint configuration. A follow-up patch is planned to do the same for
eslint-config-standard.

By doing this, we are able to upgrade `@typescript-eslint/eslint-plugin`
from v6 to v7, which is the current latest version.

Refs: standard/standard#1948
Refs: standard/standard#1957
meyfa added a commit to meyfa/eslint-config that referenced this issue Jul 26, 2024
Continuation of #195. Dropping the dependency on eslint-config-standard
due to unclear governance, and since it can be considered unmaintained.

Refs: standard/standard#1948
meyfa added a commit to meyfa/eslint-config that referenced this issue Jul 26, 2024
Continuation of #195. Dropping the dependency on eslint-config-standard
due to unclear governance, and since it can be considered unmaintained.

Refs: standard/standard#1948
@johnwatson484
Copy link

Since we sadly could reach no conclusion on this me, @mcollina, @wesleytodd, @bcomnes have gone ahead and created the neostandard project that aims to carry the torch forward under an open governance model.

Just want to fully understand what the full impact of this decision is?

Does this mean that Standard.js will remain as is, static with no further updates, patches, fixes etc? Therefore, a potential risk long term and we should look to adopt something else to mitigate that risk?

@bcomnes
Copy link
Member

bcomnes commented Jul 26, 2024

neostandard is an open governance fork that includes some modernizations and updates to the existing standard, as well some larger architectural changes (like leaning into the eslint ecosystem a bit more heavily to take advantages of LSP tooling). It's still a bit under development but worth checking out if you want access to the improvements it makes now.

I had a discussion with @feross the other week and he is open to reconciling the neostandard fork back into mainline standard and adopting the governance model neostandard has adopted. Currently discussing with those involved. That would be my personal desired outcome.

In the meantime, standard continues to work as is.

Alkarex added a commit to FreshRSS/FreshRSS that referenced this issue Aug 4, 2024
* Migrate to ESLint 9
* https://eslint.org/docs/latest/use/migrate-to-9.0.0
* https://eslint.style/guide/migration
* https://github.com/neostandard/neostandard/ (standard/standard#1948)

fix broken Dependabot PRs such as #6680

* comma-dangle rule is already included

* Use more standard filename

* More flexible syntax globals

* resolveIgnoresFromGitignore

* Dependabog update

* Relax object-shorthand

* GitHub action node-version

* GitHub action node-version again

* object-shorthand: off

* node >=18 due to dependencies
dgdavid added a commit to agama-project/agama that referenced this issue Sep 16, 2024
Because standard does not support ESLint 9 yet because a governance
issue, see standard/standard#1948 (comment)
Cruikshanks added a commit to DEFRA/water-abstraction-system that referenced this issue Nov 14, 2024
I happened to hit upon one of the previous issues we'd come across when considering how we could get ESLint and StandardJS to work together. [Support for Eslint v9 Flat Config format](standard/eslint-config-standard#411) was one of the blockers that meant to have both ESLint and StandardJS play ball, we were stuck on ESLint v8.

I spotted that there had been some [recent activity](standard/eslint-config-standard#411 (comment)), all of which referenced an alternative called 'neostandard'.

And oh my! All my issues/dreams were answered

- Built for ESlint to avoid the need for separate IDE tooling
- Built for the latest ESLint (v9) so flat-file config is supported
- Just like we did, any style rules have been updated to use @stylistic/eslint-plugin
- A desire to work with current practices. So, banning or requiring ; is an option, along with disabling style rules for those opting to use prettier

For context, maintenance on StandardJS and related packages like eslint-config-standard has been stalled for some time. neostandard references the issue as being a [block in governance and direction of travel](standard/standard#1948). I've not been through every message, but it appears the maintainers are split between those who remained committed to StandardJS's 'one-tool one way' approach and those looking to move to where most folks are: ESLint.

Even our own @johnwatson484 [has gotten involved!](standard/standard#1948 (comment))

The thread suggests that those behind StandardJS are open to reconciling the neostandard fork with StandardJS. But that comment was made some time ago. My bet is neostandard is here to stay as the successor to StandardJS.

So, this change strips out all my hand-cranked implementations of the StandardJS rules, including those it was implementing from other plugins and replaces them with neostandard.

Lovely!
Cruikshanks added a commit to DEFRA/water-abstraction-system that referenced this issue Nov 22, 2024
I happened to hit upon one of the previous issues we'd come across when considering how we could get ESLint and StandardJS to work together. [Support for Eslint v9 Flat Config format](standard/eslint-config-standard#411) was one of the blockers that meant to have both ESLint and StandardJS play ball, we were stuck on ESLint v8.

I spotted that there had been some [recent activity](standard/eslint-config-standard#411 (comment)), all of which referenced an alternative called 'neostandard'.

And oh my! All my issues/dreams were answered

- Built for ESlint to avoid the need for separate IDE tooling
- Built for the latest ESLint (v9) so flat-file config is supported
- Just like we did, any style rules have been updated to use @stylistic/eslint-plugin
- A desire to work with current practices. So, banning or requiring ; is an option, along with disabling style rules for those opting to use prettier

For context, maintenance on StandardJS and related packages like eslint-config-standard has been stalled for some time. neostandard references the issue as being a [block in governance and direction of travel](standard/standard#1948). I've not been through every message, but it appears the maintainers are split between those who remained committed to StandardJS's 'one-tool one way' approach and those looking to move to where most folks are: ESLint.

Even our own @johnwatson484 [has gotten involved!](standard/standard#1948 (comment))

The thread suggests that those behind StandardJS are open to reconciling the neostandard fork with StandardJS. But that comment was made some time ago. My bet is neostandard is here to stay as the successor to StandardJS.

So, this change strips out all my hand-cranked implementations of the StandardJS rules, including those it was implementing from other plugins and replaces them with neostandard.

Lovely!
Cruikshanks pushed a commit to DEFRA/water-abstraction-system that referenced this issue Nov 22, 2024
DEFRA/water-abstraction-team#115

Now, we are a team of seven, with seven different opinions on the 'right' way to write the code! Because of our size, we are splitting into two teams to focus on various features simultaneously. But we'll still be working with the one code base.

We'd already moved from just using [StandardJS](https://standardjs.com/) to lint our code to using **StandardJS** via **ESLint** (we kept the rules but not the tool) because there are too many cases where **StandardJS** has no ruling, but we wanted one.

However, each time these rules don't provide a style convention, the team must stop, discuss, debate, and finally decide how something will be done. We want something else to take the decision away from us!

Step forward [Prettier](https://prettier.io/). **Prettier** is an opinionated code formatter that focuses only on the style of the code.

> Prettier enforces a consistent code style (i.e. code formatting that won’t affect the AST) across your entire codebase because it disregards the original styling by parsing it away and re-printing the parsed AST with its own rules that take the maximum line length into account, wrapping code when necessary.

So, any rules or conventions we have that would affect the [Abstract Syntax Tree (AST)](https://www.nearform.com/insights/what-is-an-abstract-syntax-tree/) would still be controlled by **ESlint**. These are the things as a team it is worth spending time debating and agreeing.

For the rest, we intend to let **Prettier** take over. It is widely used across the JavScript community and is popularly advocated for teams that become large or dispersed like ours.

Our approach to the adoption was first to remove our existing **ESlint** config, add **Prettier**, and then let it update all the files.

Then, having checked through as a team there were no 'red-line' changes, commit them. We then add **ESlint** back in and only re-apply the non-stylistic rules.

Our research found that JSDoc is still better managed through **ESlint** (**Prettier** does nothing with it), so we also added our original config for that.

Another fundamental change is that we are no longer bringing in **StandardJS** as an **ESlint** extension. This means we can move to the latest **ESlint** v9 and away from the [deprecated config file format](https://eslint.org/docs/latest/use/configure/configuration-files-deprecated) to the new [flat file config](https://eslint.org/docs/latest/use/configure/configuration-files).

Previously, we'd been blocked because extensions are not supported in ESLint v9. **StandardJS** does provide [eslint-config-standard](https://github.com/standard/eslint-config-standard), but along with the core project, it does not appear to be actively maintained, is still using the deprecated **ESLint** style rules and has an error so cannot be used.

> See [Switch to new eslint config format](#991) for more details on why this was blocking us

We'd resigned ourselves to manually copying and updating the rules from their plugin when we revisited an old issue when first switching to **ESLint** with **StandardJS**. [Support for Eslint v9 Flat Config format](standard/eslint-config-standard#411) was one of the blockers that meant to have both **ESLint** and **StandardJS** play ball, we were stuck on ESLint v8.

We spotted that there had been some [recent activity](standard/eslint-config-standard#411 (comment)), all of which referenced an alternative called [neostandard](https://github.com/neostandard/neostandard).

And oh gosh! All our dreams were answered.

- Built for ESlint to avoid the need for separate IDE tooling
- Built for the latest ESLint (v9), so flat-file config is supported
- Just like we did, any style rules have been updated to use @stylistic/eslint-plugin
- An explicit desire to work with current practices. So, built for use with ESLint only, banning or requiring `;` is now an option, and disabling style rules for those opting to use **prettier** is possible

For context, maintenance on **StandardJS** and related packages like **eslint-config-standard** has been stalled for some time. **neostandard** references the issue as being a [block in governance and direction of travel](standard/standard#1948 (comment)). I've not been through every message, but it appears the maintainers are split between those who remained committed to StandardJS's 'one-tool one-way' approach and those looking to move to where most folks are: **ESLint**.

Even our own @johnwatson484 [has gotten involved!](standard/standard#1948 (comment)).

We're betting this isn't going to be resolved any time soon, so to avoid us having to maintain standard rules in our ESLint config manually, the final fundamental change to highlight is we're now using ESLint + neostandard to manage coding rules.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests