Re: Issue Management in Apache Projects

[Juan Pan <pa...@apache.org>]

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 <er...@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 <pa...@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 <de...@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 <ct...@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 <er...@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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org



--
+48 660 796 129


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org



--
+48 660 796 129



--
+48 660 796 129

Re: Issue Management in Apache Projects

[Jarek Potiuk <ja...@potiuk.com>]

Hello everyone,

After a similar discussion in users@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 <pa...@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 <pa...@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 <er...@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 <pa...@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 <de...@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 <ct...@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 <er...@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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
>
> --
> +48 660 796 129
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
>
> --
> +48 660 796 129
>
>
>
> --
> +48 660 796 129
>
>
>

Re: Issue Management in Apache Projects

[Juan Pan <pa...@apache.org>]

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 <pa...@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 <er...@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 <pa...@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 <de...@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 <ct...@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>
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 <er...@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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org



--
+48 660 796 129


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org



--
+48 660 796 129



--
+48 660 796 129

Re: Issue Management in Apache Projects

[Jarek Potiuk <ja...@potiuk.com>]

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 <pa...@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 <er...@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 <pa...@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 <de...@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 <ct...@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>
>> 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 <er...@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-unsubscribe@community.apache.org
>> For additional commands, e-mail: dev-help@community.apache.org
>>
>>
>>
>> --
>> +48 660 796 129
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>> For additional commands, e-mail: dev-help@community.apache.org
>>
>>
>>
>> --
>> +48 660 796 129
>>
>>
>>
>> --
>> +48 660 796 129
>>
>

Re: Issue Management in Apache Projects

[Jarek Potiuk <ja...@potiuk.com>]

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 <pa...@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 <er...@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 <pa...@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 <de...@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 <ct...@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>
> 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 <er...@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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
>
> --
> +48 660 796 129
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
>
> --
> +48 660 796 129
>
>
>
> --
> +48 660 796 129
>