Hi Community Metrics team,
this is your automatic monthly Phabricator statistics mail.
Number of accounts created in (2015-03): 388 Number of active users (any activity) in (2015-03): 838 Number of task authors in (2015-03): 461 Number of users who have closed tasks in (2015-03): 215 Number of tasks created in (2015-03): 3461 Number of tasks closed in (2015-03): 2830
Number of open and stalled tasks in total: 20757
Median age in days of open tasks by priority: Unbreak now: 48 Needs Triage: 88 High: 113 Normal: 373 Low: 668 Needs Volunteer: 498
TODO: Numbers which refer to closed tasks might not be correct, as described in T1003.
Yours sincerely, Fab Rick Aytor
(via community_metrics.sh on iridium at Wed Apr 1 00:00:05 UTC 2015)
Hi Quim and team practices folks,
Do you have any suggestions about how to shorten the average time for bug fixes shown here? In particular, it seems to me that "unbreak now" bugs should be fixed in something like 10 days max. If something is seriously broken, 48 days is long time to wait for a fix.
Thanks, Pine On Apr 1, 2015 8:56 AM, communitymetrics@wikimedia.org wrote:
Hi Pine,
I understand your concern, but in all fairness Phabricator is used by a lot of people for a lot of different things, and without a better understanding of what kind of tasks are being marked as "unbreak now" (and by whom), I don't think it makes sense to set thresholds (which will always end up being arbitrary, without better data).
It might be useful to dig a little bit into these "Unbreak Now" tasks: who is proposing them? What products/features do they address? How many have been claimed/scoped/pointed/commented on? Phabricator has a pretty good query interface that should make it easier to filter and browse tasks to answer these questions. If you were interested in taking a stab at this, I'm sure folks on this list would be interested in the results :)
Cheers, Jonathan
On Wed, Apr 1, 2015 at 9:31 AM, Pine W wiki.pine@gmail.com wrote:
Or perhaps we need better definitions of what unbreak now means. Wasn't the original definition supposed to be for major outages? The type of thing where 48 hours was the very outside limit on acceptability? E.g. bugs of the form "25% of users can't edit".
Of course history has shown that trying to enforce some shared notion of priority in bugzilla (and i guess phab too) is a loosing battle, one which the gains are not really worth the effort.
--bawolff
On Apr 1, 2015 2:23 PM, "Jonathan Morgan" jmorgan@wikimedia.org wrote:
Hi Pine,
I understand your concern, but in all fairness Phabricator is used by a
lot
of people for a lot of different things, and without a better
understanding
bug
On Wed, 2015-04-01 at 09:31 -0700, Pine W wrote:
Note that the value does not express how long a task has had this priority, but how long a task which currently has this priority set has been open. For example, T1090 has been open since Nov 2014 but has "Unbreak now" priority only since March 2015.
On Wed, 2015-04-01 at 20:40 -0300, Brian Wolff wrote:
The task priorities are defined here: https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_level...
The list of open or stalled tasks with "Unbreak now" priority: https://phabricator.wikimedia.org/maniphest/query/WtxxGlVJ.aPg/#R
Some of these tasks likely don't match the definition of "Unbreak now".
It is welcome to ask about the progress of tasks which have had "Unbreak now" priority set for a while and point to the priority definitions.
Generally speaking, some teams/developers are better and some are worse setting realistic expectations via priorities. The absolute numbers of open tasks per priority and project (distribution of priorities in each project) can be seen here: https://phabricator.wikimedia.org/maniphest/report/project/?order=total
In my opinion, low and lowest priority should be used way more often.
Cheers, andre
wikitech-l@lists.wikimedia.org