Adopting Nautilus, wiki page created

Bruno Girin brunogirin at gmail.com
Tue Jan 5 13:13:03 GMT 2010


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





More information about the Ubuntu-bugsquad mailing list