Page MenuHomePhabricator

Decrease issues created many years ago with no recent activity (aka stale tickets)
Open, LowestPublic

Description

Stale tickets/gerrit patches create unnecessary noise and confusion - particularly when the content relates to code or UI that no longer exists or has changed significantly. In many cases the owner/creator of the Gerrit/Phabricator ticket may have left the movement and are unlikely to ever act. Recently patches were raised on 5 year+ old tickets in one of my repos where patches were not welcomed wasting volunteer time.

Strawman proposal

  • Allow certain phabricator/gerrit maintainers to opt out before the bulk job
  • Define what a stale patchset/phab ticket is "e.g. has seen no activity in 2 years"
  • Comment on open and stale phabricator tickets requesting that an edit is made to the description to ensure the ticket is valid. If this doesn't happen the task will be declined or the patch abandoned.
  • Leave a grace period for action to be taken if necessary e.g. 1 month
  • Abandon open and stales patchsets/tickets where no activity occurs with a message pointing to this ticket. Make it clear that they can be reopened if necessary.

Result: More relevant and actionable Phabricator tickets.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 18 2020, 10:25 PM

The description specifies

Abandon open and stales patchsets/tickets where no activity occurs with a message pointing to this ticket. Make it clear that they can be reopened if necessary

I sometimes come across very old patches that are no longer relevant (eg relevant code has been refactored / removed, or task has been declined) but cannot abandon the patches (they aren't mine):

Only users in the following ldap groups can abandon others' patches, as far as I can tell:

  • VandalFighters
  • l10n-bot-watcher
  • mediawiki

Would it make sense for, eg, trusted-contributors to also be able to do this?

Define what a stale patchset/phab ticket is "e.g. has seen no activity in 2 years"

Should probably reopen T113706 (I do see a use case for this nowadays) and make it a subtask?

Aklapper added a comment.EditedMar 30 2020, 2:22 AM

Recently patches were raised on 5 year+ old tickets in one of my repos where patches were not welcomed wasting volunteer time.

I don't understand how this task would solve that problem. If a task should not get a fix then the task should be closed as declined.
Especially as this ticket later says "Make it clear that they can be reopened if necessary." (I guess the "necessary" is vague currently.)

Recently patches were raised on 5 year+ old tickets in one of my repos where patches were not welcomed wasting volunteer time.

I don't understand how this task would solve that problem. If a task should not get a fix then the task should be closed as declined.
Especially as this ticket later says "Make it clear that they can be reopened if necessary." (I guess the "necessary" is vague currently.)

Right now tasks that are feature requests or heated do not always get declined as there are no guidelines around when (or if) we can do it. The task in question was a hot potato in 2013 that certain people wanted fixed but others didnt but since then passions had fizzled out.

As a result the task got a flurry of patches in 2020. This activity led to the forgotten task eventually getting declined but at the expense of wasted effort.

specially as this ticket later says "Make it clear that they can be reopened if necessary." (I guess the "necessary" is vague currently.)

Wording to be decided. For instance if a bug has outdated replication steps rewriting/reframing a description seems like a valuable thing to do as it shows someone is still around that cares about it, and this activity would prevent it being declined. However if nobody is engaging with a bug and willing to say "this is a problem" it's likely not a problem or a good use of time.

We don't do enough work triaging tasks/giving tasks love as a movement and could be more proactive. We throw tasks over the fence and they are there 5+ years later for whoever is still around.

I think I am still wondering which actual underlying problem to solve by this proposal/solution, apart from folks working on stuff they should not work on.
(And Gerrit is a whole different topic, hence ignoring Gerrit.)

Recently patches were raised on 5 year+ old tickets in one of my repos where patches were not welcomed wasting volunteer time.

I don't understand how this task would solve that problem. If a task should not get a fix then the task should be closed as declined.

Right now tasks that are feature requests or heated do not always get declined as there are no guidelines around when (or if) we can do it.

There are guidelines: A report is given the Declined status when (...) there's a consensus that implementing a particular bug report or feature request would be a bad idea. For example, when a report contradicts a particular project's scope or the principles of the project and fixing would be barred from approval by the project's Developers/Maintainers (or product managers, if existing). (...)
(In addition I just made some smaller edits to that page to hopefully make a few things clearer.)

The task in question was a hot potato in 2013 that certain people wanted fixed but others didnt but since then passions had fizzled out.

As a result the task got a flurry of patches in 2020. This activity led to the forgotten task eventually getting declined but at the expense of wasted effort.

That is unfortunate, however https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews has a section "Check beforehand if it is in scope".
That's the eventualism that someone might show up at some point, when tasks which are not a good idea or out of scope are left open and ignored instead of getting declined. I'd expect teams/PMs/maintainers to sweep the backlog (plus divide and conquer if needed). Ignoring hot potatoes is not a solution and then mechanically mass-closing such tasks is not a solution at all, to the contrary.

For instance if a bug has outdated replication steps rewriting/reframing a description seems like a valuable thing to do as it shows someone is still around that cares about it, and this activity would prevent it being declined.

Anyone can retriage, ask the task author for updated reproduction steps, set the task status to stalled, and ask the task author to reset the task status once information has been provided. I don't really see why a potentially valid task should be declined; I can see though and would agree that there should be periodical checks if a bug (not: feature request) is still an issue and if there is no reply within a certain timeframe the task could be declined.

We don't do enough work triaging tasks/giving tasks love as a movement and could be more proactive. We throw tasks over the fence and they are there 5+ years later for whoever is still around.

That sounds normal to me and not like an issue per-se. Plus the number of open tickets increases over time if no maintainer declines tasks based on project scope.

All in all: Tasks should receive lowest priority when patches would get accepted. Workboards for a code project can be sorted and filtered accordingly. Teams should not add a task to their team workboard if the team will not and should not work on a task. Things should be resolved when they are done. Tasks should be declined if they are out of scope for a code base. Stealing a sentence from a co-worker, "Closing things because they are 'stale' is just hiding the desired feature from the world and hoping that someone will think of the same thing again."
That last sentence makes me want to decline this ticket in its current broad scope, as automatically mass-closing older open tickets is not a solution as the solution should have been to decline the ticket earlier which led to the creation of this very task. There are some specific aspects I'd agree with though, e.g. finding a concept to close tickets with the status stalled after a while, if that status has been used correctly. Filed T252522.

I think I am still wondering which actual underlying problem to solve by this proposal/solution, apart from folks working on stuff they should not work on.

With regards to Gerrit patches, for me it ensures people that are still wanting review get it. There is so much clutter in Gerrit, tbh that I (and I'm sure others) ignore a whole host of stuff older than a month. If it was more widely accepted that open = i need review, I would be much more likely to review and it would be much easier to pair volunteers with reviews.

Right now I'm sure a bunch of people give up with our movement since they can't find someone to review their patch.

With regards to Phabricator tickets, there are so many of them, if a volunteer asks me for direction on what to work with, it's really hard to determine which "good first bugs" to recommend as I have to consider 5 years worth of history. Many of those I'm sure are important but it's hard to determine their importance the longer they stay open if that's the normal for all bugs. From my own experience many of the 4+ year bugs are only left open to avoid hurt feelings, which is disingenuous to everyone involved. I think your recent activity of unstalling bugs has been good for reducing some of that clutter. Regularly checking in on tasks and how people feel about them is important. There are many bugs I cared passionately about that I don't care about anymore or have lost interest in, while many are equally if not more important.

Gerrit

With regards to Gerrit patches, for me it ensures people that are still wanting review get it.

To me that sounds more like a data filtering problem then a data problem but maybe I'm wrong (see below).

There is so much clutter in Gerrit, tbh that I (and I'm sure others) ignore a whole host of stuff older than a month. If it was more widely accepted that open = i need review, I would be much more likely to review and it would be much easier to pair volunteers with reviews.

@Jdlrobson: What is your personal or team's workflow then? Do you use the Gerrit web frontend? Do you divide and conquer by filtering on something like status:open AND label:Verified>=0 AND -label:Verified<0 AND label:Code-Review>=0 AND -label:Code-Review<0 (no changesets which have a -1 or -2), or how does the clutter show exactly and gets in your way?
(Surely T113706: Define Cut-off date for abandoning old changesets in our code review tool could be an option to cut backlog size by age, but I'd first like to understand why not once clean up those items in the backlog which are not -1 or -2, instead of going for ignoring it by mass-closing?)

Regarding the team, do you use a custom dashboard to divide and conquer? (If yes I'd love to have the link.)

Right now I'm sure a bunch of people give up with our movement since they can't find someone to review their patch.

Indeed, and that's Code-Review-Workgroup territory and mostly about workflows, dashboards, and filtering data. In my understanding.

Phab

With regards to Phabricator tickets, there are so many of them, if a volunteer asks me for direction on what to work with, it's really hard to determine which "good first bugs" to recommend as I have to consider 5 years worth of history.

I'd simply point folks to https://www.mediawiki.org/wiki/Good_first_bugs which has its Phab query links display open tasks with recent priority first?
(Part of the problem is also that many people tag tasks as good first task though the task does not have sufficient information for a newcomer. We've been watching latest tag additions a bit more and removing good first task more aggressively lately from tasks which lack enough info (as such tagging makes the tag less useful).)
Personally I also sometimes wondered about somehow automatically removing the good first task tag after a certain time frame (tbd).

Many of those I'm sure are important but it's hard to determine their importance the longer they stay open if that's the normal for all bugs.

IMO that's what the Priority field is for. The less important and urgent, the lower the priority should be.
I'd expect PMs to realistically prioritize tickets (in my understanding that means that the vast majority should be "low"/"lowest", not "medium" or higher).

From my own experience many of the 4+ year bugs are only left open to avoid hurt feelings, which is disingenuous to everyone involved.

I'd also expect PMs to decline tickets when implementing would be a bad idea and when they are out of scope for the code project (not: "out of scope for the engineering team", because that translates to "open and a low/lowest priority, feel free to provide a patch if you want to see this implemented").
For hurt feelings, the cruel reality is documented on https://www.mediawiki.org/wiki/Bug_management/Development_prioritization and can be linked to.

I think your recent activity of unstalling bugs has been good for reducing some of that clutter. Regularly checking in on tasks and how people feel about them is important.

Thanks. It's complicated (T252522) but I hope in the long run to get there. Same with cookie-licking.

There are many bugs I cared passionately about that I don't care about anymore or have lost interest in, while many are equally if not more important.

:-/

IMO that's what the Priority field is for. The less important and urgent, the lower the priority should be.

Priorities change however. Right now there's a bunch of tasks that have been marked as low as they don't fit in with the current project of the team, however when that team finishes some of these would actually become high.

Because teams have been trained to ignore low/lowest because of the fact there are so many of them, means the onus on remembering to change these priorities falls on the the priority setter.

@Jdlrobson: What is your personal or team's workflow then? Do you use the Gerrit web frontend? Do you divide and conquer by filtering on something like status:open AND label:Verified>=0 AND -label:Verified<0 AND label:Code-Review>=0 AND -label:Code-Review<0 (no changesets which have a -1 or -2), or how does the clutter show exactly and gets in your way?

Everyone deals with it differently, but from a reading web perspective, anything marked as low is currently filtered out ignored. I have made a case several times to show low but the response has always been "there are too many low" tickets. When I review these, my assessment is they have been kept open because of a heated discussion that happened say 3 years ago and everybody is scared to touch it.

I have a personal gerrit dashboard that shows patches assigned to me and by me. I often miss patches as this relies on me keeping on top of emails and assigning myself to ones I will care about. My workflow is not perfect. I care about various projects, but the core and Vector boards are useless for example due to lots of open patches, many of which will never be merged, even when you exclude WIP.

I'd also expect PMs to decline tickets when implementing would be a bad idea and when they are out of scope for the code project

I don't think this always happens. Right now declining requires a certain level of bravery because we are an open source project and nobody owns the code and at least I know of various people who are scared of the social implications of closing/abandoning tickets. I believe establishing some accepted norms for declining this would lead to this happening more often and this is at the crux of my proposal.

Github has solved this issue IMO with the stale bot - https://github.com/apps/stale - I think this is something we could follow. It's even more aggressive on many projects - sometimes closing tickets after months. I'm not advocating for that - I'm just advocating for several years :).

There's no point in caring about a bug from 5 years ago if nobody is around to care about it any more. If someone does care - great - keep it open and reassess the conversation. I reckon lots of phabricator tickets and Gerrit patches fall into this category. For example I know of various ex-WMF staff who still have open patchsets and have not contributed since they left.

Reedy renamed this task from Decrease issues created many years ago with no recent activity (aka stale tickets) to Decrease issues created many years ago with no recent activity (aka stale tickets).Jun 16 2020, 7:20 PM
Dzahn added a subscriber: Dzahn.Jun 16 2020, 7:42 PM

There's no point in caring about a bug from 5 years ago if nobody is around to care about it any more. If someone does care - great - keep it open and reassess the conversation.

Many of these 5 year old tickets have people caring about them (in most cases the reporter of the issue) but nobody who can solve it (for example because the reporter can't merge code changes).

Imagine reporting a bug, waiting for 5 years and then having a bot automatically close it with the sole reason that it is "stale". That would be extremely frustrating.

Please let's not do that. I can only support "Closing things because they are 'stale' is just hiding the desired feature from the world and hoping that someone will think of the same thing again." as much as possible.

As Andre said above he issue described here seems like an issue how to filter data and use work boards. Closing tickets because we have too many tickets does not seem a solution to me.

Jdlrobson added a comment.EditedJun 16 2020, 7:52 PM

Imagine reporting a bug, waiting for 5 years and then having a bot automatically close it with the sole reason that it is "stale". That would be extremely frustrating.

Please re-read what I've proposed. It wouldn't automatically close it. It would ask if people are still looking at it and if they were it would keep it open.

As Andre said above he issue described here seems like an issue how to filter data and use work boards

Please also respect my experience is different to you. I am telling you there is a problem with stale tickets and gerrit patches in my repos and that filters cannot solve that problem.

Many of these 5 year old tickets have people caring about them (in most cases the reporter of the issue) but nobody who can solve it (for example because the reporter can't merge code changes).

That sounds like a different problem in the Code-Stewardship-Reviews arena. I am talking about tickets where nobody is ever planning to fix those things.

Dzahn added a comment.Jun 26 2020, 2:12 AM

Please re-read what I've proposed. It wouldn't automatically close it. It would ask if people are still looking at it and if they were it would keep it open.

Done! That sounds better. I clearly didn't read it right. Sorry.

Please also respect my experience is different to you. I am telling you there is a problem with stale tickets and gerrit patches in my repos and that filters cannot solve that problem.

Of course i respect your experience is different. Just wanted to share mine. I apologize if it sounded different. ❤️

Maybe it could be different for different tags.

hey @Dzahn apologies, I was overly sensitive that week. I think the main thing I'm getting at is in some parts of the codebase there is an overwhelming amount of task and patches and some automation would help with that.

Right now every time I get a spare cycle I go around old patches and tasks every now and again and ask if it's still being worked on/if the bug still exists and if I don't get a reply in say a month, I'll abandon it with a kind note that they can restore it at any point as otherwise it's just going to sit there forever. If people are still seeking review I try and help them out. I think this could be automated. I don't think it would be necessary for every project.

Aklapper triaged this task as Lowest priority.Oct 7 2020, 7:31 AM