Open up the gates for all maintainers

[goldhand]

This is part of the proposal in #2703 (comment)
If @evocateur is the only gatekeeper at the moment (as mentioned in #2703 (comment)), open up the gates for all maintainers at the risk publishing regressions. This is an acceptable trade off because I believe the only alternative is to let lerna wither away before it's time was up. There are ways to mitigate this risk of course. I'm not sure what the state of the unit and integration tests are but that's a place to start. pre-release candidates are another option to help prevent bugs from entering into consumers who haven't opted in to the @next release.

Problem

Having all maintenance go through @evocateur is a huge bottleneck. This was mentioned in @MikeActually's comment #2703 (comment) and I haven't confirmed this with any other maintainers or contributors but if this is the case, this should be addressed ASAP because there's no way this can continue.

Currently, all maintenance must go through @evocateur , since he is most familiar with the project and is one of two people with access to publish changes. Would love to hear what would be acceptable from the owners of this project to help find a LTS model for this package, instead of relying on 1 person to contribute to it in their free time.

[MikeActually]

use CLI:

npm owner ls lerna
evocateur <daniel.stockman@gmail.com>
hzoo <hi@henryzoo.com>

as per https://www.npmjs.com/policies/disputes I did email NPM to advise that I thought the package was abandoned, especially after multiple tags of @evocateur within this github project

I believe I can make a case to take ownership of the NPM package after August 24th. It would still require forking this repo, but I think that might be a better option than just leaving it to die.

I do think there are reasonable alternatives to this package, too, and definitely think people should pursue them, but with close to 1million weekly downloads, I don't see that as being a legitimate solution.

If community does take this over, I do think we'd need to establish some degree of governance and some degree of constant grooming of maintainers. It might be a good idea to list it as a package looking for funding in NPM, too, and leveraging that to encourage "bug bounties", etc.

[goldhand]

I see @MikeActually , If that is the case then I think we should do a new "Call for maintainers issue" with a detailed path on how to become a maintainer and what the expectations / commitment would be for interested parties. The previous attempt, #1172 failed to provide a clear path for interested maintainers.

we'd need to establish some degree of governance

Come Aug. 24th, if you are able to do so, I think setting up a small working group to (quickly) set up this model would be a good course of action. Hopefully this can be flushed out in a few weeks.

[MikeActually]

Sounds good, would you mind working together on that @goldhand ? I don't personally have a strong interest in maintaining Lerna, but would definitely be willing to help move it forward. It was clear that this was struggling, which was why I put in the request to NPM. I have no problem helping until it's in a stable condition, though.

[goldhand]

@MikeActually I'd be interested in being a maintainer but would want to include others who felt and were equipped to do the same. I could coordinate the initial governance meetings to kick things off though.

I believe I can make a case to take ownership of the NPM package after August 24th

I thought we were in August haha, are you able to make the request now @MikeActually ?

Let me know if you want me to fork or need to coordinate more. After I have confirmation from you that this can be transferred, I will begin reaching to people who have participated in discussions recently and create an announcement issue.

[goldhand]

@MikeActually I'm not sure how to reach you but if you can, join lerna.slack. I'd like to discuss some other details and don't think github issues is the place.

[MikeActually]

I thought we were in August haha, are you able to make the request now @MikeActually ?

My bad, my original submission was August 24. I'll join the slack

[goldhand]

Just to clarify for @evocateur, none of this discussion is an attempt to take away lerna from you or other maintainers. As I mentioned in my other comments, I really appreciate all lerna does. I've done a lot of work within my company to support lerna in our internal tooling and I have vested interests in this project / would be happy to be a maintainer.

There's been a long period of silence from maintainers, which I understand, as this is something done in one's free time. For that reason though, I hope that more "owners" or "maintainers" are given ability to autonomously handle incoming PRs and issues. I hope these suggestions help prevent these bouts from happing in the future as well as improve efficiency of contributions.

[Robbie-Cook]

I agree with all of this

[hzoo]

I'm happy to add people as maintainers (given I don't have interest in maintaining), but I will have try to contact @evocateur again about this. But again don't want to do things on behalf of him, don't feel like it's in my place to do that even though I was a part of this a long time ago.

Though this is a pain (in many ways), I think this is why I'm suggesting a fork (at least temporarily) might be the best approach at the moment, given he may not want these changes. It's not as easy to simply merging some PRs, need to understand how releases work, how to deal with regressions, how the codebase is setup, etc. But if he's up for it, we should find some people who are willing and able to help

Just to clarify for @evocateur, none of this discussion is an attempt to take away lerna from you or other maintainers.

Agreed, and thanks everyone for their patience in having to deal with this situation!

