Second round of edits on the RubyGems.org partnership

[adarsh]

Reason for Change

• The language came off to some readers as a bit defensive, and long.
• Taking a second draft at the language.

[adarsh]

cc @evanphx

[rubymorillo]

@adarsh made some more changes to the paragraph! Specifically:

• linking out to the post that goes in depth about the RubyGems partnership,
• small copy edits

[practicingdev]

Just a quick note, I think that this (slightly edited) line from the original is more clear than its replacement:

RubyTogether sponsors individuals to work on development and operations work of RubyGems.org to augment the work of volunteers.

The second line from the original ("The availability of RubyGems.org is not dependent...") does feel defensive and unless @evanphx thinks it's essential, seems like a candidate for removal.

The main thing to try to avoid is making it sound like "Ruby Together is the only org which is responsible for paid development work on these projects," and I think this round of edits pushes things a little bit back into that confusing direction.

By using the quoted line above, maybe it strikes a balance?

(I'm offering an "outside" view here by considering those who are neither affiliated w. RubyTogether nor Ruby Central)

[practicingdev]

Or if you're really looking for something short, replacing the word "funds" with "sponsors" to me is still an improvement:

RubyTogether sponsors individuals to work on development and operations work, and ...

To me "funds" implies an ownership/direct governance relationship, where "sponsors" makes it clear that it's a contribution.

[rubymorillo]

@practicingdev incorporated the suggested edit. Thanks.

@indirect feel free to review when you have a chance!

[practicingdev]

@rubymorillo That looks clear to me, thanks! (Although I do think those who commented on #5 ought to chime in if they have concerns)

But taking a closer look at this and where it's likely to be used (such as at the bottom of rubygems.org) it seems like shorter is better, and detailed/nuanced explanations could be on the Rubygems Sponsors page where needed as long as the link to that is always provided from the short form copy.

[evanphx]

Hi all, yes my previous statement came off a bit defensive and long but that was on purpose. There is a lot of confusion in the community right now and I believe we should over communicate and over state the situation. The current edits are still ambiguous and don’t let a reader understand the Ruby Central will keep RG.org afloat even if RT were to switch gears. In other words, RG.org is not dependent on the kindness of RT. I believe that still needs to be made clear.

[rubymorillo]

@practicingdev yep, that’s correct. From my understanding it’s meant to be short-form copy that will live in the RG footer, the FAQ section of the RT site, and READMEs. In that copy, we link out to both a blog post that details the RubyGems partnership and the sponsors page, which you reference in your comment.

Hi @evanphx, would you like to propose that change in the RG Sponsors page? That sounds like the best place for us to go into more detail. We obviously want to make sure the copy proposed in this PR is accurate while accounting for brevity due to where it will show up on various pages. But since we plan on linking our to more resources, we can write more at length there.

[practicingdev]

@evanphx:

I understand that concern, for sure.

One thing I think would help is if we can be a bit prescriptive about what the design goals are around building this standard text, where it'll be displayed, and what the intentions are behind them.

For starters, let's talk about the blurb at the bottom of the homepage of Rubygems.org. Currently, it looks like this:

It seems like the current pull request we're discussing is viewing the content through that lens: A first interaction with a Ruby programmer who doesn't know much of anything about how RubyGems is managed and supported.

Regardless of the specific wording chosen, it seems like there are at least three different goals that ought to be served by this credits blurb:

(i) Identify Ruby Central as the official organization responsible for the stewardship and management of RubyGems.org

(ii) Identify RubyTogether as an trade organization that you or your company can donate to which may (by way of sponsoring the work of individual open source contributors/maintainers) help improve the state of RubyGems.org

(iii) Acknowledge Fastly as a sponsor, giving them credit for their contribution.

Clearly (i) matters to Ruby Central, and rightly so. (ii) matters to Ruby Together because it's going to be a source of potential new paying members, and arguably that's in everyone's interest, even if Ruby Central is fully operationally independent. I see (iii) as almost like an advertisement, but Fastly is contributing something quite valuable and so that seems reasonable to acknowledge.

It's also clear that the current version of the copy on the rubygems.org website only accomplishes (ii), and it also could potentially be misleading. That's been up there quite a while, and it needs fixing.

This is the version of the text that was reached by consensus in #8:

RubyGems.org is managed by Ruby Central, a community-funded organization supported by conference participation for RailsConf and RubyConf through tickets and sponsorships.

RubyTogether sponsors individuals to work on development and operations work of RubyGems.org to augment the work of many volunteers. The availability of RubyGems.org is not dependent on these paid contributors and is the sole responsibility of Ruby Central.

Hosting fees are paid by Ruby Central and CDN fees are generously donated by Fastly.

I feel like the tone of this message could be improved considerably without much loss of clarity by removing one line (the one about "The availability ... is the sole responsibility of Ruby Central") and rearranging/rewording things slightly...

RubyGems.org is managed by Ruby Central, a community-funded organization supported by conference participation for RailsConf and RubyConf through tickets and sponsorships.

Hosting fees are paid by Ruby Central and CDN fees are generously donated by Fastly.

Additionally, RubyTogether sponsors individuals to work on development and operations work RubyGems.org that augments volunteer efforts from the Ruby community.

Learn more about our sponsors and how they work together.

I feel like from the perspective of "Person who lands on the rubygems.org page", it'd be clear to me from this text who manages the project, and where additional supplementary sponsorship is coming from. But it'd read more like a credits section than a disclaimer, and I think that's in everyone's interest.

If more detailed explanations were needed, that could be done on the full-length RubyGems sponsorship page, which would be directly linked from this blurb.

(Figuring out what the correct wording is for that page is a whole other story, and maybe a separate PR could be opened for that?)

Anyway, thoughts? @evanphx @adarsh @rubymorillo

[evanphx]

I totally agree that the bit on rubygems.org itself will need to change, no question. I can certainly submit a PR for that language, but I'd like it to be similar to the language RT uses. If you feel that the rubygems.org bit should be more forceful in Ruby Central's role, I worry that if RT is does not provide the same picture it creates additional confusion.

Folks are already confused and I want to try and end that confusion.

I ask myself a few questions when looking at these edits:

1. Is someone reading it going to think that ONLY RubyTogether folks work on RubyGems.org? If so, then in my mind it's misleading.
2. Would the reader believe that RubyTogether could shutdown RubyGems.org if they wished?

The second one hasn't been true for all of the edits thus far, but it's a question I keep in mind when reading.

Also, I want to thank y'all for this process. I'm super happy we're discussing this and getting it all sorted.

[adarsh]

If you feel that the rubygems.org bit should be more forceful in Ruby Central's role, I worry that if RT is does not provide the same picture it creates additional confusion.

Agreed - the goal here is to reduce confusion and to that end, be consistent with language used in several places.

1. Is someone reading it going to think that ONLY RubyTogether folks work on RubyGems.org? If so, then in my mind it's misleading.
2. Would the reader believe that RubyTogether could shutdown RubyGems.org if they wished?

The second one hasn't been true for all of the edits thus far, but it's a question I keep in mind when reading.

Certainly, and perhaps this is where we should user-test this language with others with this specific aim? I definitely am on the other side of this perspective but have no idea how representative my thoughts are.

In the interest of this change not getting stale, and also further iterating, I propose this:

1. Update the language to that proposed by @practicingdev (see commit a3f03ce for the change)
2. As long as the RT board agrees with the changes, merge them as-is.
3. Ask publicly (RT Slack, twitter, wherever) if others feel that the "rubygems.org is wholly dependent on RT" confusion is still exists and to propose changes in new PRs.

Thoughts?

[adarsh]

Bumping @rubytogether/directors for feedback on the language (shouldn't take too long to review, it's short).

Will merge by Weds ideally.