Maintenance & Governance of standard

[mcollina]

Maintenance & Governance of standard

[ungoldman]

The quoted contributing blurb above is boilerplate adapted from "open open source" contributing guidelines, an attempt at loose "wiki" style open governance standards from over a decade ago when the node open source community was much, much smaller and conventions were more easily shared at the community level. Some readers might remember those times :)

The purpose of the standard project was to prevent bike-shedding, avoiding arguments over style and linting and just enforcing something that worked, and for a long while it did work. The style enforced was prevalent among some (but not all) prominent open source node writers at the time standard was created (8 years ago!), and worked primarily for commonJS node written for the server or transformed for the browser with browserify.

The scope of the project has of course grown to encompass a much wider set of use cases since then, and it's been widely adopted across the industry. However, standards and requirements between common, ESM, JSX, typescript, and friends have continued to diverge quite a bit over the years, and for all the worthy efforts of the standard team, keeping up with all flavors of node under one roof is beyond the scope of one loose and scrappy association of (unpaid) open source contributors.

There is also the foundational problem of using eslint as a formatter, which has been written about at length elsewhere.

The good people of this thread could endlessly bikeshed about the correct way to move forward, who is the true and trustworthy heir of the releasers, the proper way to manage the project going forward... but I would humbly suggest something else.

When a project this big has stalled for a long time, and there are so many different voices wanting to do different things, sometimes the best thing to do is retire the project and start fresh.

If you really want to keep standard going as-is, I recommend a fork.

If you have a fresh perspective on solving linting and formatting with a standard-like approach for the current state of the open source JS ecosystem, I suggest creating something new.

If you want to try to commandeer an enormous linting project that's been in maintenance mode for some time, by all means, continue! But at this age, scale, and velocity, discussion threads like these are often where ideas and good intentions go to die.

I share this as someone who was an early supporter and member of the project, wishing you all the best of luck. That said, I'll be bowing out and removing myself from the project.

Happy coding ✌️

[mcollina]

I have been in contact with @feross and I'm making progress on this - not much to update on yet.

[anonrig]

I'd be also interested in maintaining Standard.

[wesleytodd]

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.

[mcollina]

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

[bcomnes]

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

[voxpelli]

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

[meyfa]

From the viewpoint of a user, asynchronous PRs are highly favorable as it allows for visibility of the roadmap and easy participation, without having to commit fully to mob sessions. Currently we are regularly surprised by a large number of breaking changes - almost every release of eslint-config-standard-with-typescript is semver-major. There are even some oversights (mightyiam/eslint-config-standard-with-typescript#1230) bound to happen this way. I feel like the Node.js governance and development model has much more opportunity for users to become involved and prepare for changes, as well as preventing surprises. A wiki-like approach to software development seems highly dangerous and I would not want to use dependencies released in this way, from both a security and reliability standpoint, at least without version pinning and manual vetting of all code.

[voxpelli]

@jay-bulk We’re still actively working on this

[mcollina]

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.

[wesleytodd]

Some example governence docs for reference:

• https://github.com/fastify/fastify/blob/main/GOVERNANCE.md
• https://github.com/expressjs/express/blob/master/Charter.md
• https://github.com/nodejs/node/blob/main/GOVERNANCE.md

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.

[wesleytodd]

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?

[dcousens]

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

[rostislav-simonik]

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.

[jay-bulk]

Would love to hear back from some of the instigators here. This is exactly what got us here in the first place. I'm willing to continue supporting standard, but being roadblocked isn't helping. I definitely have the least amount of experience in the room, but I'm here and I'm willing so I'd love some feedback here or correction if necessary. @mcollina I take @feross comments to mean he trusts you to help us steer the ship forward. Please suggest a time for us to meet and discuss moving forward.

That being said, from the existing contribution guide as mentioned by @mightyiam the original intent may have devolved and may not be the best model moving forawrd. Regardless, if we want to proceed with a OpenJS-like governance model here's a draft PR. Hopefully this will get the ball rolling. I don't care what model we pick moving forward, but I am disappointed at how hard it's getting to get the red tape to clear. As I understand it the idea behind standard is to follow best practice and where one is not offered pick a standard and move forward. Ironic that we're struggling to come up with a standard on our own for managing the project and thus are stopping it from moving forward. @mcollina @voxpelli @wesleytodd @jsumners @theoludwig @bcomnes @anonrig please feel free to strike me down on this or add constructive feedback. I just want to get this moving again.

[mcollina]

I've not been able to reach to feross to discuss this any further.

[jsumners]

Should we schedule a quick call?

Sure. I'll do what I can.

[jay-bulk]

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

[wesleytodd]

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]

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

[voxpelli]

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]

@voxpelli that was aggressive.

[theoludwig]

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:

