On Friday, February 24, 2023, Dan Garry (Deskana) <djgw...@gmail.com> wrote:
> On Fri, 24 Feb 2023 at 11:20, Andre Klapper <aklap...@wikimedia.org> > wrote: > >> * Personally I also assume Lowest priority is sometimes used instead >> of honestly declining a task (means: "this is not a good idea"[5]). >> But of course that is rather hard to prove. >> > > This is anecodal, but when I was a product manager at the WMF, I did this > sometimes. As is true in any company or project, there will always be > tickets that contain valid bugs or requests, but the reward per unit effort > makes them not worth fixing. I often tried to close these as declined to > reflect that reality, but not infrequently someone outside the team would > reopen the ticket. The path of least resistance to stop team workboards > being filled with tickets that would never be actioned was to mark them as > lowest priority, and then use a filter to remove those tickets from our > views of the board. > > I don't particularly have a view one way or the other on removal of the > "lowest" priority. The workflow I described above wouldn't really change; > "low" could just become the new "lowest", but people wouldn't find it > demoralising, I suppose? > > Dan > 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. My personal definition of lowest vs declined: Declined: if you wrote a patch for this it would be rejected. Fixing this is a bad idea. Lowest: nobody cares and nobody is going to work on it. However if you care, feel free to write a patch and it will get reviewed. 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. If i could change the priority field i would probably change it to be only: * unbreak now * work on next (or "urgent") * normal * no intention to fix (aka lowest) I think that's the only useful statuses. I would prefer statuses to be more descriptive. Nobody knows what "high" means. Everyone knows what unbreak now means. I would also suggest being really blunt with the names too. It's much more demotivating to give people false hope. -- Bawolff
_______________________________________________ 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/
