-
Notifications
You must be signed in to change notification settings - Fork 146
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
Suggestion: Provide template/guides/automation for common maintainer needs #17
Comments
This was referenced Jan 10, 2019
Assigned myself, per #137 |
This is still something we definitely want to do. We have issues floating around that relate to this, but I think this issue is too large and ambiguous to be useful as it is. marking as |
maybe this has / can been superseded by this issue now? #373 |
Agreed, ty for tying it to it's successor 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are many great tools and features we can take advantage of to help reduce day-to-day support workload. All of which take time and resources to research, setup, and maintain. That time takes away from actual support and maintenance of the modules themselves.
As an example, on Express we have talked about setting up GH issue templates, helpful bots and other things like this. But because the main contributors prioritize the immediate need of doing security patches, responding to user support requests, reviewing PRs, and discussion of new features those things don't get done. In a large community like Express, there are tons of repo's we would need to set this up for, making a small job for each into a big one for the whole group.
If there was a great template, guide, or even a team which could go around and do this for us, it would be super helpful. Is there is an automated way to add this? What about keeping them all updated as the standard changes? I think it would be great to hear from people who have set these up and decide on the best and most impactful things we can do.
These kind of resources would save each individual maintainer group from having to go through the whole process themselves. It would also mean that consumers and new contributors would be more likely to be familiar with the tools in use, so it might make it easier to get someone to take things over if you move on.
The text was updated successfully, but these errors were encountered: