Allow collaborators to share Github Sponsors link in project readme
anonrig opened this issue · 29 comments
I propose adding github sponsors link in nodejs's readme next to TSC members, collaborators and triagers.
We don't have any funding options like Eslint or other large projects but this would give collaborators some incentive to continue their contributions.
I'd like to hear @nodejs/tsc's opinion before opening a PR.
SGTM
+1
Question: Do we want to limit this to only Github Sponsors or are we going to allow others like buy me coffee, or patreon etc?
I see no reason to limit to GitHub Sponsors only, but IMO it makes sense to not add more options until someone requests it
I’m +1 of the idea, but I think we should add them to the website instead.
Adding tsc-agenda for visibility and possible discussion
I’m +1 of the idea, but I think we should add them to the website instead.
Why not both?
Why TSC members and not everyone listed on the README? It'd feel a bit weird to have a special treatment for us.
In anyh case, we have a bunch of automation that relies on the README list to formatted the way it is currently, so we'd need to update all that before merging the change.
I’m +1 of the idea, but I think we should add them to the website instead.
IIRC the TSC members are not listed on the website atm – if we add such list to the website, we should not forget about adding a bullet to the onboarding/offboarding document.
Why TSC members and not everyone listed on the README? It'd feel a bit weird to have a special treatment for us.
I meant everyone, not specifically a portion of the organization.
Why TSC members and not everyone listed on the README? It'd feel a bit weird to have a special treatment for us.
I meant everyone, not specifically a portion of the organization.
My bad! In that case, should we transfer this to nodejs/node? It seems it should not be a TSC decision.
Doing it should fall on the TSC, I think we should approve it here before opening there.
SGTM
Adding it to the website and or the readme.
SGTM, as I mentioned in the discussion in the TSC call, the proposal should define a standard way of presenting that link, e.g: use a plain html link with a text: (Sponsor me) linking to the collaborator-selected sponsor url.
@anonrig the suggested next step was a PR in to the collaborator documentation. I think adding a section into https://github.com/nodejs/node/blob/main/doc/contributing/reconizing-contributors.md would make sense.
From the discussion it sounded like it being very specific as outlined above in #1552 (comment) by @ruyadorno should be specififed, and that existing tooling would need to be updated to allow the added (Sponsor me) link.
In terms of bikeshedding I think I prefer the name (Support me) for the visible name of the link.
Would you like to create that PR?
Also, it might be good to see what percentage of collaborators are interested in utilizing this.
@tniessen do you have a suggestion for how we ask which collaborators would be interested.
We could do that through a different issue, a discussion item, or maybe an at mention to all collaborators in the PR with the ask of how many people are interested?
@mhdawson Not really. I probably would have just pinged the entire collaborators team to see how many people respond positively. (On the other hand, if people are in favor of this idea in any case, it might not be relevant to see if the broader collaborator group is interested.)
@tniessen my thinking is that anything that we can do to support collaborators is good, provided there are no concerns in terms of impact to the project.
I believe we should just take the time to consider the fact that this might create an incentive for collaborators to game the system in order to remain listed as a collaborator while not actively making contributions to the project. Being capable of effectively prune the list of collaborators was one of the points brought up during the conversation on nodejs/node#52459.
Sorry to insist, but I don't see the TSC position on this topic could be different than "if Collaborators are onboard with the idea, that's great". Unless there's a lack of consensus among Collaborators, I don't see the point of discussing the issue here.
@ruyadorno I can understand the concern, but I'd prefer that we optimize for supporting active collaborators versus trying to avoid inactive collaborators who stick around a bit longer.