Triaging Documentation bugs

Walter Lapchynski wxl at ubuntu.com
Fri Dec 5 16:18:46 UTC 2014


>> On Thu, Dec 4, 2014 at 12:44 PM, Peter Matulis
>> <peter.matulis at canonical.com> wrote:
>>> A discussion has surfaced within a doc bug [1] about how to triage bugs.
>>> [1]: https://bugs.launchpad.net/serverguide/+bug/1327173
>> My understanding is that this should be marked "Incomplete" since it's
>> been looked at (not "New") but we're still trying to gather enough
>> information to determine whether it's a bug or not (so can't "Confirm"
>> it).

Confirmed means that someone else sees that there's a problem.
Ideally, this occurs when there are a series of steps to repeat the
bug. How does that apply to the documentation? Just as Peter describes
in the bug: someone needs to find the deficiency through following the
instructions. Ideally, someone changes the description to have very
clear sections of "steps to reproduce," "expected results," and
"actual results."

When the bug triager can confirm this themselves and has enough
information that a clear fix can be derived (whether through a patch
or simply describing the problem and its causes enough), then it can
be triaged.

Since information has been provided and the bug is stalled at
confirming it, it's not incomplete. Waiting for confirmation is not
equivalent to incomplete status. It would be nice for there to be a
"not confirmed" status, but there's not. That being said, it stays
"new."

-- 
@wxl
Lubuntu Release Manager, Head of QA
Ubuntu PPC Point of Contact
Ubuntu Oregon LoCo Team Leader



More information about the Ubuntu-bugsquad mailing list