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

RFC: Add a Gem adoption status and ownership request approve/reject workflow #725

Open
bf4 opened this Issue Oct 24, 2014 · 37 comments

Comments

Projects
None yet
@bf4
Copy link
Contributor

bf4 commented Oct 24, 2014

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

cc @marksim @mockdeep @qrush

Promote this discussion

Related issues

Relevant discussion from below

  • #725 (comment)

    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)
  • #725 (comment)

    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
  • #725 (comment)

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

    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.

  • #725 (comment)

    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.

@marksim

This comment has been minimized.

Copy link

marksim commented Oct 24, 2014

👍 Great spec.

@antoinelyset

This comment has been minimized.

Copy link

antoinelyset commented Oct 24, 2014

Really nice idea. 👍

@mockdeep

This comment has been minimized.

Copy link
Contributor

mockdeep commented Oct 24, 2014

I think one difference might be to talk about "maintainers" vs. "adopters". Someone might be still actively maintaining a project and just looking for additional maintainers.

@kbrock

This comment has been minimized.

Copy link
Contributor

kbrock commented Oct 25, 2014

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)

@mockdeep As the request is written, there is the implication that the original user / owner is not offering help after ownership is given away. I wonder if we want to make that statement.
The future intent of the user with ownership may not be known, so a simple "I want help/to add maintainers" may suffice.


The adoption_record is a join table between the user and rubygem. There already exists an ownership between this same user and rubygem. It may make sense to put this as a flag on the existing ownership that states it help_requested or something. Makes a lot of sense if you are stating that you want to give this particular ownership away.

If the up_for_adoption flag is in the metadata of the gemspec, then it seems like it makes sense to associate the flag with the rubygem and not a join with the user. Chances are if a developer does not have time to maintain the gem, they may not have time to modify the metadata and push a new rubygem version anyway. (up for debate)


The adoption request looks like it is stating "do you need help" or "this gem is stale / owners are mia"

If it is the first, is twitter/email a better medium?
If it is the latter, the date on the request makes so much sense. Then the community can start to setup expectations for support of gems.

And we need to have this discussion. As many people have far too high expectation of open source developers and this is resulting in major burnout.

Oops, didn't mean to ramble.
Thanks for the great request

@mpapis

This comment has been minimized.

Copy link

mpapis commented Oct 25, 2014

with this assumption:

Given: An authorized and authenticated gem owner

there is no problem with finding someone to pass on the keys to the account, maybe this could be implemented outside of rubygems, like it's done with https://www.ruby-toolbox.com/ where gem authors could post adoption request for the gems ... and then rubygems.org could maintain only list of the sites that do the good work

@qrush

This comment has been minimized.

Copy link
Member

qrush commented Oct 26, 2014

@mpapis that's kind of dismissing the entire point of this PR and the entire Adoption Center idea. Please read on the history of this thread here: https://groups.google.com/d/msg/rubygems-org/niS5ZO9DNgk/SHUzS-8Qx68J

@mpapis

This comment has been minimized.

Copy link

mpapis commented Oct 26, 2014

