Better management of issues

[kaicataldo]

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]

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?

Absolutely. I think we are long overdue for this. I've struggled with what might be the right length of time to do this. My general mindset is that 90 days is enough, as in my work experience it seems like things that don't get done within a quarter tend not to get done at all, so I'll throw that out as a starting point for this discussion.

Can we codify a process for accepting issues we deem as non-crucial but would welcome PR's for?

In the past, we've labeled these as "help wanted." Unfortunately, we haven't seem much movement on those tasks. I think they fall into the same category of issues that have been open for too long. Maybe we should have a timeout set on those issues as well? Or is there another way you're thinking of designating these issues?

I would personally love to start making true beginner issues with the beginner label

Me too! The trouble we've had in the past with "beginner" issues is that team members have quickly addressed them (I think people just breeze through the issues list and think "oh, this is easy, I'll just do it right now."). I fully support having beginner issues and if we want to start doing that again, I think we also need a rule to say that team members may not address a beginner issue unless it has been open for longer than X amount of days (maybe 30?) to make sure they stay open long enough for people to find them.

[kaicataldo]

In the past, we've labeled these as "help wanted." Unfortunately, we haven't seem much movement on those tasks. I think they fall into the same category of issues that have been open for too long. Maybe we should have a timeout set on those issues as well? Or is there another way you're thinking of designating these issues?

I think the help wanted label is great, and having them fall in the category of issues that have been open for too long was exactly what I was thinking. My main concern is that the majority of help wanted issues have been stagnant for a long time and it's pretty difficult for a non-team member contributor to come in and understand why it's needed, if it's still relevant, etc.

I love having help wanted issues, and I think that by taking a few steps to better actively maintain our accepted issues and making sure they're all still relevant we'll improve the quality of our help wanted issues a lot.

I think we also need a rule to say that team members may not address a beginner issue unless it has been open for longer than X amount of days (maybe 30?) to make sure they stay open long enough for people to find them.

This would be great! If we as a team are aware that this is a list we'd like to maintain I think we'll be able to find a number of issues we can make for newcomers to the project.

[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.

[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?

[kaicataldo]

Marking as accepted because we have a number of thumbs on @nzakas's proposed details. I'm happy to make a PR to add this to our docs!

[nzakas]

@kaicataldo go for it