Hi Erik, My 2c - you (the project) may have to 'take a view' on some of the issues if they date back to older versions.
In my experience fixing bugs obviously requires replicating the problem, fixing it and confirming that its fixed, but if the issue was reported against an old version, then someone needs to replicate it in the old version (to be sure its not PICNIC - Problem In Chair Not In Computer) then replicate it in the current version to check that its still a bug, and _then_ start fixing it... Volunteers are unlikely to want to take on all that effort, so it does mean an ever increasing number of old bugs (as Jarek says, only stakeholders tend to allocate resources to that kind of thing). So I would start by seeing if you have a lot of really old bug reports and consider closing them as a matter of course. Huge bug lists also tend to put people of as they don't know where to start and don't feel that they can even make a dent in the pile. Kind Regards Paul Angus -----Original Message----- From: Jarek Potiuk <ja...@potiuk.com> Sent: Friday, July 9, 2021 12:51 PM To: dev <dev@community.apache.org> Subject: Re: Issue Management in Apache Projects We are struggling with it as well in Apache Airflow. I can write about some of the things we actively do to try to bring it down (and we can see how it will work after some time). We have not succeeded yet (we also have ~800 issues opened) but we for example have ~130 opened PR and we used to have > 200 of them so we see the sign of improvement. * we triage and respond to the issues pretty quickly and "aggressively". I.e when there is not enough information or the issue is very likely to be caused by external factor, we close the issue explaining what's missing, what the author should do, what information should be provided and add info that it will re-open as soon as more information is provided. I found closing issues in this case works much better for motivation of the user to add more information (or save the hassle of maintaining status and closing the issue later). * we have automated stale-bot that closes inactive issues and PRs after (30 day inactivity = notice, + 7 day = closing) * when the user raises the issue which is a question, we actively redirect the user to "Discussions" rather than issue and .... close the issue :). We found "GitHub Discussions" pretty useful and active, and more and more users are opening discussions rather than issues. This keeps the "issues" down to some "real" issues. * we have a triage team that virtually meets from time to time and actively reviews, classifies the issues (adds labels) but also runs some stats on which areas are "under-staffed". They meet semi-regularly and discuss and send some summaries. * we continuously encourage new users to contribute and add more committers especially in the areas that are "under-staffed" (recently UI committers "team" and "Kubernetes" team has greatly increased in capacity) and it immediately improved the situation there) * what helps there is that some of those committers are full-time employed or part-time paid as freelancers by important stakeholders in the project (Astronomer, Google). Also those stakeholders are fully aware of the value it brings, so they gladly pay the committers for their community effort, even if it is not directly responding to their needs (disclaimer - I am one of those freelancers that is part-time paid by the stakeholders) * the rule we have is that we do not need issues at all. People are encouraged (in the docs and workshops) to open directly PRs rather than issues * we added "Are you willing to submit PR?" question in the issue template. When the issue is relatively simple and the user says "yes" we assign the user to it. When the answer is missing - we actively ask the user if there is a will to submit the PR. More often than not, the users are willing to when encouraged (at least initially). * we mark the issues that are simple as "good-first-issue" which then lands in http://github.com/apache/airflow/contribute . More often than not we have people commenting "Hey I want to implement this, can you assign me?" which we do pretty immediately when they ask. That often works and we have new contributors :). * we have a "really quick to start" development environment for Airflow (Called Breeze) that we continuously improve and try to make easier to start contributing. Last but not least. We put a lot of effort into training, guiding and encouraging new contributors to contribute to Airflow: * we run semi-regular workshops for new contributors - we **just** started Airflow Summit 2021 yesterday and for example today we have the "first time contributor's workshop" https://airflowsummit.org/sessions/2021/workshop-contributing-apache-airflow/ - 3 hours hands-on when we teach the new contributors how to contribute. This is I think 5th or 6th time we do it (we have a few physical events and over last 1.5 year we had I think 4 online ones). This time we have 20 people who signed up - from literally all over the world (and BTW. all proceedings from that cheap 50 USD workshop go to Apache Software Foundation as donation). * yesterday was a "community" day at the Summit where we had three talks encouraging people to contribute: https://airflowsummit.org/sessions/2021/contributing-journey-becoming-leading-contributor/ - the road of Kaxil, the PMC of Airflow through committership https://airflowsummit.org/sessions/2021/contributing-first-steps/ - the first steps by a fresh contributor to Airlfow who shared his experiences https://airflowsummit.org/sessions/2021/dont-have-to-wait/ - "You don't have to wait for someone to fix it for you" - the talk from one of the committers to Airflow, Leah and her co-worker Rachel And we have quite few more talks for those who want to start contributing to Airflow: https://airflowsummit.org/sessions/2021/guide-airflow-architecture/ - The newcomer's guide to Airflow Architecture And finally, there are things we plan based on some upcoming features in GitHub: * we are eyeing very closely the new GitHub Issues introduced recently: https://github.blog/2021-06-23-introducing-new-github-issues/ . They seem to be much more developer-friendly and automation-friendly and they might help with better organizing/handling the issues. I am working with Github Issues Product Manager (we are going to have a meeting about it next week) to enable the new GitHub Issues for the whole Apache Software Foundation (I agreed that with Infra) and I hope very soon we will get it for all ASF projects (as an option to use) * we are waiting for Codespaces General Availability and our development environment is prepared to be used there out-of-the-box. This will make even easier path for new contributors to start contributing their code straight from the GitHub UI. https://github.com/features/codespaces. Sorry for such a long mail - this is basically a summary of ~ year of discussing and acting in this area. I hope some of those might be helpful :) J. On Thu, Jul 8, 2021 at 11:33 PM Christopher <ctubb...@apache.org> wrote: > Hi Erik, > > Do you have a good understanding of *why* there are more issues being > opened than being closed? If so, that might hint at some possible > solutions. > > For example, if you just don't have enough people to write code, then > the PMC could focus on inviting new committers to try to grow the > community, or mentoring new developers. > > If, on the other hand, the quality of the issues is poor, such that > they aren't very actionable, you could ask for more information from > the reporter, and add a label that shows its status, such as "waiting > on reporter". If no response is given in a reasonable time, you can > close old issues. You can also try to address issue quality using > GitHub issue templates: > > https://docs.github.com/en/communities/using-templates-to-encourage-us > eful-issues-and-pull-requests/configuring-issue-templates-for-your-rep > ository > > You could also set up something to auto-close very old issues that > haven't been updated in a long time, under the premise that they are > probably not relevant anymore. If they are, they can always be > re-opened. > > You can also use GitHub "projects" (which I see you're already using: > https://github.com/apache/superset/projects) to help organize related > tasks, so they can be closed when the overall project is done. > > If the problem is that your committers aren't paying attention to open > issues, you can try to ping your community's dev@ list to remind > people of how many issues are outstanding, as a way of encouraging > people to help triage, close, and bring down the number. You could try > to find other ways to "gamify" the count, too. But, ultimately, it > comes down to volunteer effort. > > If the problem is that your committers are having trouble tracking the > activity on GitHub, you can double check your mailing list > configuration to ensure activity gets copied to a notifications@ or > issues@ list that your committers can track (you can also configure > them to go to dev@, but that tends to get spammy and redundant, > especially for your committers who are happy seeing the notification > dots and/or emails directly from GitHub). > > Ultimately, you'll need to figure out why the situation is the way it > is, and address it accordingly. You won't be able to force volunteer > community members to participate to bring the number down, but perhaps > there's ways to encourage them, depending on why it's happening in the > first place. > > On Thu, Jul 8, 2021 at 5:04 PM Erik Ritter <erik.t.rit...@gmail.com> > wrote: > > > > Hi all, > > > > I'm a PMC member for Apache Superset, and we've recently been > > struggling with the number of issues reported in our Github repo. > > We're currently > at > > > 800 open issues, and are having trouble keeping up with responding > > and addressing all the user issues and feedback. We were curious if > > any other Apache projects had a way of managing Github issues that works > > for them. > We > > were considering setting up a bot that assigns new issues to a > > random committer/PMC member, but are open to other ideas too. Thanks > > for your > help > > and advice! > > > > Best, > > Erik Ritter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > > -- +48 660 796 129
