froi
commented
4 years ago T.L.D.R.
- Use labels to show state. Eg. "In progress", "Being worked on", "invalid", "Won't be worked on", ETc.
- Use labels to guide people to what you want them to work on. Eg. "Good first issue", "Help Wanted", etc.
- Use Milestones to represent releases, show progress, and roadmap.
- Use a GitHub Action for stale states.
- Put this all into the project's contributing.md
I got some ideas for this (surprise, surprise 😉 ).
Labels for quick at a glance statuses
Using labels like "Good first issue", while subjective to you, can still give direction to new contributors. "Help wanted" labels I think are key to get community involvement ( I know you all know this 😄 ).
Project Boards
Project boards can show exactly what is in flight at the moment. While great for representing sprints and what not I don't think for a project like this it should be used like this.
For projects that are done by volunteers project boards and represent releases. In this way it can substitute milestones.
At the same time the columns can also just be expressed with labels.
Milestones
I like milestones. I think it's a great way to show releases and at the same time a roadmap.
I think milestones also work really well with OSS projects like this one because of the unimportance of issue state ("TODO", "In progress", etc.).
Closed out Milestones are also a good way of showing progess, they represent your releases after all 😉
Issue and PR stale state
I think an issue or PR staleness is also a good thing to have. Showing what you consider stale because of low to no interaction is a good showing of project maintenance. Setting the rules of when an issue or PR is considered stale is a good practice IMPO.
There's a really good stale GitHub Action that can help you automate this. Take a look at suministrospr
Having a process like this helps everyone contributing or new to contribute towards the project know where the project is, what's in progress, and where we need help on.