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/ _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
