Why do we have open tasks with Community-consensus-needed? Most of them will not get consensus in near future, so why are they open? My proposal is to decline them (after a month wihtout acitivity) and let people reopen them, if consensus reached.
Description
Related Objects
- Mentioned In
- T106760: Enable Flow on Research talk namespace in metawiki
T2378: Display links to redirects that link to non-existent pages in red
T14490: Warning needed if dimensions of reupload differ
T48528: Enable RSS on Commons
T28714: Allow banner to run only in the languages we have translations for
T21909: Extension Drafts for cs.wikipedia
T42095: Set $wgAllowExternalImagesFrom to allow https://upload.wikimedia.org/wikipedia/commons/
T43479: [Spam/vandalism] Raise $wgAutoblockExpiry noticeably
T51357: Increase WMF cluster default image thumb size
T61245: Review the PageNotice extension for deployment
T64717: Move oldwikisource on www.wikisource.org to mul.wikisource.org
T64781: Make spamblacklist hit log viewable by non-admins on Wikimedia wikis
T64811: Review and deploy TwitterCards extension for proper display
T67750: Low-risk OAuth consumers should be automatically approved
T66710: Embed should use localized wikitext
T71404: preference to ignore comments from specific users ("killfile")
T68066: Add Help namespace to default search on all wikis
T69709: Change default thumbnail size to 300px for all WMF wikis
T77509: Remove tutorial from UploadWizard
T86521: Change "alt" to "title" for img (latex)
T102333: Configure WikiLabels as a MediaWiki gadget
T105064: Allow other website visibility of commons file usage
T108738: Allow deleting CentralNotice campaigns - Mentioned Here
- T102818: Disable patrolling on de.wikipedia
Event Timeline
Do it and document on https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes ? :)
Ok, so if nobody has anything against this, I will change the documentation and decline the existing open task via bulk.
Um, what? Please re-open all those tasks. Open tasks that aren't moving anywhere right now are fine, someone will get to them in the future, eventually. There's no deadline.
But why we have more and more open tasks in future? If there is no consensus, this is definitely a blocker. So the backlog grows and grows, and this spams workboards. This decline is not like a "finally deadline", it's just a deadline till there is no consensus. (Otherwise I have no problem with reopen, but I think we should discuss this first, because there was no activity at the closed tasks for more than a month, so it is not urgent).
This doesn't make any sense. Why do we need duplicate requests? And why would we want to wait until there is "no consensus"?
No it's not always a blocker, and it's clear you didn't actually read the tasks you mass-closed. Please justify why having open tasks is bad thing.
So the backlog grows and grows, and this spams workboards.
Please explain why a large backlog is bad.
This decline is not like a "finally deadline", it's just a deadline till there is no consensus. (Otherwise I have no problem with reopen, but I think we should discuss this first, because there was no activity at the closed tasks for more than a month, so it is not urgent).
Um, what? I guess what you want is the "stalled" status. But mass-declining like this is extremely disruptive, you didn't even check whether the tasks had the tag applied correctly. Things are low priority and don't get touched very often, and THAT'S OKAY.
Why do we have open tasks with Community-consensus-needed? Most of them will not get consensus in near future, so why are they open?
I believe many of them "just" need somebody to lead the effort, write up a proposal and start a discussion as some on-wiki venue. Nobody supports or opposes them because it just wasn't talked about anywhere outside of Phabricator (or at least not during last few years, in some cases).
If you got workboards with more than 200 tasks at a blocked column, this is annoying, when you load that baord. Not everyone has fast internet, and in one or two years we have a lot of these tasks I guess. For example a task like T102818: I know the dewiki community. The chance that this task gets resolved in the next two years is about ~10-20%. And this is simalar at a lot of other tasks, so the count of open tasks will behave like here, they grow and grow. So you proposed to stall these task, but the problem here is that stalled tasks are not closed. Sure, this is just a blocker, but in some tasks we have a request, which the communityy would never approve, so why we let this open? Do we want dozens of tasks for a couple of years, just open and noone does everything?
Btw, reverted the bulk action.
The Phabricator backlog (and the Bugzilla backlog before it) is among other things a wishlist of features and functionality for a very large and diverse collection of software serving an even larger and more diverse user community. Things should be closed when they are either done or shown to be contrary to the interests of the general population. 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.
When I worked in private industry "sweeping the backlog" was a pretty common thing to do based on the knowledge that our development resources were finite and things that weren't actioned upon in X days/weeks/months were honestly never going to get done. The freakishly different and truly marvelous thing about a FLOSS project where work is done in the open and anyone can contribute however is that we get new resources in the form of volunteers all the time and yesterday's "we will never ever get to this" could easily be tomorrow's "wow, I'd love to fix that because it bugs me too" issue.
Please be cognizant of the large amount of e-mail that's generated when you perform bulk actions. :-)
Sorry... I did the first action because there was no one who said anything against this for more than two weeks...
Yes, please reopen all that.
If you wish to process or close these tasks, ping the requesters and help them to get consensus, or let a message on the local project.
There weren't a lot of subscribes, you were alone with scfc and Aklapper.
Maybe to ask advice from people handling the site requests would have been a good idea?
Already done, see above.
@bd808: I don't want to close them, because there are "stale"... that is not a decline reason in my opinion too. I just think that it is not useful to have tasks, where we need approval by community and where we can say that the community would never approve that, or voted against this. In this case have an open task is not useful.
If there was actually a community vote to reject one of more of these items then depending on the task itself I would agree that it should be closed (if the task was only about the community vote) or the tag should be removed and a note left on the task that a vote was taken and the community rejected the feature.
If the tag was placed on something prematurely then I think removing it with a note on the task is also perfectly reasonable.
The one part I don't agree with is "where we can say that the community would never approve that" because I don't think anyone can know that a priori. You can assume, but you can't know.
Did you discuss it on any more visible place such as mailing list, wiki or at least IRC?
Most of those bugs are desirable, some can be closed (the discussion found issues but nobody bothered to wrap it up).
The main problem is that many of those bugs should not have had Community-consensus-needed added in the first place, or had a valid non-community reason to have the #shellpolicy tag. I still maintain that Community-consensus-needed is a horrible name that leads to confusion; if we keep it, we must be patient and do some regular cleanup.