What is the disputes procedure for packages?

[aminya]

The general registry of Julia is a centralized registry similar to NPM. NPM has a disputes procedure for the cases where there is an unmaintained package, and new maintainers want to continue developing it.

https://docs.npmjs.com/cli/v6/using-npm/disputes

TL;DR
Get the author email with npm owner ls
Email the author, CC [email protected]
After a few weeks, if there's no resolution, we'll sort it out.

In other words: NPM allows the new maintainers to email the old owners of the package and ask them to give them write access. If the authors agree, or they do not respond, NPM itself moves the package to the new owners.

Given the fact that General.jl is similar to npm, there should be a similar mechanism for handling such cases.

[Nosferican]

The registry doesn't "care" itself who the maintainer is. If you are referring to moving the repository (rename or change the GitHub owner), you can make the transfer and open a PR to change the registry entry to look for the source in the new place. Usually having the original owner comment on the PR acknowledging it is enough for the registry maintainers to approve / merge it.

[aminya]

Usually having the original owner comment on the PR acknowledging it is enough for the registry maintainers to approve / merge it.

What is the situation for the cases where the repository is unmaintained and the original authors do not respond? NPM gives them a few weeks of time, and if there was no answer, it moves the repository to the new authors.

[DilumAluthge]

We can handle this on a case by case basis.

Has this ever actually happened in the Julia ecosystem? In my experience, we are usually able to get ahold of the owner of the relevant GitHub repo. The owner then transfers to the GitHub repo to a GitHub organization that has multiple members. Once the transfer is done, we update the URL of the GitHub repo in the relevant Package.toml file in the General registry.

So this all seems very theoretical to me. If someone has a specific case that they want to discuss, that might be more helpful.

[DilumAluthge]

Ultimately all decisions about the General registry are made by the maintainers of the General registry. This is documented in the README.

That being said, the maintainers always welcome comments from the entire Julia community, whether on GitHub, Discourse, or Slack.

[CameronBieganek]

Has this ever actually happened in the Julia ecosystem?

@DilumAluthge I believe this has happened with EzXML.jl. See this issue. EzXML is a nice package, but it needs a few updates and it appears to be unmaintained. And the package owner has not responded to an email from @aminya.

Of course, if worse comes to worst, we can fork the package and register it as a new package.

[DilumAluthge]

Okay, it helps to have a concrete example.

[aminya]

So, should I just make a PR and change the link of the repo?

For EzXML, I should probably make a fork in one of the big open organizations such as JuliaData or JuliaWeb, and then change the link to that fork.

[DilumAluthge]

I've started a discussion in Slack (in the #pkg-registration channel). Let's see what people think.

[DilumAluthge]

@aminya I pinged you on Slack. @CameronBieganek I tried to ping you but I could not figure out your Slack username. You can join the #pkg-registration channel to see the discussion.

[CameronBieganek]

I actually don't use Slack, yet... 😬 😂

[mcabbott]

In case it's useful to have one example of a package whose registration now points to a fork, see #3906 .

The package https://github.com/AndyGreenwell/GroupSlices.jl had no commits after May 2017 (more than 2 years before), and various PRs to fix it for Julia 0.6 & 0.7 went unanswered. The owner was not active on github at all, and several attempts to contact him (someone had his email) went unanswered.

[DilumAluthge]

Copying my comment from Slack for posterity:

Alright, how about this as an action plan:

1. @aminya forks the EzXML.jl repo, and then transfers his fork to the JuliaData organization.
2. @aminya makes a PR to General to edit the URL of EzXML so that it points to the JuliaData fork.
3. Per Avik's suggestion, we leave this PR open for two months. During that time, we repeatedly ping @bicycle1885 in that PR. We also document (e.g. via screenshots) attempts to contact @bicycle1885 on other platforms (Slack, email, etc.), and put those screenshots in a permanent place (e.g. GitHub) for posterity.
4. If we don't hear from @bicycle1885 after the PR has been open for two months, @aminya can ping me on GitHub and I will merge it.
5. Someone (any volunteers?) makes a draft PR to add a new dispute policy to the General registry README. That person also posts this draft PR to Discourse to get feedback from a wide audience.

[DilumAluthge]

Any volunteers to do number 5?

[Arkoniak]

May I bring your attention to #32416? The original author is not completely missed since he accepted PR a few weeks ago, but he is not responding on email or Github mentions. I am not in a hurry, but I am already waiting for three weeks and I have to use ugly things like embedding code in my repo (https://github.com/Arkoniak/ZulipReminderBot.jl/blob/master/src/dotenv.jl), because otherwise I have issues with CI. By the nature of my work I would like to use dotenv approach in the future, so it would be really great to resolve this situation one way or another:

• wait some time (?how much? Should previous 3 weeks be taken into account?) and then transfer package to JuliaWeb.
• register DotEnv2
• rename DotEnv2 to something else and register this new package.

I am agreed to any resolution, just I do not want this question to hang indefinitely (well, to be honest, if it is not solved, I'll just go with third option, since I need this package).

[johnnychen94]

Has this ever actually happened in the Julia ecosystem? In my experience, we are usually able to get ahold of the owner of the relevant GitHub repo.

Reexport is also such an example, @ararslan is given the write permission but he's not able to set up CI related settings. It would be more convenient if this package gets forked in an organization with proper CI set up. Of course, given that Reexport is a very small and stable package, this issue is not very urgent for Reexport.

Copying my comment from Slack for posterity:

I think we also need a fork announcement in the original repo with valid justification. For example, why you fork this repo, will you be the right person to maintain the fork, what's your plan on the future of this fork, and the license. (I just saw a very well-written announcement on fork saitoha/libsixel#154 and I feel it is a good reference.)

If the fork is too breaking or even malicious, the entire ecosystem will be affected by redirecting the URL in General without approval from the original author. Personally, I don't want to see a random person, who never has direct communication with the author via PR/issue discussions, fork the package; I'd rather that package die without any further maintenance.

[ctrlcctrlv]

It can happen. GitHub has procedures for the death of a repository owner, but those only apply in the case of an actual death, not an unexplained disappearance, as has happened at libsixel, thus my overdue fork and self-designation as lead maintainer de facto.

[DilumAluthge]

This is the only remaining task that needs to be done:

Someone (any volunteers?) makes a draft PR to add a new dispute policy to the General registry README. That person also posts this draft PR to Discourse to get feedback from a wide audience.

If someone wants to take on this task, please:

1. Make the PR as a draft to this repo (JuliaRegistries/General).
2. Post the draft PR to Discourse to get feedback from a broader audience.

Please ping me in both the PR and the Discourse post.

[ulysses4ever]

The last bit — updating the documentation — is very important. I think until it's done, this issue should remain opened.