@qrush I did follow the discussion for some time now, my point is this does not have to be integrated with rubygems, there are already rubygems related services like categorization (https://www.ruby-toolbox.com/) or documentation (http://ruby-doc.org/, http://www.rubydoc.info/) and more (https://gemnasium.com/, ...) - so the adoption center could be separate service too, more important would be to get a list of all this external services (with badge instructions would be great) and add the adoption center to the list, keep http://rubygems.org for hosting gems, let others build services around it --

this service does not require specific information from rubygems, it assumes the gem owner is seeking help, this means a simple gem owner <gem> -a <email> would suffice.

@kbrock

This comment has been minimized.

Copy link
Contributor

kbrock commented Oct 26, 2014

@mpapis Maybe this PR can be simplified to 2 primary goals:

  1. Provide a way for gem owners to ask for help.
  2. Provide a way to ask gem owners if they need help.

Solutions to goal 2 already exist (e.g.: email and twitter)
But the question comes up again and again about what to do when an owner is not responsive; either to bug reports or to offers of help. Marking a project owner as "mia" is potentially a passive aggressive attack, when a simple ping via email or twitter may work great. The problem is when the owner is just plain not available.

Goal 1 can be provided by other services. But when maintenance of the gems is so crucial to the rubygems ecosystem, and burnout is so prevalent, maybe it is necessary to expand scope of rubygems in this case.

In general, it is hard to prune out a directory of gems with old stale gems. Providing a mechanism for users to pick up existing gems rather than re-invent due to maintenance seems like a good start.

@mpapis

This comment has been minimized.

Copy link

mpapis commented Oct 26, 2014

well from what I remember from the mailing list discussion there is no option to add new owners without permission from former owner, add to this beginning of this ticket:

Given: An authorized and authenticated gem owner

so is this ticket about adding option for gem maintainers to ask for help (which I would assume could be an external service) or is this to allow asking to take over gems without owners permission - which can not be externalized and also was rejected as an option in the mailing list ... at least it was my understanding

@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented Oct 26, 2014

I like the discussion here and agree with most of it. The exception, is that my experience has been that getting gem push can be quite time consuming. I've adopted, revived, etc. a number of gems. 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.

The behavior in this issue belongs in rubygems.org: requests to be added as owner and the owner's ability to approve or reject such a request. Letting an owner also request 'new owner / more owners' is a natural and very helpful extension of this.

Are we all on the same page the problem we're trying to solve? Lowering friction for gem development to continue with the same gem name.

ref workflow over twitter:

@mpapis

This comment has been minimized.

Copy link

mpapis commented Oct 26, 2014

I agree it would be easier for gem owners to push up the rights, would it be easier to migrate gem rights? => not always, there are still the repo permissions, not related to rubygems at all, but still, necessary to preserve the brand, as much as it can be helpful I still do not feel the worth of it

@bf4 bf4 changed the title RFC: Add a Gem adoption status and request to adopt approve/reject workflow RFC: Add a Gem adoption status and ownership request approve/reject workflow Oct 26, 2014

@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented Oct 26, 2014

@mpapis for better or worse, access to the repo is less important than gem push. I have gem push for rmagick but can't get access to github.com/rmagick/rmagick, so we develop at github.com/gemhome/rmagick. Result: rmagick development continues and gem is released under the same name.

In any case, that's outside the scope of this issue.

@mpapis

This comment has been minimized.

Copy link

mpapis commented Oct 26, 2014

@bf4 ^5 for rmagic, it wasted lots of my time back in the day, I guess this brings it closer to you how much optional this request is for rubygems to work

@copiousfreetime

This comment has been minimized.

Copy link
Contributor

copiousfreetime commented Oct 27, 2014

I'm just dropping this link in here so that everyone can see how the Fedora project does the same thing. Theirs all revolves around the Package Database, it lists who the owners of packages are and their relationship with the package. Its worth looking at for understanding an existing workflow and for seeing additional terminoloy.

http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

@mockdeep

This comment has been minimized.

Copy link
Contributor

mockdeep commented Oct 27, 2014

@copiousfreetime this is actually a really interesting idea. Rather than posting that you're looking for adopters, you can mark a project as "orphaned" and another willing maintainer can come and pick it up.

@TimMoore

This comment has been minimized.

Copy link
Contributor

TimMoore commented Oct 27, 2014

The Fedora system also revolves around having a large, centrally-maintained list of verified "maintainers" who have to earn that status and abide by guidelines https://fedoraproject.org/wiki/Join_the_package_collection_maintainers. Allowing maintainers to pick up an orphaned project at the press of a button (without approval by prior maintainers) requires that there is already some level of trust in the new maintainer.

Rubygems is a different sort of system. You don't have to be approved by anyone to add a new gem to it or to be a "gem owner" in general. I don't think anyone really wants to turn Rubygems into something with tighter control by a central authority.


Apologies if this is derailing the discussion in the same way as the original mailing list thread... I don't think we should be debating any kind of system of automatic hand-over without the existing maintainers' approval here. That isn't what @bf4 proposed, and it's a whole different can of worms.

@copiousfreetime

This comment has been minimized.

Copy link
Contributor

copiousfreetime commented Oct 27, 2014

@TimMoore I wasn't thinking of the centrally controlled maintainer aspect of fedora at all. I also do not want rubygems to be restrictive gateway for publishing gems.

I was looking at Fedora in terms that Fedora is an existing system that has functionality (centralized repository of packages) and roles (owners/maintainers) similar to rubygems and seeing what knowledge/terminology/lessons can be gleaned from an existing system that are applicable to rubygems and use it to make a better solution.


I also do not think we should be discussing any kind of system of automatic hand-over that excludes an existing maintainer.


Apologies for derailing the conversation. I think the spec that @bf4 has put together adequately sums up the situation and provides a good solution.

@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented Oct 27, 2014

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
@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented Oct 27, 2014

You can also promote this discussion by retweeting or responding to https://twitter.com/hazula/status/526508435438071810

@qrush

This comment has been minimized.

Copy link
Member

qrush commented Oct 27, 2014

Something to consider: I always had RubyGems.org pinned as having one primary concern: hosting gems. Adoption is clearly a first class concern of this application, but we don't necessarily need to add it into this app if we don't want to.

If someone wants to take a more service-level approach to this and use the API from another application, the cookies are shared across domains:

https://github.com/rubygems/rubygems.org/blob/master/config/environments/production.rb#L11-L14

So we could have something like http://adoption.rubygems.org and have that be focused just on that job. Or, it could be inside the existing Rails app. Just something to think about. :bowtie:

@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented Oct 27, 2014

@qrush wrote:

If someone wants to take a more service-level approach to this and use the API from another application, the cookies are shared across domains
So we could have something like http://adoption.rubygems.org and have that be focused just on that job. Or, it could be inside the existing Rails app.

I was actually thinking about writing the code as an engine/railtie that is, where relevant, mounted in the app, so that it can be easily moved when we have a better idea of where it might go. I think a bunch of us are still on the fence about 'adoption' being the best term when the behavior overlaps with adding owners in general. (And 'owner' vs. 'maintainer'...)

I do like the idea of 'retiring' as well, but opening up a gem name to anyone just seems like a security issue I don't want to address. And until we have some kind of gem owner karma system... well...

@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented Oct 27, 2014

If we have consensus on the output of this issue ( #725 (comment) ) I'll append the description with a task list and probably start a PR, unless someone else wants to pick it up.

@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented Oct 27, 2014

Oh, and re: the efficiency of email as communication with the sole rubygems.org owner of a gem... mikel/mail#817 (comment) is holding back the 2.6.2 release of the mail gem :)

@kbrock

This comment has been minimized.

Copy link
Contributor

kbrock commented Oct 27, 2014

  • @bf4 I like the new language better - thanks
  • @copiousfreetime thanks for fedora link. Nice to see how others solve these problems

QUESTIONS:

  1. Who can set the flag "owner_wanted"? One of the original owners only?
  2. Can we improve the workflow to work for developers who don't know their email and/or password. Many of these records came from rubyforge. I'd imagine a high percentage of the well known gems.
  3. Are there any guides/blogposts talking about how to take on ownership of a new gem? I liked the interview with the new Jekyll owner. And how it was a learning process of what is acceptable with that gem vs others.
  4. Anyone approach GitHub with the concerns of fragmentation and stagnant repos? Of establishing a canonical source without a strong hand?
    Maybe making it easier to link/unlink repos together? Very common for repos that migrated from rubyforge or another git provider, or when your forked parent becomes stagnant.
@kbrock

This comment has been minimized.

Copy link
Contributor

kbrock commented Oct 27, 2014

@bf4 sorry if this is a nitpick and/or a step backwards

We seem to speak as if a project only has only one owner. But in fact it can have many. So adding an owner (for help with maintenance) or adding an owner as the primary driver seem unimportant. It is simple: The developers need help.

Is there a primary owner vs secondary owner that I don't know about?

@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented Oct 27, 2014

@kbrock 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.

Also, for concerns outside the scope of this issue, I'd like to keep them on the mailing list until we make a new issue for them. 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.

@danmayer

This comment has been minimized.

Copy link
Contributor

danmayer commented Oct 30, 2014

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.

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.

@qrush qrush added the feature label Nov 28, 2014

@qrush

This comment has been minimized.

Copy link
Member

qrush commented Mar 31, 2015

It's been months without any real action on this. I'm going to submit this idea to https://github.com/rails-girls-summer-of-code/projects and see if we can get anyone interested in actually working on it.

FWIW I am still bullish on a completely separate mini Rails app/site that runs this outside of the main Rails app. It doesn't necessarily have to be built into the existing app. It could be, but doesn't have to be.

@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented Mar 31, 2015

@qrush

This comment has been minimized.

Copy link
Member

qrush commented May 13, 2015

There is a RailsGirls Summer of Code project working on this and they're
waiting to be accepted.

There's plenty of other projects...doing something with our horde of
stat/download data would be super helpful!

On Wed, May 13, 2015 at 4:53 AM, Ilya Vassilevsky notifications@github.com
wrote:

Looks like GSOC isn't going to solve this. They picked other important
projects. So, what is the first step? Add the 'up for adoption' status to
gem?


Reply to this email directly or view it on GitHub
#725 (comment)
.

@vassilevsky

This comment has been minimized.

Copy link

vassilevsky commented May 13, 2015

OMG I totally confused RGSOC and GSOC! 😱
I have since deleted my comment. Sorry.
We'll find out in two days.

Is there more info on the stat data problem?

@keithpitty

This comment has been minimized.

Copy link

keithpitty commented May 29, 2015

This is a wonderful idea. I'm looking forward to hearing more about the progress of it's implementation.

@vassilevsky

This comment has been minimized.

Copy link

vassilevsky commented Jun 4, 2015

http://railsgirlssummerofcode.org/blog/2015-06-04-2015-teams/

Binary (Angela & Lina Marcela)
Location: Barranquilla, Colombia
Project: RubyGems Adoption Center

🎉

@keithpitty

This comment has been minimized.

Copy link

keithpitty commented Jun 4, 2015

👏

@vassilevsky

This comment has been minimized.

Copy link

vassilevsky commented Jan 26, 2016

Did the team accomplish anything?

@qrush

This comment has been minimized.

Copy link
Member

qrush commented Jan 26, 2016

The app lives on at https://github.com/rubygems/adoption-center. it's still a concept I would like to see continue and shipped.

@sonalkr132

This comment has been minimized.

Copy link
Member

sonalkr132 commented Dec 3, 2018

Hey everyone, this has a PR now.

@sonalkr132 sonalkr132 self-assigned this Dec 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment