See also T393376: Automatically abandon old changes after some time

Change #213579 abandoned by Hashar:

[operations/puppet@production] [WIP] Stub LimeSurvey configuration

Reason:

This was filed almost exactly ten years ago. The task T94807 has long been resolved and I don't think this change is relevant anymore.

https://gerrit.wikimedia.org/r/213579

I am happy to help test in next days/weeks as I will be anyway using it and would be in need for at least the rest of 2024 :-)

https://www.mediawiki.org/wiki/Synchronizer does something similar.

@Tgr I'd like to help with creating a more production ready version. I have some experience on hosting and configuring synapse, is there something I could do?
And could we maybe buy a space on EMS services instead, to support the project more directly?

In T186061#10198818, @Kristbaum wrote:

Is there already an instance running that can create accounts with Wikimedia SSO somewhere?

Is there already an instance running that can create accounts with Wikimedia SSO somewhere? And is that instance long term viable?

This Epic has served its purpose. We have come such a long way in the last 8 years that it is difficult to remember what the starting point was when I wrote this. Thank you to everyone who has helped make things better!

In T248034#10121971, @Bugreporter wrote:

still useful to keep open indefinitely so (1) they can be commented on; (2) they can be mentioned or referred in other tickets; (3) such idea can be proposed by multiple people in a long range of time, and such tasks provided a merge target.

with some confidence I can say that any ticket older than 2 years is already being filtered out of team work boards (or the workboard is too big that it is being effectively ignored) so it is effectively being treated exactly the same as a declined ticket.

Teams should always use a dedicated team project to organize their ongoing (current) or short-term (foreseeable future) works which is different from component projects, represents all issues and tasks about a specific software. Any tasks not in any team projects should be considered backlog and may be kept open indefinitely, potentially be picked up one day.

I do not oppose (1) or (2) if there are good task criteria.

Eventualism may be good, since things may be more relevant after years. When doing a new project we may find we need to solve some old tasks as a part, so it is meaningful to keep old tasks open. E.g. T42050 is a task that is inactive for 8 years but picked up recently as a part of ongoing project. As long as it continued to be valid and not vetoed, it is harmless to keep a task open for 50 years.

This entire conversation seems to only repeat the aspect of eventualism

Another example of ticket that can be considered "stale" is T190129. The task itself has little activity in 3 years, but is a big goal that takes multiple steps to cook. An epic like this may take several years or even decades to complete, with potentially years of inactivity. But there is reason to keep it open, since it described what should be done eventually.

In T248034#10028781, @Jdlrobson wrote:

FWIW as someone who has worked in Phabricator for a decade now, with some confidence I can say that any ticket older than 2 years is already being filtered out of team work boards (or the workboard is too big that it is being effectively ignored) so it is effectively being treated exactly the same as a declined ticket.

I can say that any ticket older than 2 years is already being filtered out of team work boards (or the workboard is too big that it is being effectively ignored) so it is effectively being treated exactly the same as a declined ticket.

My third point in T248034#10026259 refers to T228745, which is a task with no activity in 3.5 years, yet it should not be closed as inactive (continues to be thought upon).

I decided to submit a patch for the oldest open bug on Phabricator (T2005) on a lark a few weeks ago. Prior to that it hadn't been touched since 2021.

FWIW as someone who has worked in Phabricator for a decade now, with some confidence I can say that any ticket older than 2 years is already being filtered out of team work boards (or the workboard is too big that it is being effectively ignored) so it is effectively being treated exactly the same as a declined ticket.

1. You can still have all discussions in one place when a ticket is closed, thus not an argument

Example: T371302 - I will rather like merging all duplicated reports like this to one single task, so the target should be kept open to indicate the feature request is still valid (even if untouched in one decade).

2. It will not be confusing if you also closed the parent one, thus not really an argument

One example is T320842, which is a relative new task that is depended on a old task. So there are no point to close the subtask even if the subtask can be considered stale.

1. You can still have all discussions in one place when a ticket is closed, thus not an argument
2. It will not be confusing if you also closed the parent one, thus not really an argument

I strongly oppose this task for the following reasons:

• Phabricator is not just a bug tracker but also a place for feature requests and any current or future planned or proposed tasks. One feature may be proposed multiple times where we have no deadline on implementing it, so it would be meaningful to keep all discussions (including arguments pro and against) in one place. As an example I have merged a feature request created yesterday to one created 15 years ago.
• GitHub issues are mostly single and isolate, while in Phabricator there can be multiple tasks with complex dependency relation. For example it may turn out that a new feature request is blocked by another task created years ago, so the old task is added as a subtask. If we closed the subtask as stale, it will be confusing since the parent one is left open.
• Many tasks only described a goal, and there are multiple steps (i.e. tasks) inside, some or most of which did not yet have a task (sometimes it is not clear which to be done precisely); task provided a place to discuss its detail. E.g. here described a proposal that still not happened, but continues to be thought upon; so it is not a good candidate to be closed as stale even if the mentioned task has no activity in four years.

It's reported on https://meta.wikimedia.org/wiki/Communications/Movement_Communications/Meta-Wiki_presence

The problem is not only on design, is also on usability. The WMF "redesigned" pages, but they forgot the mos tvisited one and didn't make any proposal. If the Main page is our main entry point, we should think on what kind of contents should be there, and some of them may be modular and dynamic, so out of the possibilities of the community, becuase they ask for a deep coding that currently is not available.

Maybe the (global) community can try to host some sort of "competition" to propose better design of Homepages?