On Fri, 2023-02-24 at 08:31 -0700, Brian Wolff wrote:
I feel this is a problem with phabricator being used as both a
project management tool for teams and as a bug tracker, when those
are different things. Certainly its reasonable for teams to have bugs
they dont think is worth fixing and a way for them to ignore said
bugs, but declining them hinders people who are trying to track what
the known bugs are resulting in duplicated effort. Not to mention
external contributors may want to fix these bugs and declining them
hinders this. I personally think the best solution is to have
separate work boards for team management vs mediawiki component.
I strongly agree and advertise having both a project/workboard for the
team (violet project tag) AND a codebase project tag (blue project tag)
for the software.
Scope and thus responsibilities of teams change over time.
A ticket may be still valid for a codebase though some team might not
steward or maintain this codebase anymore.
Generally i find the priority field an endless source
of drama. The
way priority/severity gets conflated is problematic, the way it is
global instead of per work board is problematic. The way non-devs
think it is prescriptive instead of descriptive is very problematic.
Sometimes i wonder if it should be removed entirely, although maybe
that is too far.
Many years ago, restricting who can set/change the Priority field value
was discussed in
https://phabricator.wikimedia.org/T819 .
Over the years we have become more restrictive in who can change
certain aspects of tasks or projects in Phab due to vandalism, e.g. by
having Access-control lists (ACL) like the #Trusted-Contributors group
in Phabricator (and a similar concept in Gerrit).
Adding such restrictions often requires code changes in Phabricator
while it seems that WMF does not invest much effort into actively
fixing some of the shortcomings of its infrastructure software.
Thus some folks might instead prefer to use whatever tools folks are
already used to do or tools which presumably serve better folks' needs,
with the side effect of decreasing collaboration and transparency.
Cheers,
andre
--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/