• #1872 and #1939 somewhat the related issues that made this issue "critical", even if the issue was already there before them.
• standard/ts-standard#291 ts-standard should be in sync with eslint-config-standard-with-typescript, if updates are pushed for the config, ts-standard should receive a update too
• See how to move forward in eslint-config-standard with flat ESLint v9 config

And probably lot more TODOs...

[rostislav-simonik]

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.

[rostislav-simonik]

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]

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?

[rostislav-simonik]

@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

[mcollina]

I understand eslint-config-standard-with-typescript released ~14 major releases over the last year (and ~20 in the last two years). This seems a drastic culture clash with the slow-burning approach standard is used to have.

If you care about the thousands of users of these packages, grant us npm publish access while we continue to discuss governance.

Given I'm one of standard significant users, I'm grateful that you were not given publish access to any of the core components. 14 majors in a year is definitely outside of what I look for when choosing a module.

[LinusU]

I've been a part of Standard for a very long time, and from my feelings the goal of the project have always been to align itself with what people are already using, and only introduce breaking change when we can see that the absolute majority of all projects using standard are already compliant.

That's why a lot of my work have been contributing fixes to other projects ahead of us adding new lint rules, and creating ecosystem analysis reports when we are thinking about adding a new rule.

---

With the recent development in eslint-config-standard-with-typescript, there have been too many breaking changes recently which has lead us to stop using it at my company.

I think that this can be seen in the wider ecosystem by looking at the number of downloads for the different versions, e.g. from last week:

• 40.x - 3k
• 39.x - 133k
• 37.x - 39k
• 36.x - 21k
• 35.x - 25k
• 34.x - 117k
• 23.x - 82k
• 22.x - 34k
• 21.x - 30k
• 20.x - 10k

ref: https://www.npmjs.com/package/eslint-config-standard-with-typescript?activeTab=versions

That's a lot of people using old (in terms of number of major versions behind latest) versions...

Compared to eslint-config-standard:

• 17.x - 1625k
• 16.x - 489k
• 15.x - 15k
• 14.x - 327k
• 13.x - 29k
• 12.x - 128k
• 11.x - 65k
• 10.x - 52k

ref: https://www.npmjs.com/package/eslint-config-standard?activeTab=versions

---

Personally, I would love for the regular Standard to also handle TypeScript, and for it to continue on a slow path forward where new rules are only added after we have verified that the ecosystem already is compliant.

I also have a lot of open source repositories that uses Standard, so I would really not like to see many major releases which requires manual updates.

---

I would be happy to stay on as a maintainer of Standard, if it continues with the philosophy that it has had before, which I described in my first paragraphs here.

---

Finally, I would like to offer my apologies to @mightyiam & @rostislav-simonik. I've seen that you have tried to reach out to me on Discord. Since I only use that when I game or socialize with my friends, it has never been a good time to write out my thoughts clearly when I've seen it. But I felt that the direction that you have taken with the TypeScript standard hasn't been aligned with the philosophy of Standard, and thus I didn't want to give you publish access without this being discussed first. I'm sorry that I didn't initiate this discussion earlier, but I'm happy that it's taking place now!

[mightyiam]

Thank you, @LinusU. There's no problem with frequent introduction of generally desirable rules. Users can upgrade at their own pace. Perhaps I should take eslint-config-standard-with-typescript somewhere else and rebrand it.

[LinusU]

There's no problem with frequent introduction of generally desirable rules. Users can upgrade at their own pace. Perhaps I should take eslint-config-standard-with-typescript somewhere else and rebrand it.

Just to clarify, I'm not saying that one approach is better than the other, and I think that it's great that you have been putting work into something that I hope is enjoyed by people! ❤️

I'm just saying that it's not a great fit for me personally, the way I'm using Standard.

[jay-bulk]

@mcollina it's been almost two months since the last update. I've tried reaching out to you and @feross via twitter to offer assistance. Do you have an estimated time line on when you think we'll start to see progress here?

Sorry, I'm not trying to be a nuisance. You and Feross are both juggling running companies and multiple libraries which is very respectable. I've got projects that would like to see continued maintenance on this repo. However this thread is getting a little long in the tooth. For reference, I reached out to Feross on the issue of maintenance back in September. I want to be helpful but I'm also feeling slightly hand tied without permissions/governance in place.

[mightyiam]

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

[mightyiam]

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

[mightyiam]

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]

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.

[mightyiam]

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

[mightyiam]

By the way, from CONTRIBUTING:

Project Governance

Individuals making significant and valuable contributions are given commit-access to the
project to contribute as they see fit. This project is more like an open wiki than a
standard guarded open source project.

[mcollina]

That being said, from the existing contribution guide as mentioned by @mightyiam the original intent may have devolved and may not be the best model moving forawrd.

