On Sat, 2019-03-16 at 04:52 +0000, Pine W wrote: > From the end user perspective, reporting a bug and then having nothing > happen, or getting an initial reply but later seeing that a bug appears to > stall for months or years, may be frustrating depending on the nature of > the bug and the patience of the user. I think that communicating with users > regarding when bugs will likely be fixed would be helpful. I think that > some of that happens already, but there's more that can be done. There are > probably ways to automate some of these communications to a degree. > > On the larger scale, I don't know whether it's possible to get a good large > scale understanding of all of the open tasks in Phabricator.
What does "understanding" imply; which understanding do you lack? It's hard to help understand without knowing what's specifically missing. :) > I speculate that teams might be able to create semi-automated reports > regarding their own teams' tasks. Which specific problem do you think would be improved by reports? Not sure if it's what you're after: There are Burndown charts. Example: https://phabricator.wikimedia.org/maniphest/report/burn/?project=PHID-PROJ-kfrrtvyn66ou2iq4y4ai or in Phlogiston. For more information, see https://www.mediawiki.org/wiki/Phabricator/Project_management#Scrum_in_Phabricator > To get a larger view of the situation in Phabricator might require > combining the unique outputs of the reports from individual teams. Can you explain why a "larger view" would solve a problem and which problem that is? It's probably not 'some bugs will never get fixed'. Maybe it's 'some tickets don't get a reply'. Maybe it is 'some tickets should get prioritized differently'. Or maybe something else. These are different things... > By having a big picture view of the situation I hope that we could > improve our collective situational awareness regarding tasks, > including open feature requests and technical debt. Also, by creating > snapshots of the results of the same type of combined report over a > period of months or years, maybe we could get a sense of how > technical debt is changing over time. For the records, that would require excluding feature requests from any statistics. Plus definitions and understanding of tech debt differ. Plus tech debt can also be "TODO" code comments and many other things. > To summarize: I am thinking that a two pronged approach would be good, one > regarding communications regarding the status of individual bugs If something happens on an individual ticket, someone communicates that in that ticket. Examples: People move some tasks on workboards, people assign some tasks, people add some comments. What exactly is missing? Do you have an example that's not abstract high-level, please? :) > and one regarding a big picture analysis of technical debt. > > I realize that there would be costs of time and money for both of those > approaches. Automation can help with both. It's still unclear to me which actual underlying problem(s) you'd like to get solved. The message seems to mix several things ('no reply to some tasks', 'some tasks might get replies but not fixed', 'some tasks should be prioritized differently' etc) but maybe I misunderstand. andre -- Andre Klapper | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
