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

Change crates.io policy to not offer crate transfer mediation #3646

Merged
merged 2 commits into from
Jun 24, 2024

Conversation

carols10cents
Copy link
Member

@carols10cents carols10cents commented May 24, 2024

@carols10cents carols10cents added the T-crates-io Relevant to the crates.io team, which will review and decide on the RFC. label May 24, 2024
@Diggsey
Copy link
Contributor

Diggsey commented May 24, 2024

We [the Rust Foundation and the crates.io team] will only use your email address to contact you about your account.

I wonder if it's also worth updating the privacy policy to explicitly allow the Rust Foundation / crates.io team to contact people about their published crates as well? Even if transfer mediations are not a thing, I can think of a number of reasons why that might be required.

@carols10cents
Copy link
Member Author

carols10cents commented May 24, 2024

I wonder if it's also worth updating the privacy policy to explicitly allow the Rust Foundation / crates.io team to contact people about their published crates as well? Even if transfer mediations are not a thing, I can think of a number of reasons why that might be required.

Sure, we can make that change too. To me, "your account" encompasses "everything you've done with your account on crates.io including the crates you've published", but that could indeed be clearer.

The ambiguity we're intending to point out for this RFC is who you can expect could contact you via the email given to crates.io-- if we build a form on crates.io for any crates.io user to contact another crates.io user that results in the crates.io website sending an email to your crates.io email address, is that covered by the current statement or would that be unexpected? I lean towards unexpected.

@clarfonthey
Copy link
Contributor

The ambiguity we're intending to point out for this RFC is who you can expect could contact you via the email given to crates.io-- if we build a form on crates.io for any crates.io user to contact another crates.io user that results in the crates.io website sending an email to your crates.io email address, is that covered by the current statement or would that be unexpected? I lean towards unexpected.

I think the key difference here is the source of the inquiries: "about your account" is pretty vague, and instead, could be elaborated to:

  • General account inquiries (logging in, verifying your identity, etc.)
  • Legal inquiries (forwarding legal inquiries to you)
  • Conduct inquiries (in case of a suspected breach of conduct)

This way, it's clear that "account" doesn't mean that we will just talk about anything concerning anything you've done on crates.io, but a narrower scope of "account" meaning specific general account things and only going beyond that scope if it's for legal or governance reasons.

@dlight
Copy link

dlight commented May 27, 2024

As the number of crates on crates.io grows, so do the number of effectively abandoned crates, and so do the number of support requests we get asking us to attempt to contact a crate owner to see if they would be willing to transfer their crate. Managing these requests take time, and they aren't even usually successful. The crates.io team would like to spend their time working on the site rather than providing this crate mediation service.

It's understandable that volunteers wouldn't like to spend their limited time on this thankless task, but have the crates.io team considered the option of hiring full time persons to offer a mediation service on a more consistent basis?

Maybe the Rust Foundation could help with that.

@clarfonthey
Copy link
Contributor

Hiring full-time people just to work on crate transfer mediation? That's kind of a ridiculous proposal; despite being supported by loads of large companies, the foundation just doesn't have the resources for that.

@dlight
Copy link

dlight commented May 27, 2024

Or pass the job to someone employed by the Foundation, which performs this and other jobs. I mean that mediation is useful and if it's not an appropriate job for the crates.io team, the Foundation should step up.

@carols10cents
Copy link
Member Author

Yeah, the members of the crates.io team who are employed by the Foundation (@Turbo87 and @LawnGnome) are the ones who have been doing this work lately. As a non- Foundation member of the crates.io team and a member of the Rust Project who benefits from the myriad things the Foundation does, I think the time and energy of Foundation employees is better spent elsewhere. Never mind that this type of mediation is likely to be yet another thing that people might get loudly angry at the Foundation for their decisions and actions. I don't think these downsides outweigh someone being able to get a claimed crate name occasionally.

@carols10cents
Copy link
Member Author

@rfcbot fcp merge

@rfcbot
Copy link
Collaborator

rfcbot commented May 31, 2024

Team member @carols10cents has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels May 31, 2024
@rfcbot
Copy link
Collaborator

rfcbot commented Jun 1, 2024

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this RFC. and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Jun 11, 2024
@rfcbot
Copy link
Collaborator

rfcbot commented Jun 11, 2024

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@juleskers
Copy link

A factor that I believe is relevant in this, is that crates-team mediation carries more social weight than "random stranger on the Internet asks for transfer".

Combine that with the fact that the (overworked) team is just as (if not more so, due to overworkedness) susceptible to social engineering, and the mediation service becomes a vector for XZ-style hostile package takeovers.

For me, this is an additional, weighty, reason that the crates team should be "hands off" with anything involving transfers.

Additionally, there is no technical mechanism in vanilla cargo to signal maintainer change, making this social support feel inconsistent.

I have always been a fan of the "if you don't like it, invent a more creative name" policy, and think it has resulted in zero downsides for the community.

@carols10cents carols10cents merged commit e70fa73 into rust-lang:master Jun 24, 2024
@carols10cents carols10cents deleted the no-crate-transfer-help branch June 24, 2024 19:58
Turbo87 added a commit to Turbo87/crates.io that referenced this pull request Sep 27, 2024
This PR implements rust-lang/rfcs#3646. For some reason I thought this had already been implemented, but I just stumbled upon that section in the policies and was surprised that it was still in there... 😅
Turbo87 added a commit to Turbo87/crates.io that referenced this pull request Sep 27, 2024
This PR implements rust-lang/rfcs#3646. For some reason I thought this had already been implemented, but I just stumbled upon that section in the policies and was surprised that it was still in there... 😅
Turbo87 added a commit to Turbo87/crates.io that referenced this pull request Sep 30, 2024
This PR implements rust-lang/rfcs#3646. For some reason I thought this had already been implemented, but I just stumbled upon that section in the policies and was surprised that it was still in there... 😅
Turbo87 added a commit to rust-lang/crates.io that referenced this pull request Sep 30, 2024
This PR implements rust-lang/rfcs#3646. For some reason I thought this had already been implemented, but I just stumbled upon that section in the policies and was surprised that it was still in there... 😅
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this RFC. T-crates-io Relevant to the crates.io team, which will review and decide on the RFC. to-announce
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants