On Tue, Oct 2, 2018 at 9:57 AM Brion Vibber <bvib...@wikimedia.org> wrote:
> *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. > IMO that kind of double duty is normal for all software development project management systems (and having to track bugs in two separate systems was in fact rather painful in the dark ages when we had Bugzilla + some team-specific external task management system). Rather, the problem is that it's a task management system used by many different groups (including volunteers) with overlapping scopes. Prioritization decisions are specific to a team (or an organization at best) while Phabricator task status and priority are global settings. This problem comes up in non-volunteer contexts as well, when a task is relevant to two teams and a high priority for one but low / zero for the other. So IMO the sanest approach is for all teams to come up with ways to mark prioritization that are local to their Phabricator projects (which typically means using a team workboard for prioritization and having some kind of "we don't intend to work on this" column). Setting tasks to stalled when no one is planning to work on them would be a reasonable practice if we decide to consistently use the stalled status that way, but today it's used as "blocked" instead. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
