-
Notifications
You must be signed in to change notification settings - Fork 40
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
Gem ownership custodians and a process for dealing with abandoned gems. #33
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,113 @@ | ||
# Ownership Custodians | ||
|
||
The health of <https://rubygems.org> is important for the community. Having a large number of essentially abandoned gems contributes negatively towards the usability and impression of RubyGems, and we would like to improve the mechanisms for dealing with this problem. | ||
|
||
Developers who want to release new Ruby libraries are often hampered by the lack of good available gem names. There is no formal process for reusing gem names which are effectively abandoned. Informal processes often break down due to lack of trust or uncontactable gem owners. This can create friction for developers as they then have to consider alternative names which are less ideal. | ||
|
||
For users who search RubyGems to find relevant projects, they are often presented with many options which have not been updated for many years. This presents a bad impression of the Ruby community as "unmaintained". This problem will only get worse over time if no effort is made to address the underlying reasons. | ||
|
||
We propose to introduce gem custodians and a process for approving ownership requests where the original owner is unresponsive or uncooperative. This would be an accountable process to deal with abandoned gem namespace and enable valuable gem namespace, which is effectively abandoned, to be reused in a way which is ultimately positive for the Ruby community. | ||
|
||
## Motivation | ||
|
||
There are several cases where the current gem ownership request process can be inadequate. | ||
|
||
- **Deceased Owners**: Sadly, from time to time, gem owners will pass on. In this case, it is not expected that there would be any response from the owner. We need to consider both popular and unpopular gems. Appropriate mitigating factors (like multiple authors) may not be in place when the unfortunate situation occurs. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Repo features such as successor settings on GitHub might be helpful here. Given a successor is defined, the communication for transfer would be possible in the event of death without the need for a more laborious process by Rubygems (which should still kick in as a fallback). |
||
|
||
- **Unresponsive Owners**: Not all gem owners provide their contact details, nor is there any guarantee that their contact details will work. This makes it difficult for informal gem ownership trasferral to occur. | ||
|
||
- **Uncooperative Owners**: Unfortunately, even if contactable, some gem owners are uncooperative. This is understandable as the ownership request might come from someone who is unknown to the original owner, and the various issues surrounding gem ownership (including hijacking important gems, etc). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I really don't think "uncooperative owner" would be considered as valid criteria for removal. It has been an unwritten rule that gem names are first come first serve. We really shouldn't delve into the territory where we have to deal with one person's opinion against other about what is considered useful. We should encourage conflict resolution by communication following code of conduct. This is in line with approach taken by pypi and npm We may be fine with removing/transferring gem names (even if the owner is uncooperative) only if the package is :
Again derived mostly from list used on PEP 541 and npm disputes. |
||
|
||
I propose we introduce a new clearly documented and audited process to deal with these cases. Some members of the RubyGems community are nominated as custodians (could include members of Ruby core team for example, admins on RubyGems, etc). Some pre-requisites like experience, activity, etc may be considered. Those members have the ability to go through a gem adoption process either for themselves or on behalf of another member of the community. | ||
|
||
## Guide-level explanation | ||
|
||
### Gem Adoption Process | ||
|
||
- Given that a user makes an ownership request on a specific gem, after a certain grace period (e.g. 7 days) they can request a gem custodian review. | ||
- The gem custodian can review all details of the user making the request, including all other gem ownership requests they have made, and the details of the current gem ownership request. | ||
- Within certain guidelines, they have the ability to approve a gem ownership request without the express consent of the current owner. | ||
- The gem must meet the general criteria of being abandoned. | ||
- The gem custodian can attempt to communicate with the current owner on behalf of the ownership request. | ||
- The current owner can contest the ownership transfer but this is not a veto power. | ||
- The gem custodian is advised to give sufficient time, at least 30 days, for the current owner to respond. | ||
- Based on this investigation, the gem custodian can approve the ownership request. | ||
- Requests of this nature should be peer-reviewed, and at least one gem custodian independent of the user making the ownership request should confirm the ownership request - this means that gem custodians cannot approve their own requests. | ||
- Gems which do not meet the requirements for being abandoned require the approval of 3 gem custodians. | ||
- Any gem custodian can veto a gem ownership request. | ||
|
||
If this process fails because the current owner rejected the transfer, the ownership request owner can re-request a gem custodian after a period of 12 months. The gem custodian should consider this history in their decision making process. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think similar to PyPI we should have a separate process of gems that will continue the existing project and ones which will remove the existing code/version. I would suggest adding a locking period of 100 days for the latter. In this period the namespace would be empty (all versions yanked) so that any existing users of the gem are aware of removal (and replacement). |
||
|
||
### Abandoned Gem Criteria | ||
|
||
A gem is considered "in use" if the gem itself, or any of its direct reverse dependencies (version specific) have more than 10,000 downloads in the past year. | ||
|
||
A gem is considered "maintained" if the author has logged into <https://RubyGems.org> within the past 12 months. | ||
|
||
A gem is considered to be "valid" if the homepage and other related metadata is valid (e.g. URLs return relevant pages). | ||
|
||
A gem is considered to be "working" if a user can check out and run the unit tests on a supported, non-EOL Ruby implementation. | ||
|
||
A gem is considered to be "stable" if it has a published release `>= 1.0.0`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These are great ideal criteria. Unfortunately, the reality is a bit nuanced. I would recommend removing following criteria:
92% of all version have empty metadata.
more than 80% of traffic we receive is from ruby version which have reached EOL https://ecosystem.rubytogether.org/
rubocop didn't have a stable release for over 8 years. IMHO, we should stick to activity-related metrics like owner responsiveness and recent releases. Downloads can be a good measure if we filter the noise. Further as of now rubygems.org only tracks total downloads (not downloads over a period). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @sonalkr132 we could also map out ownership and owners activities as a factor. I do it already for internal data mining. When owners are active, the change that their packages are not "abandoned" per se is higher. This coulda act as one of the signals. |
||
|
||
Given the above, we compute an "adoption_threshold". If a gem is "in use" and "maintained", the adoption threshold is 6 years. Otherwise it is 4 years. | ||
|
||
A gem is considered "abandoned" if the the most recent release of the gem exceeds the "adoption threshold". | ||
|
||
### Gem Hijacking | ||
|
||
We could also choose to detect certain gem ownership changes that look suspicious. This would be based on various criteria such as popularity and maintainership. In that case, a gem custodian could review the changes and potentially lock the relevant accounts until all the details can be assessed. | ||
|
||
### Example Cases | ||
|
||
#### Deceased Owner of Active Gem | ||
|
||
A gem does not meet the requirements of being abandoned, but is a popular gem used in the community. A user has forked and maintained the gem in some form and wants to release it. This user has demonstrated their commitment and reliability, and their application may be supported by other reputable members of the community. | ||
|
||
They make an ownership request explaining the circumstances. After 7 day grace period, a gem custodian is requested. | ||
|
||
The gem custodian attempts to contact the original owner, who is unresponsive. | ||
|
||
The gem custodian accepts the merits of the original proposal, but they must confirm that the original owner is deceased. Evidence such as GitHub activity, obituaries, etc could be sufficient. Because this gem does not meet the abandoned gem criteria, 3 gem custodians must approve the ownership request. | ||
|
||
They can also propose the alternative to the user making the ownership request that they wait until the gem is considered abandoned. | ||
|
||
#### Deceased Owner of Abandoned Gem | ||
|
||
A gem meets the requirements for being abandoned. A user wants to reuse the gem name and has demonstrated a basic commitment to following through with this. | ||
|
||
They make an ownership request explaining the circumstances. After 7 day grace period, a gem custodian is requested. | ||
|
||
The gem custodian attempts to contact the original owner, who is unresponsive. | ||
|
||
The gem custodian accepts the merits of the original proposal and has sufficient evidence that the original owner is unresponsive. Because the gem meets the abandoned gem criteria, they can approve the request. | ||
|
||
#### Uncooperative Owner of Active Gem | ||
|
||
A gem does not meet the requirements of being abandoned, and is a popular gem used in the community. | ||
|
||
A user makes an ownership request explaining the circumstances. This should be automatically marked as having insufficient criteria for approval. After 7 day grace period, a gem custodian is requested. | ||
|
||
The original gem owner may ignore the ownership request since they consider it spam. They have the option to explicitly reject it, but they may also just ignore it. | ||
|
||
The gem custodian can review the situation including past **ownership requests** made by the user and their outcomes. | ||
|
||
The gem custodian should reject the ownership request and may also choose to provide a note regarding unacceptable **ownership requests**. Continued activity of this nature may result in further corrective action if it is deemed to be abusive. | ||
|
||
#### Uncooperative Owner of Abandoned Gem | ||
|
||
A gem meets the requirements for being abandoned. A user wants to reuse the gem name and has demonstrated a basic commitment to following through with this. | ||
|
||
They make an ownership request explaining the circumstances. After 7 day grace period, a gem custodian is requested. | ||
|
||
During this time, the original owner might make attempts to update or release trivial changes to the gem so that it no longer meets the criteria for being abandoned. | ||
|
||
The gem custodian attempts to contact the original owner. The owner may or may not be responsive. If the original owner is responsive, they can reject the ownership request. However, the gem custodian should take note of this. | ||
|
||
Within 12 months, no further changes to the gem have occurred, and the gem is still effectively abandoned. A gem custodian can be requested again, and in this situation, they should consider whether this is a case of name squatting. | ||
|
||
Because of the efforts of the original owner, the gem may no longer meet the criteria for being abandoned. In this case, 3 gem custodians are required to approve the ownership request. | ||
|
||
## Reference-level explanation | ||
|
||
TBD. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understand the importance of a new gem custodians group. rubygems admins should reserve the right to make the final decision.
IMO, the issue with a new group would be ensuring their motives align with rubygems. Further given that most likely it will be a volunteer position, they may not have the bandwidth of response/resolution within acceptable deadlines (which is currently offered by rubygems support).