search

corona-warn-app / cwa-wishlist

Central repository to collect community feature requests and improvements. The CWA development ends on May 31, 2023. You still can warn other users until April 30, 2023. More information:
https://coronawarn.app/en/faq/#ramp_down
Apache License 2.0
106 stars 14 forks source link

Using "Stale Bot" for issue management #830

Closed Ein-Tim closed 2 years ago

Ein-Tim commented 2 years ago

Current Implementation

Currently, especially in the wishlist but also in the documentation repository there are many very old issues which have no activity on them for a prolonged period of time (more than 6 months without any activity).

Suggested Enhancement

Use the GitHub App "Stale Bot" which a) asks if an issue is still relevant after a defined period of time / if this is still a reproducible problem b) closes issues if after the comment to check if the issue is still valid there are no other comments on the issue

Here's link to the bots page: https://github.com/marketplace/stale

Expected Benefits

Realistically nobody, neither from the team nor from the community has the time (or the will) to go through all open issues of the Corona-Warn-App organization (currently around 900 items).

To make the project board cleaner, using the GItHub App "Stale Bot" seems like a good solution for the following reasons:

  1. forgotten issues will be commented on automatically. Users who watch the respective repository are so reminded of the issue and can either
    1. do nothing - in this case the issue will be closed soon (nobody considers this issue as relevant)
    2. comment on the issue - in this case the bot will do nothing (somebody considers the issue as relevant)
  2. it doesn't do any harm, as it won't just close issues but comment on them before. It may well help to close some old, long forgotten items

Suggested configuration

# Number of days of inactivity before an issue becomes stale
daysUntilStale: 60
# Number of days of inactivity before a stale issue is closed
daysUntilClose: 14
# Issues with these labels will never be considered stale
exemptLabels:
  - ?
# Label to use when marking an issue as stale
staleLabel: stale
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment: >
  This issue has been automatically marked as stale because there was no activity on this issue for a prolonged period of
  time. It will be closed automatically if no further activity occurs in the next 14 days. Thank you for your contributions.
# Comment to post when closing a stale issue. Set to `false` to disable
closeComment: >
  This issue has been closed automatically as there was no activity on this issue for a prolonged period of time. 
  If you think this issue shouldn't be closed, please ping a member of the Corona-Warn-App Open Source-Team. 
  Thank you for your contributions.

Open questions

  1. If the issue was mirrored to JIRA, is it possible that another bot closes the corresponding JIRA ticket or comments on it to notify staff that the GitHub issue has been automatically closed?
  2. Do we want old issues to be closed? Or is it ok to have issues like https://github.com/corona-warn-app/cwa-wishlist/issues/165, where there was no activity for over one year?
  3. What do @svengabr, @dsarkar, @larswmh (Team), @MikeMcC399 & other community members think of this? Feel free to use this issue as place for discussion!

Additional information

Should we come to the decision that this should be implemented, I'd like to provide PRs!

Internal Tracking ID: EXPOSUREAPP-13312

svengabr commented 2 years ago

@Ein-Tim

That's an excellent idea, I will bring this up in our community management meeting.

Ein-Tim commented 2 years ago

@svengabr Thank you, I appreciate it!

svengabr commented 2 years ago

Internal Tracking ID: EXPOSUREAPP-13312

MikeMcC399 commented 2 years ago

If a stale bot is applied to old issues, then it is likely to increase the overhead of community moderators and I don't get the impression that there is any spare capacity for this type of task. Issue submitters will increase their activity if prompted by a bot, even if not all of them will react and they may need an answer or action from a community moderator based on this. Also, I don't think that there is any automated link in place between GitHub issues and Jira issues, so that could be another source of increased demand for community moderators.

How would you handle issues with label https://github.com/corona-warn-app/cwa-wishlist/labels/mirrored-to-jira which are obsolete, but still open? It seems like a bot will not solve this situation since it only takes action in GitHub, not in Jira.