[MikeActually]

@hzoo - one thing that is confusing to me is that yourself and @evocateur have expressed a desire to help groom additional maintainers, but whenever interest arises, it seems like you both are worried about giving up control. I think you and @evocateur need to decide what the go-forward plan is for this project. Forking is not too reasonable as it wouldn't easily allow for rolling out the updated library leveraging the NPM distribution system, unless you are ok with deploying releases from a forked repo.

I'd also point out that Git allows rollbacks, and, any undesirable changes can be reverted. Lastly, I think you are highlighting the perils of a single point of failure for a project. I have no problem helping review PRs, it's a major component of my day-to-day outside of Github, if that helps with gatekeeping undesirable outcomes. I think it's also good to manage backlog, but, as you point, the community needs guidance regarding what is allowed/not allowed.

I think nearly everyone who is involved here really is trying to help this project. Can you at least give us some dates/milestones as to what we can expect and when? Especially regarding improving the process surrounding PRs, approvals, and releases. Waiting for someone to address a couple of PRs once or twice a year is not really working out too well.

[hzoo]

EDIT: And who is it that is willing to be collaborators at this point: at least from this thread, @MikeActually and @goldhand?

Forking is not too reasonable as it wouldn't easily allow for rolling out the updated library leveraging the NPM distribution system, unless you are ok with deploying releases from a forked repo.

To clarify, when I mean forking, I don't mean one would fork and release under the Lerna package or name. It would be a different name or a scoped module that people could use.

If people want to fork for their use case they can, the people who are maintaining or not maintaining can keep the old one as is. If we are worried about regressions or things not being a certain way, that is the suggestion: that anyone is free to fork for their use case. This is something you can do now if it is needed for your work in the meantime. What specifically are the issues that need to be resolved?

It's not easy to just start maintaining any open source project (and I applaud the continued initiative and effort), especially for the long run. Funding and contributors don't usually just come because we are asking though, agreed the current approach isn't working but general community help is maybe similar.

Especially regarding improving the process surrounding PRs, approvals, and releases. Waiting for someone to address a couple of PRs once or twice a year is not really working out too well.

I don't think people are disagreeing with the state of things. I don't know the current process either. Pretty sure @evocateur is burnt out trying to figure things out for this project, it's a side thing as well. Hopefully he can make some time to write up some of this, and we can move forward but if you need to make this work now, I'd make/use your fork in the meantime (this is not my suggestion as a solution but a temporary measure).

[Robbie-Cook]

@hzoo Thank you for your response. I appreciate all your effort.

Having said that, some of the things you have said in here do worry me a little.
To me it seems like what you are saying is:

• @hzoo and @evocateur do not want to maintain this.
• Forks will not be merged into Lerna, ever

To clarify, when I mean forking, I don't mean one would fork and release under the Lerna package or name. It would be a different name or a scoped module that people could use.

• We're not going to add any maintainers
• Go away and use your own fork.

Dropping a package with 1 million weekly downloads seems like a bit of a problem, even just from a security standpoint.

Forking is a really bad solution, because the goal is to coordinate, and not splinter, a package.

The community could create a new branch & package called lerna@next, with greater access permissions, say @goldhand and @MikeActually . This way regressions won't make it into the old branches, access permissions can be opened on one branch only (https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/enabling-branch-restrictions), and we don't have to create an entirely new package that does the exact same thing, but is maintained.

[evocateur]

Apologies, I'm extremely burned out. I'm cool with something like https://github.com/all-contributors/all-contributors, bonus if a bot can automagically backfill all previous contributors.

[Berkmann18]

I'm cool with something like https://github.com/all-contributors/all-contributors, bonus if a bot can automagically backfill all previous contributors.

That's not possible yet as we (speaking as a core maintainer of All Contributors) are short-staffed and had a lot of blockers on stuff including this auto-fetching feature (currently in the works for the CLI and hopefully something that will be ported to the bot as well).
In the meantime, you should be able to use the CLI or bot but it wouldn't be fully automatic.

[JamesHenry]

Hi Folks 👋

You may or may not know that lerna is now under the stewardship of Nrwl (announcement here #3121), a company with a long history of not just producing valuable open-source software (OSS), but also backing others (at the time of writing, Nrwl has donated over $50,000 to OSS it hasn't created, see https://opencollective.com/nx for full details).

Quite simply, Nrwl ❤️ OSS, and is committed to making lerna the best it can be. We use it ourselves.

We hope you will continue to be a part of this community as we look to take things forward from here!

Please see #3140 for more details on our plans for 2022.

[Robbie-Cook]

Thanks @JamesHenry