Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Gem adoption #1842
RFC for said feature, talks of being able to flag gems by owners as 'looking for help' (
Todo (this PR)
Todo (future PRs)
I had started working on this before npm/event-stream situation. Above was my pitch which still holds, except it doesn't talk of what does ownership transfer means to users of the gem. How can we improve trust of users in code they are installing? This is not the first time this question has come up, and I would say there is fair consensus on TUF:
Problem with TUF as put by tarcieri is: "TUF is, well, tough"
See also: rubygems/adoption-center
olleolleolle left a comment
I read this change carefully, and suggested wording changes.
If you like them, that's fine. If not, that's also fine.
Thanks for adding this piece of functionality.
Kudos for taking this on!
Thank you for your input. @olleolleolle I have updated your suggestions in i18n commit. I hope you found email bodies presentable as you didn't leave any suggestion on them.
IMHO, Adoption and AdoptionRequest better communicate transfer of gem/namespace.
Adoption belongs to user. this is not needed. I would consider edit a nice to have too.
I will add a small github button like tag next to gem name where adoption exists. I think we should not limit characters of body/note, as both adoption and adoption requests are better when detailed with responsibilities and acceptance terms (check screenshots).
If we are to store approver (owner_id/approver_id), we would need to create a token per owner per adoption request(one more relation). Previously, we had issue of email token being leaked as referrer url. I get the idea of making things easier but I think it's best if we avoid email tokens. This PR, sends note of adoption request along with link to gem adoptions path (where owner can approve/close requests after login).
Lastly, AdoptionRequest also has a enum status field, as owners can close/reject adoption requests and we shouldn't delete the record for that.
I really like this idea. Is it deployed yet?
I'm wondering if this forms part of a wider discussion about how to handle gems which are abandoned by their author.
Namespace is a limited resource and there are a ton of gems which were published in 2010-2012 which only ever had a handful of
Just dumping some ideas for further discussion:
How to decide if gems are "unmaintained"
Is the gem still in use?
Can we track monthly downloads? If so, we have a pretty good statistic on whether a gem is in use or not.
Is the gem stable or in development?
Gems which have a "stable" release should have a higher threshold for adoption.
Is the source code still available?
This could also be a warning sent to users - e.g. request that the URL is updated.
Is the user still active?
If users are no longer active, and the gem is no longer being maintained, this is a strong signal that someone else could step in and maintain the gem or reuse the namespace.
Here is some pseudo code. Feel free to play around with the ideas.
class Gem def in_use? if monthly_downloads.last > 1000 return true else reverse_dependencies.any?(&:in_use?) end end def maintained? author.logged_in_recently? && updated_at > 3.years.ago end def valid_metadata? response = get(homepage_url) !response.not_found? end def stable? version >= "1.0.0" end def adoption_threshold if stable? && maintained? return 6.years else return 3.years end end def automatic_adoption? last_released_at < adoption_threshold.ago end end
We could also add a lock flag for gems which are critical, or part of stdlib, etc.
I had one more idea about this, which would be an interesting thing I could do in isolation: upon downloading the gem and installing it (and dependencies), does the code load and do tests run?
There are a couple of ways this could work: using the declared minimum version of Ruby, or testing on all current rubies. It would give a good baseline as to whether gems were actually functioning. Given a gem that's unmaintained, not stable, and non-functional, is there an obligation by RubyGems to continue hosting it?
What could be interesting, is to add an API for tagging gems. If this was the case, I could, for example, build a local test server and actually do this, and then tag gems with the appropriate metadata.
adoption aims to facilitate gem ownership transfer between users, whether requested by gem owner or any rubygems.org user. ownership transfer is already possibly by `gem owner -a/r` command, however to quote bf4: > Being able to make an 'ownership request' on rubygems.org and have current owners able to approve by clicking on a link or otherwise not having to go to the commandline would reduce a lot of friction RFC for said feature, talks of being able to flag gems by owners as 'looking for help' (`adoption.seeked?`), following which other users can make 'adoption requests' (`adoption.requested?`). These requests can be either 'approved' (`adoption.approved?`) or 'rejected' (`adoption.rejected?`). Differentiation between just looking for help and looking for owner/transfer can be communicated through `note` field of adoption. Approval of adoption request with only add requester as owner, and not remove any existing owner. I have chosen to use a single table/model for both flagging a gem as up for adoption and making adoption requests, (contrary to https://github.com/rubygems/adoption-center) for both flagging a gem as up for adoption and making adoption requests, because those two things are not different except status field, also because I want to allow adoption requests to be sent whether gem owner is actually looking for help. On our help site, number of tickets asking gem transfer is "too damn high". All we do on those tickets is add owner of gem to the ticket and hope they reply. Allowing adoption request being sent from site will automate some of our work. Also, I hope it will further discussion about ways of dealing with unresponsive owners.
Adoption update will only be of status (requested -> canceled, requested -> approved, seeked -> canceled, seeked -> approved). Approval of adoption doesn't remove existing owners. index action will show adoption request made by all users to gem owner. Multiple adoption requests can be approved. Adoption requests will show up in view unless canceled by gem owner or requester.
Past of seek is sought, not seeked. I was looking for a word equivalent of `put up for (adoption)` and has past form ending with `ed`. Moved section shown when gem has no open adoption to a partial.
Partial for collection view of adoption makes everything simpler. Ensures only owner can approve adoption request
This was needed because we should save owner_id with approvals and timestamp. It will still have null value for adoption requests where status is opened but it is not as bad as null values with adoptions records created by owners(previously). I had started with one model to keep my change as small as possible.
Also changes adoption to singular resource (`/gems/some/adoption` makes more sense). using `/adoption` for indexing of all adoptions. Template names are changed to better reflect content of file and convention. Timestamp was added to show on adoption index page. Adds validation for presence of note.