For instance:

Let's say that the submitter agrees that the issue has been addressed, so then there would be a manual step necessary to also close the Jira issue.

I will test this on the above issue by placing a qualified comment in it.

Ein-Tim commented 2 years ago

If a stale bot is applied to old issues, then it is likely to increase the overhead of community moderators […]

May I ask why? The scenario is the following: An issue stays open for a prolonged period of time without any activity on it. After 9 moths the bot comments on: "This issue has been automatically marked as stale because there was no activity on this issue for a prolonged period of time. It will be closed automatically if no further activity occurs in the next 14 days. Thank you for your contributions."

Now there are two things that can happen:

  1. Nobody comments on the issue - it is automatically closed 14 days after the bot commented on it
  2. Somebody comments on it - The bot does not close the issue & removes the stale label

Where in this process are community moderators involved?

I understand your points reg. JIRA. This would probably demand manual interaction.

MikeMcC399 commented 2 years ago

@Ein-Tim

Where in this process are community moderators involved?

I'm guessing that if somebody comments on an issue, that the comment might need some moderator reply. That is just a gut feel. You will only find out if you implement the bot, so it might be a good idea to start on a simpler repository first to test the reaction.

Ein-Tim commented 2 years ago

@MikeMcC399

I see where you're coming from, maybe someone then asks what the status of this ticket is, etc.

You're suggestion to start enrolling the bot on a simpler repository sounds good to me.

svengabr commented 2 years ago

@Ein-Tim @MikeMcC399

We already had the internal discussion yesterday also in terms of possible overhead that might happen once we will use the stale bot. However, a final decision on our side was not made yet.

We also need to make sure we are fine from technical/legal standpoints this is why neither I nor my community management team can make any decision right now. We have to wait for final approval from the product owners.

I would expect a decision on this topic in the next few days.

MikeMcC399 commented 2 years ago

@svengabr

If the product owners decide to go ahead, I would suggest a much shorter number of days to declare an issue stale: something like 4 to 8 weeks, not 9 months. That's based on the current release schedule of once a month. I would factor in what the product release schedule is planned to look like for the future as well. I can only see 2.24 in the pipeline with no date so far visible and no visible version after 2.24.

svengabr commented 2 years ago

@MikeMcC399 Yes, I agree that 9 months is too long. I am also not sure at the moment if my cwa-bot that manages the project board will interfere with the behavior of the stale bot. We will have to figure something out if this gets approved.

svengabr commented 2 years ago

@MikeMcC399 @Ein-Tim The usage of the stale bot was rejected by the PO - at least for now.

The reason is that it's not nice to automatically close issues automatically and many people will not be happy if their issues will get closed for no other reason than elapsed time.

In the meantime, our community managers are working through many tickets at the moment that are already obsolete/completed on SAP side. Once we are finished cleaning up, we will address all the "stale" issues in SAP Jira and decide what will happen next.

MikeMcC399 commented 2 years ago

@svengabr It's good to see that you are updating the externally viewable issues with internal information. I agree that without this manual synchronization it would not make sense to try to add automatic closure to the process. Hopefully in the future of this project Jira and GitHub can be kept in sync in a timely way.

Ein-Tim commented 2 years ago

The reason is that it's not nice to automatically close issues automatically and many people will not be happy if their issues will get closed for no other reason than elapsed time.

I see where the PO is coming from, however, but does the PO think people are happier with proposing issues and they just lay around for 2 years? I don't think so. I agree that closing issues only because time elapsed makes no sense, but to come back to my example from the OP (https://github.com/corona-warn-app/cwa-wishlist/issues/165), I would at least expect some action in two years, either:

You & @larswmh are doing great work cleaning up the issue boards, I appreciate that very much!

Hopefully you find some way to automatically mirror JIRA status -> GitHub Issue!

Ein-Tim commented 2 years ago

Closing as not planned.