From:  Liz Henry <>
Date:  08 Jun 2013 01:44:33 Hong Kong Time

SUMO bug triage day - report


We had a lively triage day for SUMO bugs. Thanks very much to Andrew
(feer56), Swarnava, Tiziana, Aleksej, Tyler, and mga,  as well as to the
sumodev team.  We deluged the #sumodev channel bot with bugs, and hope
that it was worth it!

We started out with around 600 open bugs to look through. There are now
537 open bugs.  Many more have extra information added, or are waiting
for information with a new needinfo flag.

Over 70 still-open bugs had information added yesterday.

And, we closed about 70 bugs!

Breaking the bugs down by component gave us numbers easier to work with.
You can see this breakdown as follows:

    Army of Awesome bugs (35/22)
        Triagers: Swarnava, Andrew (feer56)
    Code Quality bugs (57/48)
        Triagers: Andrew (feer56)
    Forum bugs (31/27)
        Triagers: mga, Tyler
    General bugs (106 -> 96)
        Triagers: lizzard, Swarnava
    Knowledge Base Software bugs (217→209)
        Triagers: Aleksej
    Localization bugs (19/18)
        Triagers: Andrew (feer56)
    Mobile, Knowledge base
    Questions bugs (71->54)
        Triagers: Tyler, Andrew (feer56)
    Search bugs (34->32)
        Triagers: Andrew (feer56)
    Users and groups bugs (39)--> (31)
        Triagers: Andrew (feer56)

And more information is on the SUMO bug day page on the wiki,

My feeling is that, if we try this again, we will go through more bugs,
and will know how to triage more efficiently.

I'd love to know whether this seemed helpful to the sumo developers,
whether it was annoying to get a flood of bugmail and irc bot notices,
or both. It is possible it may be more helpful over time as we clear out
more of the dead wood, making it easier to attract new contributors.

One thing that became clear to me was that bugs often stick around
longer than the pages or products they served. Many bugs mentioned a
flaw in a page, or odd support forum behavior, or a desired feature
change, but lacked a URL or a screenshot to document it.  In going
through bugs from over a year or two ago, it would be faster to clear
them out if they had URLs or easy pointers to what they were talking
about. With support forum or knowledgebase bugs, that often didn't exist
any more.

In theory, providing a url or other obvious pointer to the right spot
could also help lead community contributors to help them try to fix a
bug and submit a patch. Even if everyone knows what you are talking
about right at that moment, a year later, they may not. So, when you
report a bug, put in as much identifying info as you can.

Thank you everyone for a very interesting, educational, productive day!



Liz Henry