rubygems.org: RFC: Add a Gem adoption status and ownership request approve/reject workflow

Scenario: The happiest of happy paths is to enable communication dev-to-dev, requiring no external involvement.

Given: An authorized and authenticated gem owner either via a gem command, gemspec metadata, or on the rubygems.org site

Feature: advertise gem looking for owners

When the gem owner sets ‘looking for maintainers’ to be true Then an ‘adoption’ record is associated with the gem which also includes the user’s id and the date

When a gem has an associated adoption record Then the gem’s page will show that it is ‘up for adoption’ And there will be an interface for an authenticated rubygems.org user to make an ‘adoption request’

Feature: creating/approving/rejecting a gem ownership request

When an adoption request is made Then the gem owners are notified of it And they may respond either via email, rubygems.org, or a gem command

When an adoption request is approved Then the requestor is added as an owner And the requestor is notified And the gem’s adoption record status is set to ‘no longer up for adoption’ (other requests may still be outstanding)

When an adoption request is denied Then the requestor is notified, preferably with a nice message

Given a gem is ‘up for adoption’ Then it can be found via search of some sort And/or listed on an ‘up for adoption’ page Whether or not the searching/viewing user is logged in or not This may be a separate app that pulls in data over the rubygems.org API

Feature A gem owner may generate a badge to place in the gem’s repository, linking to rubygems.org

We’d probably also want to add copy about this process to RubyGems guide somewhere and under the RubyGems GitHub org.

Some implementation details:

• I think we’d probably want to create two tables for this. One, is an adoption record for a gem, and the other is for associated adoption/ownership requests.

ref

• http://www.benjaminfleischer.com/2014/08/17/rubygems-adoption-center/
• https://groups.google.com/d/msg/rubygems-org/niS5ZO9DNgk/SHUzS-8Qx68J

cc @marksim @mockdeep @qrush

Promote this discussion

• retweet or respond to https://twitter.com/hazula/status/526508435438071810

Related issues

• https://github.com/rubygems/rubygems.org/issues/429
• https://github.com/rubygems/rubygems.org/issues/637
• https://github.com/rubygems/rubygems.org/pull/724

Relevant discussion from below

• https://github.com/rubygems/rubygems.org/issues/725#issuecomment-60470182

  This is great. I’m having trouble keeping all the nouns straight. There are 3 existing models of interest: rubygem, ownership, and user.

  There are 2 new concepts:

  • adoption_record where a user with ownership wants to give another user ownership. (aka the rubygem is up_for_adoption, looking_for_maintainers, “needs help” )
  • adoption_request where a user without ownership requests ownership. (inferred, user is stating that the current users with ownership are mia)

• https://github.com/rubygems/rubygems.org/issues/725#issuecomment-60602380

  So, here is, I think, the output of this discussion. I’ve changed much of the ‘adoption’ language.

  Two top-level feature PR’s:

  1. Web UI for gem ownership requests. Requires adding an ‘ownership_request’ table and links on the view to request/approve/reject. sub PR’s would include
     • notification on request creation/approval/rejection
     • ability to make or respond to requests either via email, rubygems.org, or a gem command
  2. Web UI to surface an ‘owner_wanted’ flag on a gem. Unclear if this should be a new table. sub PR’s would include
     • searchable; surface ‘owner wanted’ flag in search
     • ‘owner_wanted’ / ‘up for adoption’ page
     • ability to set status via gem metadata?
     • perhaps differentiate between looking for help vs. looking for new owner
     • create a hosted badge

  Followup would be

  • to add info about this in the guides
  • make sure these new data are available via the rubygems api, esp the rubygems/gems gem

• https://github.com/rubygems/rubygems.org/issues/725#issuecomment-60640825

  • Are there any guides/blogposts talking about how to take on ownership of a new gem?
  • Anyone approach GitHub?

• https://github.com/rubygems/rubygems.org/issues/725#issuecomment-60657387

  Answer re: guides to take ownership: adding or remove gem owners is part of the gem spec and only available (right now) by running gem owner <gem name> -a <rubygems.org account email>

  There aren’t different kinds of owners. Maybe there should be, but there aren’t. The difference between ‘looking for help’ and ‘looking for new maintainer’ is about the relationship between the people. In all cases s/the owner/an owner/. And, I’m using the word ‘owner’, because that’s what it’s called in rubygems.

  re: ‘taking ownership of a new gem?’ There’s a bunch of stuff out there, I’ve referenced some in some slides 1, 2, but you’re right that that’s not the friendliest format. That said, it would probably be nice to put together a bunch of links 3, 4 at http://guides.rubygems.org/resources/ Let’s discuss that on the list, though.

  Anything repository-related is way out of scope (and has been much discussed on the list). If a gem has no owners due to the way it was imported, that’s also out of scope. It’s a good point, and a problem, but not the problem we’re dealing with here.

• https://github.com/rubygems/rubygems.org/issues/725#issuecomment-61036972

  I like the first step of allowing any owner to mark a gem as adoptable. Which allows a new owner to request ownership. I think it works well for the set of gems that have an owner who just isn’t actively working on the project. Yes there are gems with no valid email or account attached which this won’t solve, but I think as a first step this goes through a good first case happy path.

  I In the future I could see building off it to support gems that have no maintainers. Such as a trusted group of Rubygems.org users that can mark abandoned gems for adoption if some number of them nominate a gem to be adoptable even without a currently known owner. After that the mechanism could look very much the same to a user requesting access.