Adopting Nautilus, wiki page created

[Sense Hofstede]

2010/1/5 Bruno Girin <brunogirin at gmail.com>:
> On Fri, 2010-01-01 at 14:24 +0100, Sense Hofstede wrote:
>> Hello,
>>
>> I've created a wiki page at
>> <https://wiki.ubuntu.com/BugSquad/AdoptPackage/Nautilus>. I've added
>> some information to the page and came up with three tasks: 'New Bugs',
>> 'Confirmed Bugs' and 'Forwarding upstream'.
>>
>> What do you think of the page? Is the information correct and sufficient?
>
> It's a great start. I think we could extend the information by being
> more specific in what is expected of people when dealing with bugs in
> the "New", "Confirmed" or "Triaged" states. Some of it is explained in
> the HowToTriage page [1] but we could be more specific here. Here are a
> few ideas to start with:
>
> When a bug is New, the aim is to move it to Confirmed or Invalid,
> depending on whether we can re-create it or not, or mark it as duplicate
> of another bug. In some cases, we may need more information, in which
> case, it should be changed to Incomplete first and we should start a
> dialogue with the original reporter to be able to re-create. In all
> cases, this first pass should be an opportunity to improve the bug
> report (even if we can re-create it easily) and rewrite it in the form:
>      * Steps to recreate
>      * Expected behaviour
>      * Actual behaviour
>
> That's the theory. In practice, how do we deal with the more complex or
> arcane bugs that require certain configuration or hardware that the
> triager doesn't necessarily have? For instance, if there is a bug report
> about iPod integration and the triager doesn't have an iPod, how do we
> move it forward?
>
> Once a bug is in the Confirmed state, it should be moved to Triaged,
> which only Bug Control members can do. I think that if the previous
> phase is done properly, moving bugs to triaged should be
> straightforward. So for this to work, it would be useful to know what
> Bug Control members look for in a confirmed bug to consider it triaged.
> Sense, what would you want to see in a bug report to move it to Triaged?
>
> Once bugs have been triaged, the aim is to get them resolved. Some of
> them will be resolved by the Ubuntu developers, others need forwarding
> upstream. How is that identified, who is responsible for making that
> decision and how is this communicated in the bug report? At the moment
> there are 559 bugs against Nautilus in the Triaged state. That's a lot
> so I suspect that a number are old and have actually been resolved but
> never closed, while others have not been addressed and may have given
> the original reporter the impression that nobody cared about his
> problem. How do we move them forward?
>
> Sorry about all the questions, I'm sure some of them are answered on the
> wiki but I've struggled to find that info and it might be useful to
> answer them in the Nautilus context. Also if any of my assumptions above
> are incorrect in terms of the triaging process, please point it out.
>
>>
>> Yazen, Marcos and Bruno, I'm glad you're interested. I've only added
>> myself to the table because I don't know what you would like to do. If
>> you'd tell me that and give me your name on the wiki I'll add you, but
>> if you add yourself to the table that's fine too.
>
> Thanks, I added myself to the wiki.
>
>>
>> Erick and David, you said you hadn't started with triaging yet. I
>> would recommend you to gain a bit more experience before adopting a
>> package. At <https://wiki.ubuntu.com/BugSquad/Mentors> you'll find
>> more information about the mentoring process, I suggest to read that
>> and apply for a mentor.
>
> Thanks, that will be useful to me too :-)
>
> [1] https://wiki.ubuntu.com/Bugs/HowToTriage
>
> Bruno
>
Hello,

First of all, don't apologise for asking questions! Your mail
contained some good suggestions and you ask some valid questions.
Furthermore, like someone whose name I forgot once said, there are no
bad questions, only bad answers.

The explanations of the different tasks and the actions you're
expected to execute when doing them could and should be more extensive
indeed. However, I'm not sure if it would be a wise decision to write
everything again and again on each adoption page. Not only would it be
a lot of work to update this, it would also make the page longer and
divert attention from the content that actually matters for the
adoption group.
What I would suggest is to write a separate page that briefly explains
all tasks and then provides a link to a more extensive description.
This page could be included on all adoption pages.

Bug descriptions are often incomplete and don't reflect the bug report
properly. I also often don't extend the bug descriptions, even though
it would be desirable. However, it is a lot of work to do this for all
bug reports. We could mention it in the explanation of the first task,
but I think that it is more something the Bug Squad as a whole should
pay attention to. Furthermore I think that it would be better to spend
our energy on triaging bug reports and making sure they are either
marked as Invalid or are of use to the developers and packagers. We
can't afford to do much else with so many bug reports.

It is the task of the triager to determine whether the bug has to be
forwarded upstream. The description, title and replies of/to the bug
report should make this clear. Packaging errors are mostly Ubuntu
bugs, unless the package was synced from Debian. In that case it
should be forwarded to Debian.
There is a separate task/subgroup for forwarding upstream because it
is a disruption of your work when you have to leave Launchpad and not
everyone is familiar with GNOME Bugzilla. I though it would be better
to let people that focus on triaging bugs in Launchpad focus on
triaging bugs in Launchpad. When a bug should be forwarded upstream
they can open an empty task against the upstream project with the
"Also affects project" button.

Maybe it would indeed be wise to create a temporary focus group that
goes to all bugs that were or weren't triaged and that are forgotten.
It would be a lot of work to clean those bug reports, but it would be
worth it. When it is done it is the task of the adoption group to make
sure the adopted package stays in shape.

Regards,
-- 
Sense Hofstede
[ˈsɛn.sə ˈɦɔf.steːdə]