RubyGems Adoption Center

[Benjamin Fleischer]

This is a follow-up to https://twitter.com/qrush/status/463761602475335680

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

I was just thinking about this and prepared a lightning talk on it at RailsConf (ran out of time though, so never given https://speakerdeck.com/bf4/the-open-source-junkyard )

I put a lot of my thought in the deck, which I'll overview here:

- 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

I'd love to help make a 'RubyGems Adoption Center' (qrush's term, which I like).

There's so many ways to do it… 

- through an endpoint on rubygems? 

- A wiki? 

- Issue tracker? 

- Mailing list?

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 (hi Tony)?)

You thoughts?

-Benjamin

[Nick Quaranto]

Hey Benjamin!

This sounds pretty great. I want these decisions to not be on my (or anyone's) shoulders. It's stressful and nerve-wracking if I get it wrong. Also our bus number is and has been historically low with answering support tickets (very few were answered from November to April).

I think there doesn't need to be an API or anything to start. Just a separate site, perhaps that could live at adoptme.rubygems.org (or something similiar), and then we could have a way to put a gem up for adoption in the UI. That site could then handle the transaction, and allow for a little pitch from the author.

As for the GitHub end of it, I don't think we should worry about that at all. This should just be for rubygems.

Nick

--
You received this message because you are subscribed to the Google Groups "rubygems.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Rochkind]

Technically transfering maintainership doesn't absolutely _require_
giving commit/owner access on github -- the canonical repo could move to
a completely different location, which the new maintainer controls.

But it does absolutely require transfering rubygems.org ownership, with
no way around that.

(After all, if you did move the repo to a new URL, the first thing a
responsible maintainer might do is update the repo URL in the gemspec
and re-release! Plus, of course, subsequent gem releases in general).

I too have experienced the pain of transfering gem ownership. Even in
cases where I _did_ make contact with the original maintainer, and they
_did_ agree to transfer it to me... there were at least two cases where
they were unable to figure out how to get access to their rubygems
accounts to transfer ownership, and we had to ask for help from rubygems
maintainers, and it ended up taking 4-6+ months to make that happen.

In one case, the original maintainer no longer even really used ruby,
and didn't feel like getting a ruby stack installed just to run `gem
owner`.... and didn't remember the email address they had registered, etc.

At least at that time, there was no way to change ownership from the
rubygems.org web ui, you had to do it via the command line. I think
that's still true?

So one improvement might be allowing ownership transfer from the
rubygems.org web UI, to make it at least easier for a contactable and
willing previous owner to transfer gem ownership. But I'm not positive
how much of the problem case this would hit, how often it is there is a
contactable and willing-to-transfer previous owner who just can't figure
out how to make it work. Might not be a significant use case. I do know
it's happened to me 2-3 times though.

> --
> You received this message because you are subscribed to the Google
> Groups "rubygems.org" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to rubygems-org...@googlegroups.com

> <mailto:rubygems-org...@googlegroups.com>.

[Benjamin Fleischer]

So, let's assume we add a web UI component that facilitates changing gem ownership,

what would the UX on adoptme be?

A logged in rubygems.org account can

- set a 'looking for maintainers' flag on a gem they own

  - optionally with an abandonment date

- 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

A mechanism within the rubygem.org registered account or rubygem spec metadata to faciliate 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"

Anyone on the sites can search the 'gem maintainer need classified'

A badge available for all rubygems that give their maintainance status and perhaps latest version number.

And this would be under some part of the RubyGems guide somewhere and under the rubygems GitHub org.  Perhaps even hosted on GitHub pages.

-Benjamin

[Samuel Williams]

I think the ideas you've proposed seem really good. However, does this only works if the original author opts in?

[Benjamin Fleischer]

Sigh, another abandoned gem https://github.com/rmagick/rmagick/issues/18#issuecomment-50107189

[Robert Fletcher]

Hey all, Benjamin brought me here via further discussion on the RMagick issue: https://github.com/rmagick/rmagick/issues/18#issuecomment-50822328

Saving you all a click, here's a quote from me:

It's sad to see so many projects falling away from being maintained. Some I've tried to contribute to only to get radio silence, others people ask if they can maintain and also don't get any response. Seems like there should be some sort of statute of limitations on rubygems for how long a gem can go without an update before it is released to be handled by another willing maintainer. Almost like renewing a domain...

I could see having some infrastructure to warn gem maintainers when they haven't pushed a new version in a few months that the gem will open up to other maintainers. There might be some internal process to ensure that new maintainers are taking it over in good faith.

[Sam Kottler]

On Thu, Jul 31, 2014 at 8:10 PM, Robert Fletcher <lobati...@gmail.com> wrote:

Hey all, Benjamin brought me here via further discussion on the RMagick issue: https://github.com/rmagick/rmagick/issues/18#issuecomment-50822328

Saving you all a click, here's a quote from me:

It's sad to see so many projects falling away from being maintained. Some I've tried to contribute to only to get radio silence, others people ask if they can maintain and also don't get any response. Seems like there should be some sort of statute of limitations on rubygems for how long a gem can go without an update before it is released to be handled by another willing maintainer. Almost like renewing a domain...

I could see having some infrastructure to warn gem maintainers when they haven't pushed a new version in a few months that the gem will open up to other maintainers. There might be some internal process to ensure that new maintainers are taking it over in good faith.

So there are a few problems I see with implementing a system to take over a gem on RubyGems.org:

1. Some gems just don't get updated very often and that's okay because they're stable and work well across lots of different versions.
2. What do we do when someone wants to fork a gem and the maintainer comes back to it later?
3. What if two (or more) separate groups want to maintain the same previously unmaintained gem and don't want to work together?

My general opinion on this is that we need to have the original maintainer(s) be involved in the handover process.

-s

 

On Friday, July 25, 2014 7:42:31 AM UTC-7, Benjamin Fleischer wrote:

Sigh, another abandoned gem https://github.com/rmagick/rmagick/issues/18#issuecomment-50107189

--

You received this message because you are subscribed to the Google Groups "rubygems.org" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org...@googlegroups.com.

[Robert Fletcher]

On Aug 1, 2014 9:17 AM, "Sam Kottler" <s...@kottlerdevelopment.com> wrote:
>
>
>
>
> On Thu, Jul 31, 2014 at 8:10 PM, Robert Fletcher <lobati...@gmail.com> wrote:
>>
>> Hey all, Benjamin brought me here via further discussion on the RMagick issue: https://github.com/rmagick/rmagick/issues/18#issuecomment-50822328
>>
>> Saving you all a click, here's a quote from me:
>>>
>>> It's sad to see so many projects falling away from being maintained. Some I've tried to contribute to only to get radio silence, others people ask if they can maintain and also don't get any response. Seems like there should be some sort of statute of limitations on rubygems for how long a gem can go without an update before it is released to be handled by another willing maintainer. Almost like renewing a domain...
>>
>> I could see having some infrastructure to warn gem maintainers when they haven't pushed a new version in a few months that the gem will open up to other maintainers. There might be some internal process to ensure that new maintainers are taking it over in good faith.
>
>
> So there are a few problems I see with implementing a system to take over a gem on RubyGems.org:
> Some gems just don't get updated very often and that's okay because they're stable and work well across lots of different versions.

I think this is where an internal review would make sense. If the gem is clearly stable, then there is no need to approve a handoff. But I think it's unlikely for even a very stable gem to go a year, or even six months without at least a point release.

> What do we do when someone wants to fork a gem and the maintainer comes back to it later?

The original maintainer is no longer the maintainer at that point. If they want to get back involved with the project then they'll need to get in touch with the current maintainers.

> What if two (or more) separate groups want to maintain the same previously unmaintained gem and don't want to work together?

Then one option might be for the internal reviewer to decide as best they can who to hand it off to, and the other group is free to fork it if they like and create a new gem from it. This seems like a scenario that would be suitably rare, though, as to not worry about until it actually happens.

> My general opinion on this is that we need to have the original maintainer(s) be involved in the handover process.

I agree, but the situation we seem to be struggling with is where the original maintainer has fallen off the map or has become unresponsive. See cancan and the above mentioned RMagick. We end up with a lot of good gems becoming defunct in spite of there being plenty of interest in helping out.

[Robert Fletcher]

Just had another thought about this situation. What if there was a Github organization that adopts repos? Basically, we have a pool of maintainers, and when a maintainer of a project needs support, they can relocate the repo to that organization in order to gain access to some additional maintainers. There would need to be some core set of values and probably some review process so it doesn't end up being a junk drawer of people's crappy little one-off projects, but it seems like it might be an effective solution to the maintainer problem.

[Kerri Miller]

Its an interesting idea, but how would this work in the all too common case of gem authors who simply drop off the face of the earth?

-k-

[Robert Fletcher]

Good question. I think in those situations the adoptions group could have a discussion about it, taking into account the license on the project, and fork it if it sounds appropriate. That being said, I think having a known place where you can get support for your project would actually reduce the number of projects that end up in that state. While there are projects where the maintainer just disappears, there are quite a few where they ask for new maintainers, and when nobody comes around in a decent amount of time, then the maintainer becomes unresponsive.

[Benjamin Fleischer]

I used github issues import when forking rmagick to gemhome... Working do far

[Benjamin Fleischer]

To be clear, an abandoned repo is only a problem insofar as porting
over issues and prs is a pain.

I have push to rubygems.org for rmagick even though I haven't (yet?)
gotten access to rmagick/rmagick. Rubygems.org doesn't care that dev
has moved to gemhome/rmagick

So, perhaps there could be rubygems.org terms of service that another
user can be given push when certain fair-to-all conditions apply.

I'd love for gem owner to flag a gem as open for adoption

[Adam Wilson]

My 0.02 is to use the domain name subscription model.

Domain names have basically the same problem (and a solution) and everyone already knows how it works.

At the end of the day life is going to happen and for whatever reason gem owners will disappear or be too busy to maintain a gem and it would be great to have a system that handles this.

I feel that the needs of the community trump the individual needs.

If users are actively (say once every 6 months) saying that yes they want to keep the gem, then fine. Otherwise it gets released into the adoption pool, first come first served.

Example:

- User creates Gem, agrees to terms that say it will expire.

- Gem is updated etc for a while (months or years)

- Updates stop. 6 months after the last update the user is sent a friendly email asking them to click the link if they are still interested in maintaining ownership of the gem.

- If the users clicks the link, then the clock is reset for 6 months, no need to do anything. Repeat while still interested in owning the gem.

- If there is no response after 1 month (to allow time for holidays etc), then the gem is 'released' into the adoption pool.

Thanks,

Adam.

[Tim Moore]

I like the idea of an expiration period overall, but I'm worried that a first-come-first-served adoption pool with no vetting would create a security risk. Malicious developers could hijack gem names when they expire, and unwitting users might 'bundle update' to a bad version of a previously-trusted gem.

[Amos King]

This doesn't seem like a problem you are going to solve with technology. Now the good thing is that if we have a malicious developer all the ruby code is open source. The community will probably notice. Then the proper actions can be taken to take care of that.

Amos King

"The bitterness of poor quality remains

long after the sweetness of low price is forgotten" - Benjamin Franklin

http://dirtyInformation.com
http://github.com/Adkron

http://thisagilelife.com # podcast

=======================================================
I welcome VSRE emails. Learn more at http://vsre.info/
=======================================================

--

[George Dinwiddie]

It would still be prudent to think about the response in the event of
the inevitable gem name squatter. Grabbing expired domain names for
ransom is a big business.

- George

On 8/6/14, 10:27 AM, Amos King wrote:
> This doesn't seem like a problem you are going to solve with technology.
> Now the good thing is that if we have a malicious developer all the ruby
> code is open source. The community will probably notice. Then the proper
> actions can be taken to take care of that.
>
> Amos King
> "The bitterness of poor quality remains
> long after the sweetness of low price is forgotten" - Benjamin Franklin
> http://dirtyInformation.com
> http://github.com/Adkron
> http://thisagilelife.com # podcast
>
> =======================================================

> I welcome VSRE emails. Learn more athttp://vsre.info/

> https://twitter.com/qrush/__status/463761602475335680

> <https://twitter.com/qrush/status/463761602475335680>
>
> We really need to get better at making gem
> maintenance/abandonment easier.
>
> I was just thinking about this and prepared a lightning talk
> on it at RailsConf (ran out of time though, so never given

> https://speakerdeck.com/bf4/__the-open-source-junkyard

> <https://speakerdeck.com/bf4/the-open-source-junkyard> )
>
> I put a lot of my thought in the deck, which I'll overview here:
>
> - Maintainership nowadays requires giving commit/owner

> access on BOTH GitHub and rubygems.org <http://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
>
> I'd love to help make a 'RubyGems Adoption Center' (qrush's
> term, which I like).
>
> There's so many ways to do it…
> - through an endpoint on rubygems?
> - A wiki?
> - Issue tracker?
> - Mailing list?
>
> 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 (hi Tony)?)
>
> You thoughts?
> -Benjamin
>
> --
> You received this message because you are subscribed to the Google

> Groups "rubygems.org <http://rubygems.org>" group.

> To unsubscribe from this group and stop receiving emails from it,
> send an email to rubygems-org...@googlegroups.com

> <mailto:rubygems-org...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "rubygems.org" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to rubygems-org...@googlegroups.com

> <mailto:rubygems-org...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Nick Quaranto]

We already have dealt with gem name squatters in the past. For blatant abuses of the system we remove all of the gems and their account.

    send an email to rubygems-org+unsubscribe@googlegroups.com

    <mailto:rubygems-org+unsub...@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google
Groups "rubygems.org" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to rubygems-org+unsubscribe@googlegroups.com

<mailto:rubygems-org+unsub...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
 ----------------------------------------------------------------------
  * George Dinwiddie *                      http://blog.gdinwiddie.com
  Software Development                    http://www.idiacomputing.com
  Consultant and Coach                    http://www.agilemaryland.org
 ----------------------------------------------------------------------

--
You received this message because you are subscribed to the Google Groups "rubygems.org" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org+unsubscribe@googlegroups.com.

[Robert Fletcher]

Is it better to deal with them after the fact or pre-emptively? I was kind of thinking it would make sense to have some human intervention before gems change hands, but I guess it could also go the other way.

To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org...@googlegroups.com.

[Sam Kottler]

On Wed, Aug 6, 2014 at 2:03 PM, Robert Fletcher <lobati...@gmail.com> wrote:

Is it better to deal with them after the fact or pre-emptively? I was kind of thinking it would make sense to have some human intervention before gems change hands, but I guess it could also go the other way.

IMHO a human has to be involved to understand the situation and help resolve any human issues (i.e. a disagreement over who should become the maintainer).

[James Cox]

Yeah, as pointed out, the issue isn't squatters so much but it's bad actors who find a dormant gem to update with a malicious payload.

Resque is a good example: before that gem switched hands, it sat dormant for a year or more without releases. Theoretically then, someone could 'claim' that gem name, adopt it, and release a new version which sucks up all kinds of data. 

Most users wouldn't notice, as bundle update/install isn't especially usefully informative (especially not in deployment scenarios), and then worse still, if they haven't pinned the gem (why would they, it doesn't update often), then it'll be at risk.

That's not to say you couldn't put some business rules around it: number of downloads, activity around the gem, searches... whatever. It may also be a good idea to have a gem be named something else - e.g: "resque-forkedversion" and have that gain proof before it becomes the desired name.

On Wed, Aug 6, 2014 at 2:03 PM, Robert Fletcher <lobati...@gmail.com> wrote:

--
James Cox,
Consultant, Raconteur, Photographer, Entrepreneur
t: +1 347 433 0567  e: ja...@imaj.es w: http://imaj.es/
talk: http://twitter.com/imajes photos: http://500px.com/imajes

[Amos King]

Are we really running out of words and names?

Amos King

"The bitterness of poor quality remains

long after the sweetness of low price is forgotten" - Benjamin Franklin

http://dirtyInformation.com
http://github.com/Adkron

http://thisagilelife.com # podcast

=======================================================
I welcome VSRE emails. Learn more at http://vsre.info/
=======================================================

[Tyler Knappe]

It is a fairly frequently discussed topic.

https://groups.google.com/forum/#!searchin/rubygems-org/good$20names

[Robert Fletcher]

It doesn't make sense to me to rename a gem that is essentially the same gem, just under new maintainers. While we can always come up with witty new names for gems, it makes it increasingly difficult to determine whether it's a true fork or just a convenience until the real gem is updated.

[Kerri Miller]

How about something like... every 6 months, you get a "click it or lose it" email.. but we'd send 2 or 3 over 2 weeks, just to Make Sure. Then the gem (as listed in RubyGems) gets listed as "available for adopting"  which are open for people who are interested in adopting it put their name in. When the first person signs up, there's a 2 week window where other people can say "no, *I* want it!" Owners would have a chance during this window to say "oh no wait I do want it" and yank it back.

Have a rotating group of 3 people from RubyGems review the situation at the end of that 2 week window and approve or reject the transfer to the new owner's repo (after make a last ditch effort to contact the original owner, of course) Also, have a process for the original owner to appeal the transfer within, say, 60 or 90 days of the final transfer. There could additionally be a follow-up spot-check to make sure the new maintainer is tending to the gem (merging outstanding PRs, issues, etc)

Its kind of a lengthy process, but it should help avoid "oh I was on vacation" or "oh I never got that email" etc, /and/ reduce the potential for squatting, since there's people in the loop doing the review who could say "hmmm, well, maybe the new github account with no other repos and a bogus twitter account isn't who we should hand [gem] to.."

-k- 

--

[Nick Quaranto]

Given our history with help/issues so far, I'm not comfortable with any kind of time bomb like this that requires support to intervene. Also, people change their emails fairly frequently (email-changing related issues are probably the #2 most frequent issues behind permadeletion) and I'd bet people would be surprised/angry if they missed the adoption notice emails.

I think this just needs to start simple. A gem owner can opt-in to list their gem for adoption. We don't need to make it more complex than that to start.

[Sam Kottler]

On Wed, Aug 6, 2014 at 5:40 PM, Nick Quaranto <ni...@quaran.to> wrote:

Given our history with help/issues so far, I'm not comfortable with any kind of time bomb like this that requires support to intervene. Also, people change their emails fairly frequently (email-changing related issues are probably the #2 most frequent issues behind permadeletion) and I'd bet people would be surprised/angry if they missed the adoption notice emails.

I think this just needs to start simple. A gem owner can opt-in to list their gem for adoption. We don't need to make it more complex than that to start.

Completely agreed.

[Kerri Miller]

Yeah it's a little complex :) simple is better but it's tough to meet everyone's concern without getting boroque :/

[Amos King]

+1

Amos King

Binary Noggin

[Adam21e]

Regarding the malicious takeover, what if we implemented a trusted peer review? 

- First we seed the rubygems user community with known trusted users.

- The trusted users can then 'trust' other users that they know and trust.

- New users can become trusted users by having 3 other trusted users mark them as trusted. 

- Gem is in the 'adoption pool' and a user (trusted or not) applies to take the name over.

- Trusted users can opt in to receive an email notification or just browse to the adopted section.

- They then click yes/no to approve the gem name take over

- Once they have 5 trusted users approval then they get the name.

Benefits

- Zero load on admins (once this feature is built)

- The community will decide who gets to take over a gem. 

[James Cox]

again i go with nick's suggestion, and we can make it super simple by way of the gemspec:

spec.adoptable = true

this would mean that in the event you are no longer able to contribute, by whatever means (death, work, boredom, the end of the internet), and someone else is interested in taking it over, then that's ok. At least that would reduce the barrier to entry.

--

You received this message because you are subscribed to the Google Groups "rubygems.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

[Adam21e]

Totally agree on the opt in to adoption.

Was just commenting on the next step of making sure the gems aren't adopted and abused by malicious people. :-)

Why load up the RubyGems support staff to preside over every adoption when the community can handle it?

With the gem owner opting in and community overwatch of adoptions, we can take big steps to solve an issue that won't require more from RubyGems support.

[Kerri Miller]

Love how simple this is!

[Tim Moore]

Is that what it would mean? I understood Nick's suggestion to mean that the current maintainer is explicitly seeking new maintainers. Something similar to http://stillmaintained.com/ but integrated with rubygems.org.

It still leaves open the question of the actual handover process, and what to do in the case where the current maintainer is not contactable.

On Thursday, August 7, 2014 10:03:31 AM UTC+10, James Cox wrote:

[Nick Quaranto]

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

I'm not sure if this will work but it's worth a shot. Could be the easiest way to prove if this works and would require a fairly small amount of code.

[Tim Moore]

I think there still needs to be a clear policy on how and when the Rubygems support team will and will not transfer gem ownership. With a policy in place that's easy for everyone to understand, it should both reduce the number of frivolous requests and also make it easier to eventually expand the team of people with permission to do it.

To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[James Cox]

Yes, the policy needs to be in place -- you can't just go ahead without any guidelines -- otherwise you end up with the same stresses the team has right now.

the concept of the adoptable flag in the gemspec is to indicate that you (as the owner/maintainer) care more about the fact that the code is out there and is public than your own personal equity in it. So, if someone else wants to drive it forward, that's fantastic. It's a dead-man's switch: it doesn't require you to do anything much, and when you do lose interest/get distracted, your desires are already clear. (it'd be analogous to an organ donor card :)) 

once that's in place, the next thing would be to establish terms of adoption, and how that would be approved.

best

james

[Tony Miller]

What are we going to do about the gems that are already out there? Will there be some kind of default setting for the adoptable flag?

Is there any case where we absolutely SHOULDN'T hand over a gem to a foster developer?

There are also probably some cases where the source might not be easy to find:

https://rubygems.org/gems/klookup

Just trying to move the discussion, sorry I don't have any answers.

-Tony Miller
github.com/mcfiredrill
@freedrull
freedrool.us

[Sam Kottler]

On Sat, Aug 9, 2014 at 8:45 PM, Tony Miller <mcfir...@gmail.com> wrote:

What are we going to do about the gems that are already out there? Will there be some kind of default setting for the adoptable flag?

Is there any case where we absolutely SHOULDN'T hand over a gem to a foster developer?

Yes, the case IMO is all existing gems. If we decide to go the route where people can set an adoptable flag in their gemspec then any gem without that flag should not be available for adoption.

To be completely honest, I feel like the whole adoption center idea is going to be way more complicated and dodgy in its implementation and practice than any of the hypothetical things we've talked about. We are already so overworked in keeping the site running; this is certainly going to add more drama to the lives of the people who actively work on RubyGems.org than it's worth. I hate to be so dismissive, but this is going to introduce a lot of social issues which we have no business nor the ability to be involved with.

[Benjamin Fleischer]

I'm not sure if everyone saw the original posts in this thread, so I'll repost it here since I think it can help bring focus to the requirement that this not be a lot of work for any small group of humans, especially Nick Q.

This is a follow-up to https://twitter.com/qrush/status/463761602475335680

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

I was just thinking about this and prepared a lightning talk on it at RailsConf (ran out of time though, so never givenhttps://speakerdeck.com/bf4/the-open-source-junkyard )

I put a lot of my thought in the deck, which I'll overview here:

- 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

I'd love to help make a 'RubyGems Adoption Center' (qrush's term, which I like).

There's so many ways to do it…

- through an endpoint on rubygems?

- A wiki?

- Issue tracker?

- Mailing list?

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 (hi Tony)?)

The MVP +/-, I think, is just 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

Bonus items

- 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 rubygem.org registered account or rubygem spec metadata to faciliate 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:

  - Let's pick something from the MVP that we agree on and create a PR for further discussion.  It's time, I think, to move from discussion to action. Probably reference https://github.com/rubygems/rubygems.org/issues/637 and here's an example PR that modifies the user account page https://github.com/rubygems/rubygems.org/pull/679

Other references

- Taking over and/or giving back Gems https://github.com/rubygems/rubygems.org/issues/429

- Ernie Miller put some of his gems up for adoption at a new github org http://erniemiller.org/2013/11/17/anyone-interested-in-activerecord-hackery/ https://github.com/activerecord-hackery/squeel

- https://speakerdeck.com/bf4/the-open-source-junkyard 

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 click send and move on to other things at some point)

- MetricFu: original owner put up blog post and mailing list message looking for new maintainer. I applied, talked to him, and he gave me gem ownership, repo ownership, and rubyforge access.  He request that I continue work on a forked repo. Using an  GitHub orf 'metricfu' is much easier to manage owners than an individual user account. http://jakescruggs.blogspot.com/2012/08/why-i-abandoned-metricfu.html

- Kaminari: I had a PR that was ignored, ( https://github.com/amatsuda/kaminari/pull/374 )I emailed the maintainers and bumped to repo, but didn't get the PR merged until I sat down with Akira Matsuda at RailsConf 2013, and then subsequently created another issue to prompt a new release https://github.com/amatsuda/kaminari/issues/412

- ActsAsTaggableOn: bugged a PR https://github.com/mbleigh/acts-as-taggable-on/pull/343 and then mbleigh on email and twitter till I got commit and gem push, then bugged again to add more collabs https://github.com/mbleigh/acts-as-taggable-on/issues/441  but have mostly dropped off and one of the collabs (seuros) basically maintains it now, but I pop in now and again

- SimpleCov: bugged a PR  https://github.com/colszowka/simplecov/pull/245 then offered to help out https://github.com/colszowka/simplecov/issues/297 and helped prove that the blocking issues in 0.8 were fixed, then helped add some  maintainers https://github.com/colszowka/simplecov/pull/317#issuecomment-48905518 Development has since picked up by both collabs and the colszowka

- RMagick: Joined a long-running thread about the need for a release and the absent maintainer https://github.com/rmagick/rmagick/issues/18#issuecomment-50774623 forked the repo https://github.com/gemhome/rmagick and got gem push and some help from one of the original maintainers, put out a new version,... looking like we might get access to the rmagick user soon.  Used https://github.com/IQAndreas/github-issues-import to import issues to the gemhome fork

- Mail: Helped loosen mime-types dependency which was locking any user of the gem (including anyone using actionmailer) to an older version  https://github.com/mikel/mail/pull/713 which resulted in revived activity on the repo and some PRs to rails (that will be be in a release at some point) https://github.com/rails/rails/pulls?q=is%3Apr+is%3Aclosed+author%3Abf4+mail

- Rails-ERD: is totally abandoned with no one interested in picking it up https://github.com/gemhome/rails-erd/issues/30 so I made an issue I just point people to

- Fnordmetric: was abandoned but maintainer says he is now backhttps://github.com/paulasmuth/fnordmetric/issues/177 https://github.com/paulasmuth/fnordmetric/pull/178

- Saikuro: was abandoned and got buy-in from the original author but am slightly hamstringed by a gem of the same name, but lowercased, also being pushed to rubygems, and a non-responsive author of that fork https://github.com/metricfu/Saikuro/issues/2

- Roodi:  I maintained a fork until a new maintainer was found https://github.com/roodi/roodi/pull/16

- TestConstruct: I bugged the original devs and they renamed and re-released it.  https://github.com/metricfu/construct/issues/1 https://github.com/bhb/test_construct No activity on the repo, no work neeeded

- Jenkins-MetricFu-Plugin: Got the original author to transfer the repo to the metricfu org but no subsequent work has taken place https://github.com/metricfu/jenkins-metricfu-plugin/issues/3

- Bcrypt: prompted for renewed dev https://github.com/codahale/bcrypt-ruby/issues/54 after a languishing PR https://github.com/codahale/bcrypt-ruby/pull/48  activity has since picked up

- YUI-Rails: Had a PR, original author gave me commit and push but no activity, issues, or PRs since https://github.com/nextmat/yui-rails/pull/1#issuecomment-13896385

- recommendify: asked maintainer to specify an official fork.. responded with link to new project, but left issue open https://github.com/paulasmuth/recommendify/issues/26

[Benjamin Fleischer]

I made an issue on RubyGems.org for an MVP  https://github.com/rubygems/rubygems.org/issues/725 

[Tony Miller]

RE: maintainer-ship badge, stillmaintained.com seems to be using a
'maintained?' badge in their github repository, maybe could be useful?

https://github.com/stillmaintained/stillmaintained