Sponsor based GitHub feature toggling

[pierotofy]

Select Topic Area

Product Feedback

Body

This came up while discussing improvements to the sponsors program: https://github.com/community/maintainers/discussions/292

In order to provide incentives for sponsors, GitHub should offer the ability to toggle the following features based on a sponsorship level:

• Create/Open issues. Many peoples already have this as a policy, But the majority of people raising issues just ignore it. I think view and reply to issues should still be allowed to non-sponsors. Optionally also make is based on issue type
• Access to discussions
• Access GH Package feeds.
• Access Wiki
• Access Release Downloads

This would be similar to the the sponsor's only repository access: https://docs.github.com/en/sponsors/receiving-sponsorships-through-github-sponsors/managing-your-sponsorship-tiers#adding-a-repository-to-a-sponsorship-tier

[SimonCropp]

i think to make this work we would also need a "yearly sponsorship" option. on many of my project i would be happy with "1$ a month and u can do issues", but i would want them to do 1$ for a full year.

[dansiegel]

I like this, but think this feature should be able to go beyond GitHub sponsors. Even if it was a manual process I can see value in being able to support those that may sponsor a project through alternative means like Open Collective, or for those that may offer paid support / licensing. Similarly many OSS maintainers like to offer extended support for other OSS maintainers as we may have mutual dependencies on one another.

A good solution IMO would be to have the ability to define access lists that can be managed manually where the individual list could be granted access to certain Discussions or abilities. It would be nice to have features for the access lists to add users by:

• GitHub username
• Email
• automatic access for users that are members of a GitHub organization (for example I might add the dotnet org so that by default all members of the dotnet team have access)

[kzu]

You could also provide an email domain to mean "anyone with an email from this domain". Given that GitHub allows organizations to verify their domain, this would tie the two nicely.

This could be a .yml on the .github folder or the org-wide community files for the same.