Better management of issues

I’ve been going through a lot of our inactive unaccepted issues and closing them/checking in. While doing so, I had some ideas that I wanted to discuss and see what others thought.

Things we’re doing well

First off, I want to say that I actually think we do quite a good job of managing issues relative to the number that come in and the bandwidth we have as a team. Many other popular projects have many more open issues than we do.

As far as getting better at managing new issues, I think we’ve been moving in the right direction with some of our recent policy changes, including:

• requiring champions from the team who commit to seeing the process through
• closing unaccepted issues after 21 days of inactivity
• the guidelines laid out for TSC-approved issues

I think these policies will alleviate some of the challenges we’ve faced previously, as all new issues will have someone who is taking on the responsibility of implementation (whether it’s a team member or a community member).

Challenges

• This unfortunately doesn’t help us out with issues accepted before these policies were in place, which is quite a few. And it’s hard to imagine that many of them will actually get done, given that they don’t have a champion on the team or a much visibility in the community.
• Another challenge is balancing issues that we think are crucial and are willing to implement ourselves and having open issues for nice-to-haves that the wider community can work on and contribute. I know there are plenty of features that the community asks for that we would welcome PR’s for but just don’t have the bandwidth to implement ourselves right now.

The new policies for accepting issues don’t really allow us to create issues for nice-to-haves unless someone is willing to take it on immediately. This, combined with the fact that we don’t close old accepted issues means that a lot of help wanted issues are older ones that may or may not still be relevant.

Possible Solutions

• I was thinking it might be nice to have a policy that allows us to close accepted issues that have not seen activity for an extended period of time. I think this time should be longer than the 21 days we use for unaccepted issues (6 months?), and we should allow for exceptions (JSCS compatibility issues, for example).
• We have the help wanted and beginner labels, and I wonder if we could codify our usage of those labels to help the community contribute. For example, if we encounter an issue that we have decided (through consensus) is a nice-to-have that we support but is not crucial to the roadmap and is not championed by one of us, we can label the issue with help wanted and encourage the community to check these issues out (on our site, social media, etc.). And again, they should probably be culled if they’ve been on the shelf for too long with no activity.
• One of the reasons I started contributing to ESLint was that the documentation was so thorough that I knew what was expected of me, lowering the barrier for entry. I would personally love to start making true beginner issues with the beginner label - i.e. simple docs changes where it’s very clear what needs to be done or an enhancement that adds an option to an existing rule. I know I’ve talked to a number of people who were interested in contributing but didn’t quite know where to start, and I think these kinds of issues could be the final nudge that gets some of our community members to contribute.

It seems to me like closing older accepted issues with no activity (say, after 6 months) and creating a list of help wanted issues - that we have discussed and reach consensus on but do not currently have a champion for and are intended at the time of acceptance to be open for the community to help contribute to - would allow us to ensure that all issues are relevant, manageable, and make it even easier for community members to contribute.

Summary

To summarize, since I know this turned into a wall of text (apologies!):

1. Can we create a policy that allows us to close accepted issues that we deem not crucial to the roadmap that have not seen activity for a long period of time?
2. We have policies in place that allow us to manage newer issues by championing them and either implementing them ourselves or helping community members implement them. Can we codify a process for accepting issues we deem as non-crucial but would welcome PR’s for? And while doing so, can we perhaps help new contributors get over the last hurdle of contributing and make issues specifically for them?

[nzakas]

Okay, here’s what I’ll propose to get the ball rolling:

1. Help wanted issues should be closed after 90 days if they have not been completed.
2. Accepted issues may be closed after 90 days if no one is willing to step forward and own the work to complete it.
3. Beginner issues must be open for 30 days from the day the issue was labeled before a team member is allowed to work on it.

@eslint/eslint-team thoughts?

[nzakas]

I think the key thing for “help wanted” is to decide on a timeout period after which we just close them. If we can decide on that, then we can go back and close a lot of the old ones we have.