What is the disputes procedure for packages?

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.

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.

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.

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.

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.

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.

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.

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.

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.

In case it's useful to have one example of a package whose registration now points to a fork, see https://github.com/JuliaRegistries/General/pull/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.

In case it's useful to have one example of a package whose registration now points to a fork, see https://github.com/JuliaRegistries/General/pull/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.

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.

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.

Any volunteers to do number 5?

Any volunteers to do number 5?

May I bring your attention to https://github.com/JuliaRegistries/General/pull/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).

May I bring your attention to https://github.com/JuliaRegistries/General/pull/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).

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 https://github.com/saitoha/libsixel/issues/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.

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 https://github.com/saitoha/libsixel/issues/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.