Benjamin Fleischer
Benjamin Fleischer

A RubyGems Adoption Center

17 August 2014

Summary

There is an ongoing discussion on the RubyGems.org mailing list about the creation of a RubyGems Adoption Center.

Update 2014-10-24

I created a GitHub issue to spec out the MVP

Background

(you can skip to the call to action if this background doesn’t interest you :)

The background for this is that I’ve, for whatever reasons, become involved in taking over maintenance of various gems or otherwise helping to revive stalled development.

In particular, I, quite accidentally, became a maintainer of ActsAsTaggableOn, a Rails tagging engine, after bumping a long-stale, minor, pull-request I had written. There were already some second-generation maintainers on the project, but they had, apparently, burned out. I started going through the issues, tests, and pull requests, got a few more collaborators added to the team, and got gem push so that I could release new updates. But, I was no longer using the gem, the issue activity was overwhelming, and the codebase in serious need of reworking. One of the devs I brought on, Abdelkader Boudih, @seuros continued working on the codebase while I, guiltily, drifted on to other things.

At RailsConf 2014, I posted on the boards about creating a ‘gem maintainers / developers support group’, and prepared a lightning talk, “The Open Source Junkyard”, which unfortunately too far down the list to make it into the alloted time slot. I’m really passionate about the issue, and continued talking to people and looking around. In particular, I talked to Nick Quaranto, so when I saw him tweet in a thread about maintenance of the RSpec-Given library, after Jim Weirich’s passing, I responded “We really need to get better at making gem maintenance/abandonment easier.” and he wrote back “agreed. maybe we need a RubyGems adoption center.” and suggested I post to the RubyGems.org mailing list.

There was a bit of discussion, which petered out, then began again for a bit after I posted a link to it in a discussion about reviving RMagick.

Call to Action: A RubyGems Adoption Center

We really need to get better at making gem maintenance/abandonment easier

Maintainership nowadays requires giving commit/owner access on BOTH GitHub and rubygems.org

  • If the original maintainer is non-responsive, one may submit a request to http://help.rubygems.org/ but that’s a lot of work for humans (@qrush) and requires a lot of judgement calls
  • Maintainers might ask for help on public lists, private lists, twitter, in the repo, etc, but there’s no ‘clearinghouse’.
  • http://stillmaintained.com/ is unreliable and not well-integrated. Maintainership-through-badges isn’t the right approach

Some possible implementations

  • Through an endpoint on rubygems?
  • A wiki?
  • Issue tracker?
  • Mailing list?
  • We could make a new Category for “Adoption” in Tender (help.rubygems.org). If a gem is marked for adoption, we could just have a link on the page that pops up their embeddable widget: https://help.tenderapp.com/kb/setup-installation/adding-and-customizing-the-tender-widget
  • RubyGem name ownership expires like the domain name subscription model
  • RubyGems owners periodically confirm ownership, else the gem is listed as “available for adoption” Humans review adoption requests to reject/accept any, maybe with an appeal process.
  • Variation on the above where a trust-community is built and is self-policing.

And how integrated with RubyGems and/or RubyGems.org should the original source repo be, if at all? (Like a maintainership API via PGP, TUF))

MY proposed MVP– enabling communication dev-to-dev

A logged in rubygems.org user can

  • set a ‘looking for maintainers’ flag on a gem they own
    • optionally with an abandonment date
      • ( note, this would likely be in the gem’s metadata spec since that doesn’t require any changes in the spec )
      • ( but it could be just part of rubygems.org as well and independent of the gemspec )
  • request to be added as an owner of a registered gem
  • apply to a ‘looking for maintainers’ request
    • maintainer can accept or reject the request

Nice to haves:

  • having a gem maintainership badge that can communicate a need for adoption.
  • making gems up for adoption searchable by logged in and anonymous users
  • Adding copy to RubyGems guide somewhere and under the RubyGems GitHub org. Perhaps even hosted on GitHub pages.

Note what this does NOT do:

  • anything having to do with github or other repositories
  • involve anyone except the gem owner, the application, and the rubygems.org code/data-base
  • deal with gems whose owners are AWOL
    • e.g. a mechanism within the rubygems.org registered account or rubygem spec metadata to facilitate this in the absence of maintainer response. Like “I grant ownership to rubygems.org of any RubyGems registered to my name if I do not reply to requests for maintainership (TBD what this means) within some reasonable window”

Action Items:

Other references

Experiences as unscientific case-studies

I’ve helped revive or take over a number of gems. Here’s the results, thus far (tl;dr some authors help pass on ownership, some don’t, and sometimes the request results in renewed activity and adding more collaborators/maintainers)

(I apologize that this isn’t better written, but I had to stop writing and move on to other things at some point)

blog comments powered by Disqus