*nods* I think the root problem is that the phabricator task system does double duty as both an *issue reporting system* for users and a *task tracker* for devs.
An issue reporting system should capture all actual problems and all actual suggestions, and is meant to provide visibility for the devs into the world of users. A task tracker should capture only things that are, or are planned to be, worked on and is a work planning tool for the devs. Secondarily if open, the task tracker provides visibility for the users into the world of devs.
This mixup of concerns is endemic in open source software development, unfortunately, and leads to exactly the sorts of conflicts you mention.
One way to handle this in a mixed single tracker environment is to use a state marker such as a backlog column in a workboard -- don't decline, move it to the "backlog" or "someday" column. Another is to use separate project tags for general issues and specific work efforts. Put it in the general project for issues, copy it to the work project if it's being tracked in your work group.
-- brion
On Tue, Oct 2, 2018, 9:31 AM Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder thinks
that doing the task as proposed is a bad idea. There are also variants of this:
- The person who filed the tasks misunderstood what the software component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are legitimate explanations.
However, if the task suggests a valid idea, but the reason for declining is that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to mark it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined" gives a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long term" or "Volunteer needed" column on a project workboard, but nevertheless Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l