Hello everyone, After a similar discussion in us...@infra.apache.org I was asked if I can share the experiences - I restructured my answers a bit and created a page in the "builds" confluence space. I also updated based on the experience over last few weeks and since the discussion was mainly about "migration" experience, it has also a chapter on how we migrated to GitHub Issues from JIRA, If anyone wants to make use of it, or correct/update - add their own experiences - feel free:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632 J. On Thu, Sep 2, 2021 at 11:09 AM Juan Pan <panj...@apache.org> wrote: > Hi Jarek, > > > Thanks for your detailed wonderful experience! > What you said triggered me to become interested in airflow community. > > > > GitHub implemented this great feature that you can convert an issue into > a discussion and discussion into issue any time. > > > Agree with you. ;-) > > > > > ------------------------------------------------------------------------------ > Juan Pan(Trista), Apache member, Apache ShardingSphere PMC, Apache brpc > (Incubator) & Apache AGE (Incubator) mentor > Twitter, @trista86934690 > > > > On 09/1/2021 16:34，Jarek Potiuk<ja...@potiuk.com> wrote： > correction: " likely external (deployment/networking issue) rather than a > product bug/feature" > > On Wed, Sep 1, 2021 at 10:33 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > The current approach of mine is - if the issue is likely external > (deployment/networking issue) a product bug/feature, or if there are no > reproducible steps - it's a discussion. > > The "likely" part is important I think (and that's how I approach it at > least) - is that if i am not 100% sure or lack of information I always > mention that this is a guess and unless more information is provided, we > will treat it as discussion (I believe lack of reproducible steps is pretty > much always a "discussion" by default). > > Previously I was closing such issues (but that was a bit too "strong") and > might put-off some people. But recently GitHub implemented this great > feature that you can convert an issue into a discussion and discussion into > issue any time. This is a great feature, I think. Discussions can remain > open forever if the user will not provide more information (hey, they are > discussions!) and they are not "firm closed" either. > > I think Discussions went a long way for us in Airflow - we started using > them pretty much immediately after they were introduced several months ago > (we like to try new things!) and initially they had very little "uptake". > But this changed over time, people started to use them when we kept > answering there and even started to mark things as "answered" (which is > akin to Stack Overflow). Also after we introduced the template which is a > bit annoying to fill-in (you have to pick version, get the operating system > information etc. etc. as required fields) and we added direct links to "if > you have no reproducible step [OPEN DISCUSSION]", I already noticed that > people are opening more discussions than issues resulting from deleting the > template and entering free question/general rambling, > > I think the important thing is that we treat discussions seriously, and > engage with users and discussions are not left "unattended". On the other > hand it's perfectly ok for us to ask for more information etc. and forget > completely and immediately about an open discussion. Unless the author or > other user comes back with more information that is - it's perfectly ok for > a discussion to "die-out", it's not ok for an issue to do so. > > J. > > > On Wed, Sep 1, 2021 at 9:37 AM Juan Pan <panj...@apache.org> wrote: > > Hi fellows, > > > Thanks for your sharing, ShardingSphere community is still using GitHub > template and triaging issues with labels by our committers. > I still found recently many communities opened discussion section on > GitHub. I wonder how to leverage Issue and discussion section together? > Which questions belong to Discussion section and which ones are supposed to > put in Issue section? > Look forward to your experience and ideas. > > > Best wishes, > Trista > > > > > ------------------------------------------------------------------------------ > Juan Pan(Trista), Apache member, Apache ShardingSphere PMC, Apache brpc > (Incubator) & Apache AGE (Incubator) mentor > Twitter, @trista86934690 > > > > On 08/29/2021 00:46，Jarek Potiuk<ja...@potiuk.com> wrote： > Some update from the most recent attempt of Apache Airflow to improve our > issue handling using some "new-ish" features available in GitHub: Issue > Forms and GitHub Discussions. > > TL;DR; We don not have yet results but we think in Airflow making the full > use of GitHub Form Templates and endorsing the use of GitHub Discussions > where appropriate (and at the issue entry time), should help us a lot by > "gating" issues better, improving their quality and getting our users into > "pre-clasifying" the issues (or indeed using Discussions where it is a > better choice). > > *Problems we observed:* > > * with the standard MARKDOWN templates we have many issues where people > did > not provide useful information (version of airflow, operating system etc.) > * we had a number of issues where users would simply delete the markdown > template content straight away and replaced with their own issue > description - without "reproducible steps", or really to ask a question > about their deployment problems without even trying to attempt to > investigate it. > We've ended up with many "discussion" kind of question posted as issues. > Then we would "convert" such issues into discussion but it required > maintainers comment and explanation. Mostly it was because the users did > not even know they can (and should) open a discussion instead. > * the markdown templates were difficult to read/fill in - it was not clear > what you should do with the parts which were relevant - we left > instructions in the comments, which were sometimes left/sometimes deleted, > generally the issues were "structur-ish" rather than "structured". > * often people opened Airflow 1.10 issues even if it reached End-Of-Life > in > June (they should open discussions instead - which is still great because > even if there are no way we will handle the issues but either us or other > users can help them still for workaround or even directing t) > > *Discovery* > > Then we discovered that we already can use "Forms for GitHub Issues" (beta > feature but it is available for everyone now - > > > https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms > ). > This looked like not only a great way to structure and pre-classify the > issues (by the users) but also seems to be a great communication tool with > the users. We believe it will allow us to address most of the issues > above. > Basically instead of committers having to explain the rules over and over > and instruct the users how they should report the issues - it's all there > explained really clearly and nicely while the user enters the issue. > > *Solution* > > We defined forms with required fields that cannot be "skipped". also when > you do not fill a "textarea" entry it is marked as "Not Provided" rather > than deleted. We added helpful comments and hints as well as explanation > in > which cases you should use GitHub Discussions (including lack of ability > to > select 1.10 version and link to open GitHub Discussions) instead of issues > (with direct link). We've added logo and welcoming message to "soften" the > "more formalized form entry need. We made it clear that if there is no > reproduction steps, the users should open GitHub Discussion instead. We've > added more issue types - we've separated "Airflow Core", "Airflow > Providers" (we have more than 70 providers that extend Airflow's > capabilities) and "Airflow Docs" issues - automatically applying correct > labels, so we do not have to do triage ourselves. We also created a > "maintainer only" issue type with allows to enter pretty much free-form > information (for tasks/todos etc.) and we've added a required "checkbox" > to > confirm you are maintainer, to discourage people from using it to raise > their "free form" questions there. We wanted it to be "easy" for > committers > to enter such "free form" issue but "not easy" to skip structured > information by the users - at the same time guiding them to use > "Discussions" which are much "easier" to enter any content and ask > questions. > > What is even more - this structured form will allow us to automate some > stuff if we find it is needed. For example if someone submits an entry > without providing "reproduction steps" we can write a bot to automatically > convert such issue into discussion. Or automatically close an issue if > someone opens a "free-form" one while not being maintainer. > > *Demo/Take a look yourselves* > > You can try it yourself here: > https://github.com/apache/airflow/issues/new/choose > > And see some screenshots how our issue form entries looks like: > > - https://ibb.co/Lxgx7xn > - https://ibb.co/0rYqm1Q > - https://ibb.co/fX45nBB > - https://ibb.co/dbTR9GV > > PR introducing it is here: https://github.com/apache/airflow/pull/17855 > > We really hope it will drive the issue quality up and issue number down > eventually. > > J. > > > On Thu, Jul 15, 2021 at 5:17 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > Good luck :). > > On Thu, Jul 15, 2021 at 3:53 PM Erik Ritter <erik...@apache.org> wrote: > > Thank you all for the great advice and thoughts! I see a lot of alignment > between items suggested here and things we've tried or thought about. > > Being proactive about closing issues against old versions of Superset is > definitely something we want to do, but haven't gone through and done a > mass issue closing yet. That could certainly help cull the issue count. > > We have set up some bots on github to close stale issues, but their > timeline is probably too long (I think we wait 3 or even 6 months before > closing a stale issue). Setting a more aggressive timeline for closing > feels like a reasonable approach. > > A lot of the issues we see seem to be legitimate bugs/issues with the > product, but Superset has such a large surface area (supporting dozens of > database query engines) that many committers don't have the time or > ability > to replicate someone's environment to truly repro an issue. I'd imagine > making it easier for new contributors to set up a dev environment and test > with their own data could help solve this issue. Our new developer > onboarding docs/workflow is somewhat lacking, but enabling more community > members to resolve issues could provide the incentives to improve it. > > Finally, I do think we have an issue with committers/PMC members paying > attention to issues filed, probably because Github email spam is all too > common, and we pretty much all have jobs that touch more than only > Superset. As mentioned, assigning work isn't really possible for an open > source Apache project, but I would hope that we could improve the triaging > rate of issues at least. Perhaps gamifying in some way, or creating a > volunteer group to do a bi-weekly or monthly triage session could help us > start to get some control over the issues filed. > > Thanks again for all the great advice, and I'm glad to know it's not only > us having these issues. We've got some plans in the works to improve this > state, and hopefully in a few months I can follow up on this thread with a > success story! > > Erik > > On 2021/07/09 12:01:06, Paul Angus <p...@angus.uk.com.INVALID> wrote: > 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 > <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-rep> > < > https://docs.github.com/en/communities/using-templates-to-encourage-useful-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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > > > > -- > +48 660 796 129 > > > > -- > +48 660 796 129 > > >
