Skip to content
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

Allow collaborators to share Github Sponsors link in project readme #1552

Open
anonrig opened this issue May 11, 2024 · 25 comments
Open

Allow collaborators to share Github Sponsors link in project readme #1552

anonrig opened this issue May 11, 2024 · 25 comments

Comments

@anonrig
Copy link
Member

anonrig commented May 11, 2024

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.

@ronag
Copy link
Member

ronag commented May 11, 2024

SGTM

@MoLow
Copy link
Member

MoLow commented May 11, 2024

+1

@anonrig
Copy link
Member Author

anonrig commented May 11, 2024

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?

@aduh95
Copy link
Contributor

aduh95 commented May 11, 2024

I see no reason to limit to GitHub Sponsors only, but IMO it makes sense to not add more options until someone requests it

@mcollina
Copy link
Member

I’m +1 of the idea, but I think we should add them to the website instead.

@benjamingr
Copy link
Member

Adding tsc-agenda for visibility and possible discussion

@anonrig
Copy link
Member Author

anonrig commented May 11, 2024

I’m +1 of the idea, but I think we should add them to the website instead.

Why not both?

@aduh95
Copy link
Contributor

aduh95 commented May 11, 2024

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.

@anonrig
Copy link
Member Author

anonrig commented May 11, 2024

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.

@aduh95
Copy link
Contributor

aduh95 commented May 11, 2024

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.

@mcollina
Copy link
Member

mcollina commented May 12, 2024

Doing it should fall on the TSC, I think we should approve it here before opening there.

@BridgeAR
Copy link
Member

BridgeAR commented May 15, 2024

SGTM

Adding it to the website and or the readme.

@ruyadorno
Copy link
Member

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.

@mhdawson
Copy link
Member

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

@tniessen
Copy link
Member

Also, it might be good to see what percentage of collaborators are interested in utilizing this.

@mhdawson
Copy link
Member

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

@tniessen
Copy link
Member

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

@mhdawson
Copy link
Member

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

@ruyadorno
Copy link
Member

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.

@aduh95
Copy link
Contributor

aduh95 commented May 22, 2024

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.

@mhdawson
Copy link
Member

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

@jasnell
Copy link
Member

jasnell commented May 23, 2024

While I'm not opposed to the idea, I'm not sure if the project readme is the right place for it and we'd need some guidelines around it. For instance, each contributor should be limited to a single link at a maximum. That could be to a page where they choose to list multiple support options but the main link itself should be limited to just one. Second, if the link is going to be to specific sponsor services then it should be limited only to specific vetted services -- I don't want to get into a situation where someone posts a link to something like an onlyfans type of thing, etc. Third, the link itself should have specific display text like "(sponsor link)" or something equally generic and consistent.

@jasnell
Copy link
Member

jasnell commented May 23, 2024

Another important thing to keep in mind is that Github Sponsors and other sponsorship services may not be available as an option for all Node.js contributors if they happen to live in a region where such services aren't provided. It's important to recognize that not all collaborators will be in a position to be able to take advantage of this.

@mcollina
Copy link
Member

I would support only GitHub sponsors for now.

@mhdawson
Copy link
Member

@jasnell your points 1 and 3 were already discussed/agreed in the TSC meeting where it was discussed. The link needs to be standardized because there is tooling that validates the entries in the README.md.

The second point was not discussed and its a good thing to discuss/agree on as we don't want what the links point to, to reflect badly on the project.

Different people could be supported in different ways. For some financial sponsorship through GitHub sponsors or something else could makes sense. For others, it could be an ask that if they are a customer of where the person works for to let their the company know that they use Node.js.

Just agreeing that we'll need some guidance on what is appropriate or not on the sponsor page.

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

No branches or pull requests