Enabling the community to solve the open issues is a big metric to measure how involved a community is. If most of the issues are solved by a small number of developers in a package, it either means the community is passive or they find it intimidating to contribute. This can happen without the package maintainers wishing otherwise.
I’ve seen a lot of repositories tag their issues with
- Technical Difficulty: Low, Medium, High
- Time to Implement: < 1 Hour, Few Hours, Few Days, A Long Time
- Request to Audience: Beginners Only (This preserves non-critical issues in case the main team is busy), Up For Grabs, Help Wanted, etc.
- Category: Bug, Enhancement, Feature Request
- Progress: In Progress, Almost Completed, Not Yet Started (implied)
This doesn’t take much time/effort on the part of maintainers and has potential to increase contributions from the wider community. Moreover, it would help people who might want to organize Bug-Crushing parties or Hackathons to aid in development efforts. This does come with an increased burden on the maintainer as well as accepting that the labels might not be 100% correct, esp for Technical Difficulty and Time to Implement.
Right now, there is no community-wide guideline regarding this, but I’ve seen a lot of ROS packages add labels to keep track of their issues. I feel it’d be better if we all started doing that, both while writing the issues (Community and yes, Github doesn’t have such a feature, but we can mention as much as possible while creating it) as well as while reading them for the first time (Contributor/Maintainer).
I hope we can gather some suggestions on what more can be done to make the issues list a less daunting and more inviting place. I’m sure there are a lot of good practices for issues such as maintain a list of feature requests as issues, create smaller easily digestible issues from larger issues, etc.