Triaging Documentation bugs

[Walter Lapchynski]

Oops, forgot to include the documentation and OP in my reply so I'm
leaving my original response below. Please reply all folks.

Anywho, the documentation is as much code as a web page is and let's
remember that various Ubuntu web sites are managed on Launchpad and
held by the same triage processes. In fact, it appears to be XML,
e.g.:
https://bazaar.launchpad.net/~ubuntu-core-doc/serverguide/trunk/files/head:/serverguide/C/

That being said, I'm not sure we need to treat this differently, but
if the Documentation Team sees some reason to have a unique workflow,
that's certainly something we can discuss.

wxl

On Fri, Dec 5, 2014 at 8:30 AM, Thomas Ward <teward at trekweb.org> wrote:
> I think we need to keep in mind this is the 'server guide' and might not
> apply to the same policies as standard Ubuntu bug triage.  Especially
> since the Documentation Team has ownership over that project.
>
> The Bug Squad works in Ubuntu bugs, but the documentation bugs are not
> necessarily under the Ubuntu Bug Triage processes.  I am not a member of
> the Documentation team, but if the Server Guide (and other Documentation
> Team governed bugs) are subject to standard Ubuntu Bug Triage rules,
> then Walter's response here is accurate.
>
> I believe this merits additional discussion between the Bug Triagers and
> the Documentation Team to determine whether documentation bugs fall
> under the same triage procedures as standard bugs or not.  (It stands to
> reason that since it's documentation and not fixable code/packaging bugs
> like most Ubuntu bugs, it might be a case of different statuses and
> different guidelines, kind of like the special workflow bugs.)
>
>
> On 12/05/2014 11:18 AM, Walter Lapchynski wrote:
>>>> 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."
>>
>
>
> ------
> Thomas
> LP: ~teward



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