[GitHub] [comdev-site] rbowen commented on a change in pull request #32: Update gsoc.md
rbowen commented on a change in pull request #32: URL: https://github.com/apache/comdev-site/pull/32#discussion_r667166572 ## File path: source/gsoc.md ## @@ -133,18 +131,17 @@ more info about mentoring, please read our [guide to being a mentor](guide-to-be . Prospective mentors must join the ment...@community.apache.org mailing list, -this is where mentor specific issues are dealt with, and where -announcements will be made. If you want to track the program -administration you should subscribe to dev@community.apache.org. +this is where mentor specific-issues are dealt with, and where Review comment: I would think it's mentor-specific. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
RE: Issue Management in Apache Projects
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 Sent: Friday, July 9, 2021 12:51 PM To: dev 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
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:
