Page MenuHomePhabricator

Restructuring of tasks with project community-consensus-needed
Closed, DeclinedPublic

Description

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.

Event Timeline

Luke081515 raised the priority of this task from to Lowest.
Luke081515 updated the task description. (Show Details)
Luke081515 added a project: Phabricator.
Luke081515 subscribed.

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"?

I totally agree with Legoktm. Please reopen.

But why we have more and more open tasks in future? If there is no consensus, this is definitely a blocker.

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

So the backlog grows and grows, and this spams workboards.

Please explain why a large backlog is bad.

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.

So the backlog grows and grows, and this spams workboards.

Please explain why a large backlog is bad.

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?

Yes.

Btw, reverted the bulk action.

Thank you.

And why? I see only disadvantages, or are there any advantages?

And why? I see only disadvantages, or are there any advantages?

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

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.

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

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?

Yes, please reopen all that.

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.

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

Sorry... I did the first action because there was no one who said anything against this for more than two weeks...

Did you discuss it on any more visible place such as mailing list, wiki or at least IRC?

Nemo_bis subscribed.

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.

The only thing here that needed "community consensus" were the bulk declinations...