The reactjs GitHub organization (henceforth "reactjs" or "the org") was created to ensure critical open source projects in the React community receive long-term support and maintenance.
We believe the following principles will provide a strong ecosystem of open source projects by ensuring they have active and enthusiastic owners and contributors.
When you start a new job, you assume responsibility for the code base. When you, or somebody before you, imports a reactjs lib, you have that same responsibility. We are building this stuff together. There is no “core team”. If you use our code, it is now our code. (Get it?!)
Collaborators are added liberally by other owners and/or collaborators. They need only contribute some non-trivial commits and follow the project's contribution guidelines and Code of Conduct (if one exists).
This also means contributors should be consumers. If a contributor finds they are not using a project in the “real world”, they should reconsider their involvement with the project.
When you leave a job, nobody expects you to continue to maintain all the code you wrote while at that job. If the business falls apart in your absence, there’s a problem with the business.
Before a project joins the org, it should have some significant usage in the community and multiple owners so that a major contributor’s absence does not critically injure the project. If it has significant usage but only one or two owners, new owners should be added as soon as possible.
Becoming an owner should not come with the pressure to maintain the project for longer than you have interest. This should encourage people to accept ownership, even if for a short time.
Owners of reactjs projects can stop working on them without any guilt or explanation, just like a job. If this makes you uncomfortable, you can either not use our projects or, preferably, increase your organizations investment in open source and dedicate some time to helping with maintenance. If you use our code, it is now our code. (Get it yet?)
The first priority in managing the issue tracker for a reactjs project is avoiding burnout. Sprawling lists of inactionable, open issues, is burnout’s most potent fuel.
This means:
Bug reports without test cases (copy/paste-able code is enough) can be closed with or without comment.
Usage questions can be closed immediately and directed to stack overflow. Owners should pay attention though, because the docs or the APIs probably need help if there are a lot of “question issues”.
Feature requests without thoughtful commentary and sample code can be closed with or without comment.
Issues without activity in the last 30 days can be closed with or without comment. If this is a bug you care about that isn’t getting attention, fix it. If you’re good enough to understand the bug, you’re good enough to fix it. Remember, it’s our code now.
If you have imported a reactjs lib, you can gather responsibility and be a contributor in a number of ways:
Answer questions on stack overflow
Add test cases to bug reports
Add fixes for test cases
Write up thoughtful feature requests with sample usage
Close issues that qualify for closing (see Avoid Burnout)