My understanding is that it's working as expected. Apparently what's being landed does not meet the criteria/trust of the releasers. Therefore, nothing is getting shipped and the project is locked.

My read of the current situation is that the "mob programming" model is a 100% culture clash with how @feross, @voxpelli, myself and all "old" folks develop OSS. We work asynchronously via PRs, while you all develop together synchronously. This is not fixable without a different governance.

As I said a few times, my overall intent is to unblock standard, because I use this linter and I do not want to fork.

Thanks for putting the PR in. I'm strapped for time until this Wednesday, then I'll make some progress on things (I have a backlog of 250+ gh notifications to process, I've been traveling for a while).

[mightyiam]

Apparently what's being landed does not meet the criteria/trust of the releasers. Therefore, nothing is getting shipped and the project is locked.

Sorry. I never knew. Can this be confirmed, please?

[jay-bulk]

@ungoldman thanks for your solid contributions, hopefully we can do your legacy (and so many others) justice. Best wishes.

@mcollina totally understandable with your time constraints, I for one am grateful for your travels because I'm learning from your talks 😄 (NodeconfEU was awesome BTW, great job). I just want to make sure we don't lose momentum here so we can start publishing again until a long-term solution can be agreed upon. For that matter, I also prefer the asynchronous PR approach. Working mob on this project has been a new and informative experience. However we decide to move forward, I'm here to help.

[mightyiam]

eslint-config-standard-with-typescript is at major version 40. How are major version bumps surprising?

For the record, I'm not certain that mightyiam/eslint-config-standard-with-typescript#1244 included an oversight.

eslint-config-standard-with-typescript is in constant increase in popularity, thanks to the work of myself, @rostislav-simonik and more recently @jay-bulk.

Let's take a look at some statistics. Observations:

• eslint-config-standard-with-typescript recently overtook standard in popularity
• eslint-config-standard and eslint-config-standard-with-typescript are both rising at a similar pace. Since the former is a dependency of the latter, then the former's increase can be attributed to the latter's, which means that otherwise, eslint-config-standard is likely decreasing.

Despite the popularity of eslint-config-standard-with-typescript, it enjoys a marginal issue reporting rate. Many of the issues reported are misunderstandings.

My impression is that users are satisfied. I suppose it's because we've been doing excellent work. We are the only regular contributors to this organization.

If you care about the thousands of users of these packages, grant us npm publish access while we continue to discuss governance.

[rlidwka]

If you care about the thousands of users of these packages, grant us npm publish access while we continue to discuss governance.

Maintaining an open source project does not require npm publish access.

Maintaining an open source project means answering to all the issue tickets, reviewing all the pull requests, and creating new pull requests if a feature is frequently requested, but nobody else is up to do so.

That's the bulk of the work, and it does not require any governance changes, and any permissions whatsoever.

Here's a hundred open issues with zero answers and nobody available to sort them out. If you care about the thousand of users of these packages, you can start right there:
https://github.com/standard/standard/issues

[voxpelli]

Perhaps I should take eslint-config-standard-with-typescript somewhere else and rebrand it.

@mightyiam This has been my proposal all along but your response has been that without the standard branding you wouldn’t get any users.

I think this would be the ideal solution. Moving eslint-config-standard-with-typescript to its own organization with its own governance and standard moving forward with the governance that @mcollina is spearheading

I could for sure help out facilitate the moving of repositories and modules to such a new organization of yours.

This I think would make you and your collaborators and users the happiest and eg me the happiest 😌

[rostislav-simonik]

Finally, I would like to offer my apologies to @mightyiam & @rostislav-simonik. I've seen that you have tried to reach out to me on Discord. Since I only use that when I game or socialize with my friends,

No worries, it's ok.

Guys, the conversation got heated somehow, meantime 😉 . Everybody has good intentions here. It's just that nobody has a crystal ball, so some incompatible decisions were assumed in good faith. That's why I asked to capture the original maintainers' expectations because that info would make it all easier.

@voxpelli @mcollina I understand now that the standard ecosystem expects less drastic changes. That's reasonable.

On sessions with @mightyiam, we chose to do breaking changes more often but with a more minor impact. That comes of course, with not receiving patches or minor updates without mandatory modifications.

Both approaches are viable, but each must be consistent with their users.

And we unintentionally mixed them. So If some changes are incompatible with the standard users, let's revert.

If there is still a will, Let's capture some rules and expectations, and if we agree on them, we can continue. If not, then we separate. There are no wrong options, just options.

@mcollina @voxpelli, is there still an option on the table to have that call where each group can present their own expectations to find out if there is an intersection?

[mightyiam]

Please see #1957.

[Bugs5382]

@mcollina Hey there. So.. I am up for this as well and use ts-standard, in all my projects including the ones for fastify plugins. So let me know!