add "Gratipay" link to gem pages #500
Comments
|
Gittip for whom, though, if there are many authors? On Dec 13, 2012, at 3:17 PM, Chad Whitacre notifications@github.com wrote:
|
|
@indirect Well, for GitHub orgs, Gittip currently has pages that list the individuals involved, at URLs like: https://www.gittip.com/on/github/rubygems/ I was thinking we could do something similar for RubyGems.org, with pages at URLs like: https://www.gittip.com/on/rubygems/gems/slim/ That page would list individuals like the GitHub page above does. Does that make any sense? See here for deets. |
|
Ah, yup. Makes sense to me. I had not yet seen the github org pages, but they look pretty awesome. |
|
For the record, it sounds like @tehgeekmeister is going to take this on as a project. Huzzah! :D |
|
I really like the idea of having rubygems show the gittip link on any gem that has an author who has connected their rubygems.org account to gittip. That may be too much work on the rubygems.org side, though. |
|
@indirect so I understand what you mean, here's some concrete examples: Would you like gittip links to each author (and/or the organization, as appropriate) inlined there, or... Or, on both? Also, from the rubygems community side, is the preference to make gittip links opt in or opt out? I'll be happy to build it either way. |
|
I was thinking a single link to the gittip page for the gem, up near the RSS link -- but only visible if at least one of the gem's authors has linked to gittip. On Jan 8, 2013, at 1:59 PM, tehgeekmeister notifications@github.com wrote:
|
|
Oh, I had not noticed the proposed new URL structure on the gittip issue. That makes sense. I'll start working on it that way. |
|
Also, since I don't see any decision mentioned anywhere re opt{in/out}, I will assume opt in for now, but try to make it easy to change later. |
Yes, please, and thank you. I'm definitely more comfortable with it being opt-in. I don't want Gittip to appear to be overstepping bounds.
This sounds good to me. Here are the requirements I'm seeing (working with slim as a random example): A person can visit A person can visit A gem owner who has a Gittip account can connect their RubyGems.org profile to their Gittip account via UI in the "Connected Accounts" section of their Gittip profile. Probably the easiest thing to do is have UI on the RubyGems.org side for adding a Gittip username to your RG profile. That way RG is guaranteed to have the info it needs to render the gem view with the possible Gittip link. Once the connection is made on RG then the gem owner can visit their Gittip profile to complete the connection. This way we can just parse their RG profile for the Gittip username, instead of doing this via email. Does that sound right? |
|
All sounds good to me. I'll focus on the rubygems side of this stuff today, and gittip stuff after that (but maybe still today). |
|
That sounds exactly like what I was thinking. 👍 On Jan 9, 2013, at 1:15 PM, Chad Whitacre notifications@github.com wrote:
|
|
One other thing we have a choice on is whether rubygems should call gittip to say the authorization has happened, or gittip should hit the rubygems API on pageload to check (until the authorization is there). I think rubygems calling gittip makes more sense for the case of people removing gittip from their gem/rubygems profile later. Also, it's probably more efficient just in general. |
I guess I was going for low-hanging fruit when I suggested that this be manual. You're right, though, and I think the pattern we're establishing is good: the partner (RG in this case) "owns" the connection, and Gittip provides API for updating Gittip when the relationship changes on the partner side. |
|
From all I can tell, this is the only place to modify anything about a gem on rubygems.org, except by pushing. I don't see any big conceptual problem with doing the linking from here, but the copy will need to change, and perhaps this isn't where the rubygems people want it? Alternately, it just struck me that we could just have a visible-to-maintainers-only button that does this from the gem page itself. I think that sticks with the way it's set up currently a little bit better, but again, it's not my decision to make. |
|
For concreteness' sake, I'm thinking of a button for linking/unlinking to the left or right of the edit button here: |
|
(If the previous comment has a broken image for you in email, it's because I submitted the comment before github's image uploading magic could finish doing it's thing. It's up to date on the issue itself!) |
|
@tehgeekmeister My understanding was that we were talking about linking a Gittip account to a profile on RubyGems.org, not (at this point) to a gem. In which case, it seems like the profile edit form would be the place for a "Gittip username" field. No? |
|
Oh, so you'd want the gittip link enabled for any gem where any of the authors have opted in, rather than having options for both gem-level opt in and author level opt-in? That's no harder, but we certainly need to decide which we want. |
|
Then, the gittip link would take them to an organization like page on gittip, but where only the authors who've opted in are listed in such a way that you can donate to them (but, perhaps, all of them are listed). |
|
I understood @indirect to be asking for:
To which I'll suggest adding:
|
|
That seems reasonable to me. I'll leave the current PR open until we have confirmed that the gem level opt in approach is undesirable, and start working on another version of it that takes the owner level opt in approach in the mean time |
Right. Here's an example of how that's handled on GitHub organization pages on Gittip: |
|
Here's a question: What happens when I change my username on Gittip? It's possible then for someone else to grab my old username on Gittip, and potentially siphon some tips intended for me, if I forget to update the Gittip connection out on RubyGems.org. It's probably the case that Gittip should provide an immutable id apart from username. I've ticketed that over in gratipay/gratipay.com#455. The implication is that when the user on RubyGems.org enters their Gittip username, we should hit Gittip to fetch the immutable id with which that username is presently associated. In terms of handling name changes, we could have Gittip push to RubyGems.org when that happens, or RubyGems.org can ping Gittip on its own schedule (perhaps whenever the edit form is loaded). |
|
Good thinking. I'll make sure to do something like that, or start a discussion if it seems like it needs changing. |
|
Chad summed up what I was thinking very nicely. A gittip link on rubygems profile pages also seems useful, albeit unlikely to be used very much (as far as I know, profiles on rubygems.org don't get much traffic). As for ids vs usernames, I think it makes sense to start with "light" association, just in the form of links to gittip usernames. In a more advanced version of this feature, I can imagine gittip providing an OAuth authentication flow that any other application can use to link profiles in that application to a particular gittip account. Gittip can then use the token provided to that application to ensure that the link always goes to the correct gittip account (and also to allow gittip users to see a list of other sites where they have accounts linked to their gittip profile, and possibly revoke the link). On Jan 9, 2013, at 7:18 PM, tehgeekmeister notifications@github.com wrote:
|
|
I'll implement it based on username for now, with the caveat that on gittip's side, whenever a user changes their username and has an associated gem, we will break the association to that gem. That prevents the siphoning, but we certainly do want to do something better around that; some kind of OAuth sounds good, and would allow arbitrary services to integrate well. |
|
@indirect We've got the gittip side of things done. Once that's deployed, what's necessary to get this live? |
|
@indirect awesome! |
|
@indirect somehow I missed a big huge part of what needs doing on the gittip side, thought it's not complicated. Probably should hold off. I guess I'm still waking up or something. 😫 |
|
I have rubygems account and has some gems but I can not upload my gems in gittip but in my profile I update the gittip id and also in gems it is showing link but it is not uploaded in gittip https://www.gittip.com/on/rubygems/gem/google_book/ |
|
You don't upload any gems in gittip. In fact, no setup is done on the On Fri, Nov 8, 2013 at 7:56 AM, Rajarshi Das notifications@github.comwrote:
|
|
Thanks for suggestion but look at my question I asked that the gittpi link was not working of my gems. hey I did but the links are broken look at the gitpi is showing on my gem but the link of the gittip is broken http://rubygems.org/gems/google_book https://www.gittip.com/on/rubygems/gem/bbc_api/ |
|
Gittip doesn't yet support those links. It was a mistake to enable them on rubygems.org. See #612 |
|
oh, that! I thought that issue was resolved for some reason. I'll fix it today, don't know how soon it can be deployed. — On Tue, Nov 12, 2013 at 4:54 AM, David Radcliffe notifications@github.com
|
|
Picking up from gratipay/gratipay.com#1591 (comment), can we think about a simpler implementation than we were considering previously? How about a |
|
I just did some spelunking: Gratipay's teams feature began life in this commit from April 11, 2013, reached its first point of stability a few days later, got a rewrite a couple weeks later, on May 1, and then a second rewrite to its present form two months after that, on July 1 (with a blog post two days later). This present ticket is from December 13, 2012, four months before any sort of teams feature on Gratipay. The conversation started even earlier, on August 4, 2012, seven months before teams. tl;dr It's appropriate to rethink this ticket in light of Gratipay teams. :-) |
chadwhitacre
changed the title
|
@whit537 I think it'll be easier if we don't integrate gittip/gratipay at all. I'm working on some changes to make our test suite better (read: removing cucumber and some older features like RubyForge login), and then next up will be taking the gittip info out. I think instead a "donation" link in |
|
Oops meant to add: I'd happily accept a PR to add a Donation/Donate string to the |
|
@qrush Indeed, that's even simpler. :-) |
Gittip is an open-source platform for sustainable crowd-funding. Gittip lets you set up small weekly anonymous donations to people who do great work. It's particularly well-suited for open source programmers and projects. Over on gratipay/gratipay.com#223, @qrush floated the idea of integrating with RubyGems. There's discussion there about the Gittip side of the integration.
This ticket is for the RubyGems side of the integration. A basic integration could be quite straightforward: @qrush suggested adding a Gittip link next to the "Download | Subscribe | RSS" links:
However, @matin raised the question of whether the presence of the link should be opt-in or opt-out on the RubyGems side. How would RubyGems like to proceed?
The text was updated successfully, but these errors were encountered: