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?

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.)

In T248034#6009026, @Aklapper wrote:

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.)

In T248034#6010538, @Jdlrobson wrote:

In T248034#6009026, @Aklapper wrote:

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

In T248034#6149152, @Jdlrobson wrote:

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.

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.

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.

In T248034#6229537, @Jdlrobson wrote:

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.

To me the elephants in the room are ownership, workflows and capacity: When I worked in a corporate environment with clearly defined and restricted resources and roles who makes decisions, it made sense to me that tickets got mass-closed as "wontfix" after a sprint/program/project had been finished or canceled. In that place, some people had the job of looking at new tickets for some codebase and deciding whether to put that ticket also into the team backlog, or not.

Regarding the status quo only, from a team perspective I'd recommend to use the "low" priority value instead of avoiding it, not pulling each and every ticket in some codebase automatically via Herald into a huge team workboard (cf. T271911) with an unmaintainable backlog, and/or potentially filtering workboards not to display low priority tasks, and a team regularly looking at latest-only tickets in 'their' codebase project tags to decide which few tickets to add to their team workboard (and which many tickets to ignore as a team) and which tickets to decline because they are bad ideas (and not because of lack of resources).

In an open environment, anyone is free not to care about a ticket created five years ago, and anyone else is also free to care. Plus if someone (still) cared about a ticket created many years ago, then reopening the ticket would be cheap. This is exactly the conflict between the idea(l)s of eventualism (someone might show up after some decades and implement/fix a ticket) versus immediatism, and I'd dare to say that our movement has sometimes too much eventualism around.

Today I looked a bit at GitLab's Triage policy concept: https://gitlab.com/gitlab-org/gitlab-triage
GitLab (the company/product)'s documentation for themselves says they run it once a day and it's heavily based on labels (equivalent in Phab would be project tags). Their triage policies for themselves can be seen here.

The interesting challenge, as already mentioned by Jon in the task description here, is defining criteria.

• Should feature requests have different criteria than bug reports?
• After a lack of which exact actions to consider a ticket 'stale'? And which actions do not imply "activity"?
  • For the records, the most common task "transaction types" (basically: changes to a task) in Phab in the last six months were: core:comment, core:edge, core:subscribers, core:columns, description, title, core:customfield, core:create, core:view-policy, core:edit-policy, core:space, reassign, status, priority, unblock, parent, core:subtype, points, token:give, mergedinto, mergedfrom, cover-image, core:mfa.
• (and probably some more questions)

Looking at some examples of triage policies, I've seen things like "no activity in 18 months, no milestone scheduled, no 'Stretch' or 'Deliverable' label" or "needinfo label for a month", or "feature label, no activity in 12 months, no Stretch or Deliverable label, no merge request provided" from my very quick and limited look at it.

Quoting from GitLab's concept at https://about.gitlab.com/handbook/engineering/quality/triage-operations/#auto-close-inactive-bugs :

Tasks marked as bugs (not: enhancement or feature requests) without activity for 12 months (see my comment above on defining the vague term "activity") automatically receive a ~stale label and a "Comment by GitLab Bot to the author to check whether the reported bug still persists and to comment accordingly within the next 7 days" (which feels like a very short time frame to me).

After seven days, if no comment happened, their status is changed to closed with an additional ~auto-closed label added.

After seven days, if a comment happened, the ~stale label gets removed.

I suspect "stale" will vary per team, this it's important this is configurable and opt-in given the feedback from other teams/users as I recognize not everybody would want/make use of this.

For my own products, where I would make use of this, I would benefit from having reminders on tickets that have not had activity for over a year. I'm optimistic this wouldn't lead to bugs being closed, but rather the opposite - helping us prioritize the stuff that matters. My experience of using stalebot in Github is when you threaten to close something, you get a lot of feedback when that thing is important and that leads to it getting better prioritized.

Implementation-wise, I think we'd do the following:

1. Opt-in Herald-like rule like so:
2. "If task has tag:<team tag>, AND task open > 12 months (configurable per team)

THEN add "Stale" tag to the phabricator ticket, and add comment "Please remove stale tag within the next month if this ticket is still relevant, otherwise it will be closed due to inactivity"

2. Weekly basis: check for phabricator tickets with stale tag AND last updated < 1 month THEN delete.

In T248034#7032036, @Aklapper wrote:

To me the elephants in the room are ownership, workflows and capacity...
In an open environment, anyone is free not to care about a ticket created five years ago, and anyone else is also free to care....

Stakeholders are important (speaking to ownership). Closing old tasks just because they aren't new (or other arbitrary criteria as suggested in description) is upsetting for people who aren't sufficiently technical to close the task themselves by committing a change to the software. We are in an open environment, not a closed one, and "we will never fix this" is rarely the right response ("we don't have the people to do this [right now]" is absolutely fine, and that's indicated by 'low' or as I suggested on the linked task "Backlog that the team has deprioritized" columns [not freezer columns]).

Asking whether people care is one way to assess whether someone cares, but people may care and simply not know or be watching the task of interest. So then we get into a cycle of (if you know to look for closed tasks - I expect most stakeholders' default working modes to be "open represents the total set of issues or feature requests"): "report it (again) -> oh it was closed before -> because no-one could work on it???" and similar other reactions. Closing and reopening is one way to deal with this, but so is leaving it open.

Regarding the status quo only...

These seem like the right direction generally. Let's try that.

Tasks where the patches are ancient

I think it might be reasonable to abandon old patches, especially ones that won't merge today without a conflict. The people sufficiently technical to submit the patch in the first place will presumably get an email that their patch was abandoned with rationale. Maybe this is something that could be be done automatically once a year, coinciding roughly with start/end of WMF fiscal?

Bugs that are old

These should be tested and reevaluated, not necessarily presumed to be gone or still-present, or given a sufficiently technical reader, inspected by reviewing source.

Feature requests that are old

Well, if they aren't worked on, they're rarely going to magick themselves away. We have tasks from the early 2000s still that would be closed under the above suggestion (or otherwise cause a flurry of comments of various temperament - 'how dare you' to 'well, that's a dumb message') that are either hard technically or socially.

Some other old thing

More likely these are more like feature requests and should generally remain open.

I know of various people who are scared of the social implications of closing/abandoning tickets.

I honestly think they should be, because that is probably at least one reporter-contributor who won't use Phabricator again... out of disgust or disappointment.

Bot

I don't think this is right place for a bot that does anything more than tag stale things as stale. (Which I guess makes it easier to filter out than setting date stamps.) If there's value to it, it's "removes team tag" (which I presume is not a component tag).

("we don't have the people to do this [right now]"

No - we won't have these resources ever, I'd dare to say. (If you know any FOSS projects that have more resources than requests to handle, please share.)

These should be tested and reevaluated, not necessarily presumed to be gone or still-present

This "should" ideal requires volunteer resources that we do not have and will not have in a foreseeable future. I'm more interested in feasible, realistic actions.

I honestly think they should be, because that is probably at least one reporter-contributor who won't use Phabricator again... out of disgust or disappointment.

I'd prefer instead to accept that you will always disappoint somebody. Every piece of software has some scope.

feasible

The proposed path "leave a note -> no activity and close" would be overwhelming to try to keep up on tasks that matter for volunteers and WMF developers alike. On any repeated basis. And once a task dies, no-one is going to find it. If it manages not to die the first go-around, the cycle repeats until either the volunteer who knows That Task is a problem or the developer or project manager on the team who cared about That Task moves to another team. And that's ignoring internal reorganization above and beyond the casual movement of engineers from group A to B. Even if none of that happens and you end up with the happy case, at that point you're adding spam "does it still matter" "yes of course it still matters" on for potentially years until someone comes to talk to the bugmeister about the fact a task has been up for questioning 10 times in 10 years. That's all assuming that that person isn't already gone and has stopped caring....

You have a large community of non-technical volunteers that can and will be summoned at the drop of a hat when they find out that tasks that matter to them whether they know it or not are being systematically closed by a thoughtless bot. This community of non-technical volunteers is quite unlike every other FOSS project. Those people receiving work from an FOSS project take what they can get (or stop using the product I guess; c.f. Firefox Quantum loss of XUL scripting). This community complains, loudly. It's also really easy to get them riled up over automation. Some won't participate in that protest out of disgust or disappointment. But there are a lot more who will come down on whoever they can find, whether that's the now-absent CEO, the VP of tech, and on down to the bugmeister himself (you). Did you see the reaction over THEYCANTHEARYOU (mobile talk page communication)? And that was a half dozen tasks that have been dormant for years, some of which I can only assume would have been closed for inactivity under this policy. (Subsequently, accusations of ineptitude at the WMF I am sure.)

That's not fair or fun for anyone. And it's a situation where no-one comes out ahead, and probably ends up in front of whatever future enforcement group of UCOC there is, and certainly in front of the same for the technical community that exists today. Were you planning to announce that this was going to be done? To whom? What do you think the reaction to that announcement is going to be? If you expand the group of people you were planning to email (I assume wikitech-l or MediaWiki-l, but maybe your plan was even more limited than that) to the non-technical, what do you think that reaction is going to be? What about if there's at least one or two somewhat technical persons to explain in basically whatever terms they please to that community the implications of however you word that email or Tech News post?

what is feasible

I agreed about some things that are feasible: "let's try that". But just in case (in no particular order and with only so much consideration on my part ;):

• Mark all inactive tasks with an "auto-old" tag and make the automated comment as such (without threat of closure). That's unobtrusive, trivially filtered out in Phabricator, and also gets to the same end goal of asking whether the task is still relevant. Possible extensions:
  • The bot removes the tag if anyone responds. (Issues remain here about bot spam.)
  • The bot manages the workboard of tasks in "old" by age of staleness from time start.
• Move such tasks on team work boards to a team-setup stale column.
• Remove "team" tags ("Reading" et al.) from stale tasks.
• Stop auto-adding teams to new tasks in any given component. Tasks will accumulate in component backlogs regardless; if a team should somehow find they ran out of work, the newest tasks in that backlog will be prominently displayed at the top of the query or column (by default). Have a person watching the components of interest for new tasks after each deploy for bugs that crop up and decide at point of entry whether it's in scope for current work, later work, or never by that WMF team.
• If Herald should continue to auto-add team tags, project teams can and should triage those at that time. They have authority over what goes into their project tag bucket and I doubt anyone will say otherwise.
• (Re-)Add a severity assessment or tag to tasks (and/xor bugs). This got dropped when we moved from Bugzilla but it can be a good mechanism for finding issues to resolve. (I might lean to having a tag for it so that not all tasks need an assessment of it, but YMMV.)
• Abandon stale patches. These already have the right mechanisms in place, with both visibility to the original patch submitter and the tasks they're attached to, that you could go ahead and just abandon the ones that haven't seen movement in a while. (I have personally been annoyed by the uselessness of Patch-For-Review as an indicator that there is a "patch in the queue".)
  • Perhaps add an #auto-abandoned-patch tag in conjunction so if someone wants to find and start from prior work in whatever state, they can. This tag would be unmanaged.
• Tag tasks as good first task or patch-welcome more at point of triage. You can't know who or why or when will be drawn in. For example, the sole task I've submitted a patch for was almost a year old when I did so. The task was trivial. No-one saw that it was, even though that particular component has a stewarding team. (The point of this task being that there's too much Stuff out there to wade through, I won't complain about the fact no one has actually stewarded the component in question in any meaningful sense since its creation, even though I try to at least triage stuff when it shows up. ;)

A particular case of lost work

I want to speak to a specific rationale some more since I don't think I said what I really meant to: "We're scared of closing a task that had a disagreement 3 years ago." Fundamentally, someone needs to take ownership of that disagreement and lay out the ways the task can proceed. I have a task in mind that I felt very frustrated with that was almost exactly "we lost some work from a volunteer" that would have improved* the software (for some value of improvement), yet never was there identified/agreement from the singular person who -2d the patch and declined the task what could have been done to take that work and run with it. Specifically, what the requirements were that the innocent volunteer who submitted the patch didn't know about (heck, which no-one on the task prior to the -2 knew or thought about). Subsequently the task was reopened. I expect many such "we had a disagreement 3 years ago" tasks are of this sort, waiting for the unstated requirements or getting consensus to Invalid/Decline or adding patch-welcome as WMDE is willing to do or even just removing the component tag and adding MediaWiki-extension-requests (because MediaWiki has a rich extension environment and if someone wants a WMF-maintained extension to do more, that is another option for them).

(When I pointed out the stonewall and the fact a separate team had wandered onto the minefield 4 years later shouldn't have had to deal with it, I'm the one that got reprimanded [in public]. By you [Aklapper]. Can you tell I'm still bitter? 🙂 That task remains open another year later, btw, if you want to talk about that off-Phab/off-task.)

If indeed there are problems getting stuff closed invalid/declined, that's not solved by a bot. That's solved by spending time (which I agree, is thin) figuring out each specific task's requirements and whether those requirements are in scope for the component. And/or, it's solved by working out a functioning process for deciding contested tasks. Because I agree that's been a hole in how this tracker has worked for years.

prioritization

If you want an actual sense of prioritization on a project by project basis, do what CommTech does and run a vote once a year (and which the Tech side did once?). Invite participation rather than assume the opinions don't exist as a default. Say, "Reading is working to prioritize its tasking for this year. These are the overall objectives (which we don't get to set?), and here's some set of tasks that we need help figuring out the order of that fall into that category. You won't get everything because there's 5 of us and a hundred thousand of you, but we'll give you what we can." Heck, you could skip that, take the past 5? 6? years worth of data from that survey and have enough work for the next 10. Boy is that frustrating for everyone I have seen talk about that process, including me, and I love the idea of that process. (I'll even point out that I'm one of the gentle folk who don't think WMF exists solely at the volunteer community's leisure and that your collective employment is solely to keep the lights on while we build the single greatest free work of knowledge known to humanity.)

And once a task dies, no-one is going to find it

I don't really understand this. If a task is resolved, or declined it is still very much searchable. If tasks are more regularly groomed via reminder comments, that will lead to better written tasks. Recently I went through a bunch of 10 year old tasks, and most were duplicates or fixed. The ones that weren't and still valid were fixed, not because I didn't care about them, but because I wasn't aware of them.

And that was a half dozen tasks that have been dormant for years, some of which I can only assume would have been closed for inactivity under this policy.

I think if we are imagining a bot that closes out old tickets as an adversary we're looking at it completely wrong. It should be seen as a bot posting comments to remind participants about better triaging, prioritizing, and management of tickets. As someone who does care about our projects, if a ticket is well written, described and a valid problem I'm not going to let it get declined, I'm going to work towards getting it better understood by the people that need to understand it.

In T248034#7132710, @Jdlrobson wrote:

And once a task dies, no-one is going to find it

I don't really understand this. If a task is resolved, or declined it is still very much searchable.

You and I know how to find closed tasks, but I don't think as I suggested earlier that the default MO of anyone is "has this been reported before and closed without fixing?". The average bear definitely doesn't know, even if they have the MO to show up to Phabricator. (Phabricator is not welcoming, though as task managers go, it's the most welcoming I've had to deal with; I evangelize it and participation on it onwiki whenever I get the chance).

An anecdote: one of my wiki-colleagues with a technical background who should know, and be willing to interact with Phabricator just doesn't and instead asks me to (a role that I am happy to fill). I do so in the knowledge and faith that tasks that are still issues or feature requests in the software won't be closed out from under my feet. (Because then I have to figure out whether a certain task was fixed or declined and if declined whether it was an auto-decline -- all filterable in some future if this task proceeds to close tasks of course but that's trading community engagement time for some [doubtful on my part] developer productivity improvement.) Then when some sufficiently motivated volunteer comes forward, you're asking for bad reports that may not look at all like the earlier requests.... and then you're back to closing 101-year old tasks again as duplicates. Sad day. :(

If tasks are more regularly groomed via reminder comments, that will lead to better written tasks.

I distinctly left reminder comments on the table because those seem both feasible and reasonable on their face. I just think there's a concern of bot-driven spam back-and-forth as (currently) specified. (I honestly can't think of another downside to it, so that's a question of how to weight the back and forth.)

As a point of interest, I'd walk down the majority of tasks in Cite (which is one of the projects I watch) every time the bot went by (which is probably, well, a lot of those tasks--maybe it will get better when old Cite dies and is fully reborn as ParsoidCite) and myself would say "yup, those are all still valid" (out of good faith review, mind you, not bad faith WP:POINTiness), though I suspect a few maybe should be living solely in MediaWiki-extension-requests .

Recently I went through a bunch of 10 year old tasks, and most were duplicates or fixed.

I find (old) duplicates too in my Phab travels, yes. Rarely were they fixed in the meantime. That might be survivorship bias though because of diligent (or annoyed ;) engineers and managers. (My MO traveling is likely much different than yours, of course. Sometimes it's browsing the latest tasks scrollbar on the main page and sometimes it's hunting for a task that sounds an awful like some issue reported onwiki and sometimes it's getting hit with tasks into my email from project watching.)

The ones that weren't and still valid were fixed, not because I didn't care about them, but because I wasn't aware of them.

I do not wish to say anywhere at all that you or any WMF or volunteer developer doesn't care about these tasks under consideration; my whole MO on this task is that there are people who do, even if they aren't subscribed/present on Phabricator. (Or maybe I'm misinterpreting your tone here? Not sure.)

I think if we are imagining a bot that closes out old tickets as an adversary we're looking at it completely wrong. It should be seen as a bot posting comments to remind participants about better triaging, prioritizing, and management of tickets.

I'm willing to entertain that Jon's Friendly Task Bot is indeed a friendly task bot. I'm just fairly certain that this is the wrong community for such a bot, at least in regards to ending tasks.

As someone who does care about our projects, if a ticket is well written, described and a valid problem I'm not going to let it get declined, I'm going to work towards getting it better understood by the people that need to understand it.

Thank you. I appreciate it. (From one engineer to another.)

(But.) You will retire or leave at some point. (So will I, though I suspect my leaving will be predicated on death of hopefully-old age several decades from now.) Then the bot will have become an institutional force and fundamentally won't be revertable without having all the old tasks it closed be re-opened (even if its closings are tracked with its own auto-old-closed tag) or mass re-triaged which leads right back to this task. Much more painfully with likely some 10s of thousands of tasks magically springing open.

Maybe that's far enough away in the future that magical Jon's Friendly Task AI will be able to do all this management before then, anyway.

A question

Is it true a lot of your hardship is coming from tasks (or patches) that have been team-generated in the course of routine work? I am getting that feeling and want to get that on the table if so. It's general best practice that a single executable task should be a sprint-in-length at most, sometimes down to a day's worth of effort (depending on who you ask). Is it possible you're dealing with a lot of tasks that are smaller than a sprint in effort as an output of team processes? Or are you really trying to wrestle with the 300k less closed less out-of-your-scope tasks ranging the gamut from years of person-effort to days (presumably tagged with Epic ) or half-days of effort generated from any/every source?

Having a reminder bot (with tag) seems like a good compromise here. It makes sure old tasks don't get forgotten and leaves the action on whoever works on the product.

I'd be fine with starting there and seeing if that has any positive and measurable impact

Is it true a lot of your hardship is coming from tasks (or patches) that have been team-generated in the course of routine work?

For me it's the fact that my team maintains too many products :) during a project lots of feature enhancements will get created from staff/volunteers but seldom will they end up being reevaluated/triaged later.

misinterpreting your tone here?

Yeh. Just sharing personal experience

One problem that I can see from the proposal on top is that, when encountered, this would definitely lead to more comments like ‘Hey, regular reminder that this problem still exists’ that are usually frowned upon by @Aklapper before the stale-bot comes. No one really likes unpersonalised messages that tell them that their issue is not an issue no more (and the structure remind → close as invalid can imply that), so some people might go out of their way to avoid that. I’d suggest coming from the opposite angle if we intend to do it, i. e. providing positive reinforcement like ‘please comment if this task is still relevant to help us prioritise resolving it in the next month’, but that requires developer time, obviously, which is not always (never?) the option.

(Also, I notice that in some cases the fact that you tell people the problem still exists does not help to fix it (see T225873: Infinite scroll in StructuredDiscussions has no loading icon if you want to fix a small problem for me), so this might end up mostly bugging folks periodically instead of being helpful.)