About triaging etc.
Jeroen van Dongen
I'm a little confused. Recently I noticed some tickets in the ticket
tracker that were very old and seemed to me as if there would be very
little chance that they would ever be resolved, given their topic -
precisely the thing we could get rid of quickly, so as to be able to
focus on stuff that's more relevant. Seemed to me to be precisely the
spirit of the new triage process.
Reading the documentation on contributing I read things like:
" ... so there are many ways you can help Django's development:
...
* Triage patches that have been submitted by other users.
Please read Ticket triage below, for details on the triage process.
"
(BTW: I guess "patches" in the above should read "tickets")
So I read on about triaging:
"One way to help out is to triage bugs that have been reported by
other users. A couple of dedicated volunteers work on this regularly,
but more help is always appreciated."
So I guessed ... lets help out a bit. Even asked on this list for
advise:
http://groups.google.com/group/django-developers/browse_thread/thread/16b3187727a09275/29ef44a570909f7e?lnk=gst&q=jeroen&rnum=21#29ef44a570909f7e
Then I proceeded and closed a ticket as 'wontfix', with the resulting
discussion as can be seen in http://code.djangoproject.com/ticket/2415
And that's where I got confused: the contribution page does not say a
single word about who the triaging crew is, how you can become a
member of it etc.
So my question ... is triaging only to be done by "the traiging crew"
and if so what are the proper procedures around it?
For the record: I'm not offended or anything, it's just that I think
that getting people on board starts with some clarity.
Best regards,
Jeroen
James Bennett
> Then I proceeded and closed a ticket as 'wontfix', with the resulting
> discussion as can be seen in http://code.djangoproject.com/ticket/2415
I don't think we have or really need an "official" policy on it, but
I'd personally *prefer* that tickets only be closed by one of the
triagers, a Django dev, or the person who submitted the ticket. It's
nothing personal for or against anyone, it's just that -- to me at
least -- that seems like the optimal solution for maintaining
consistency in the ticket system. But I don't think it'd hurt, if
we've got more people who want to do ticket triage, to expand that
role a bit; we've certainly got enough tickets :)
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Jacob Kaplan-Moss
> single word about who the triaging crew is, how you can become a
> member of it etc.
Agreed that we need to be more clear about who these people are.
Anyone want to create a "Who's who of Django" page on the wiki to keep
track of everyone? I'll make one later on if nobody gets to it.
In terms of how to become a member of said crew: like most open source
projects, Django is essentially a meritocracy. Jump in and start
contributing, and if you do good work it'll be recognized. To quote
the Wikipedia code: "be bold" -- be willing to make mistakes (and take
criticism well) and you'll do very well in open source ;)
Jacob
Malcolm Tredinnick
This doesn't quite address Jeroen's original question though: is it
appropriate John Q Public leap in and start triaging, as a form of
contribution, or not? Our documentation suggests it is, but then we also
have a team of designated trac watchers. Hmmm... :(
I'll admit to being confused about our intentions here, too.
Open Source projects succeed or fail based on the quality (which, thanks
to laws of random selection, often correlates with quantity) of their
volunteers and rarely have enough people willing to put in the effort.
So encouraging new contributors is a good thing. On the other hand,
closing tickets as "wontfix" is a big(-ish) decision sometimes, so some
experience is needed in order to be comfortable about getting it mostly
right in order to treat the submitter (and other people interested in
the ticket) correctly -- they are volunteer contributors, too, after
all.
Not all very old tickets are an automatic close because they do capture
a nice "one day, maybe" or some kind of generic problem. Sometimes you
can tell because a lot of people have joined the CC list watching for
some action. Sometimes recent comments (usually those more substantial
than "this would be nice") give real information.
On balance, I would prefer that bigger decisions (closing as wontfix or
moving to "ready for checkin") about tickets are made by a slightly
smaller, more experienced group, just because it reduces the chances of
having to back-track all the time. If somebody I don't know closes a
ticket, I'm basically going to go and do the same work they just did to
check the result. If somebody from the triage team or another developer
or release manager does this, I'm typically going to just read the email
about it, note the ticket title to check for consistency, and move on.
Anybody who is willing to create a non-anoymous Trac session should be
encouraged to do any one of...
- move a ticket from "unreviewed" to "accepted" if they can
repeat the problem, it's against documented behaviour and is in
a non-deprecated component.
- mark a ticket as a duplicate of another one, assuming it
really is a dupe and not just "maybe, might be". If the
duplicate is not a complete carbon copy and might contain extra
information, add a note in the surviving ticket as well (along
the lines of "see ticket #1234 for a similar version of this
problem").
- close clearly invalid tickets, such as requests for help,
- where a ticket doesn't contain enough information to repeat
(or understand!) the problem, post a request for more
information -- and explain the information needed. Drop in a
note to say this is done as part of triage.
- review patches, whether they be tests -- look for likely cases
that are missed -- or docs -- read them and see if you
understand -- or code.
All of these are pretty non-controversial. The harder step is how to get
from that point to "trusted triager"? To balance between too much
formality and anarchy, how about something like this?
If somebody not in the main traige team thinks a bug is ready to
move, they can post a note (indicating it's triage) to that
effect and a member of the main team will either confirm or
reject (with reasons).
Two problems that might come up here: firstly, we're going to get a lot
of non-triagers saying "me too" or "yes, this is a showstopper for me"
in response to that, which is noise we'll just have to wade through --
that comes with the territory. The second one is to avoid getting lots
of these on a single bug, so we should encourage that if somebody has
posted a "I think this is ready to move" comment, no other proto-triager
should do the same until that's acted on. This sounds complicated, but
it's only an extra bullet point (and a slight rewrite) of the triage
section in the docs.
Malcolm
Simon G.
number of the core devs (the ones that came to mind at least - I'll
dig through AUTHORS later and add the rest), and the triagers. Anyone
else?
--Simon G.
On Mar 6, 10:23 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
Michael Radziej
> On balance, I would prefer that bigger decisions (closing as wontfix or
> moving to "ready for checkin") about tickets are made by a slightly
> smaller, more experienced group, just because it reduces the chances of
> having to back-track all the time. If somebody I don't know closes a
> ticket, I'm basically going to go and do the same work they just did to
> check the result. If somebody from the triage team or another developer
> or release manager does this, I'm typically going to just read the email
> about it, note the ticket title to check for consistency, and move on.
Hmm, for closing as wontfix I'd agree. I'm undecided about "Ready for
Checkin".
> Anybody who is willing to create a non-anoymous Trac session should be
> encouraged to do any one of...
I wholeheartedly agree to this. Triage is a lot of work, and we could
still use more people to help with it. But, please, make it really
carefully, stick to it for more than only a couple of days, or don't do
it at all. Really go through *all* the steps. Triage is a lot more than
just putting a ticket to "accepted" because you like it. Verify bugs and
patches carefully.
But for many tickets you really need to know a bit about the history and
past discussions on the list. So, be careful and, especially at the
beginning, ask for help on the list in unclear cases, or simply skip
these tickets. Someone else will pick them up.
It's important that the triagers maintain consistency. We currently do
this by watching each others' decisions to learn how the others think,
sometimes asking by private mail why they did it that particular way,
and also by discussing larger areas on the list.
I'd have one request: Please, make a "slow start". Don't try to make too
many tickets in the beginning at once. You'll learn a lot from the
reactions of the community, so give them time to react before you make
chaos in too many tickets.
We currently don't have a strong concept of "trusted triager". You have
become a trusted triager as soon as the others have learned your name
and trust you, and don't look up each of your decisions to see if that
ticket is really Ready For Checking ;-)
> - move a ticket from "unreviewed" to "accepted" if they can
> repeat the problem, it's against documented behaviour and is in
> a non-deprecated component.
>
> - mark a ticket as a duplicate of another one, assuming it
> really is a dupe and not just "maybe, might be". If the
> duplicate is not a complete carbon copy and might contain extra
> information, add a note in the surviving ticket as well (along
> the lines of "see ticket #1234 for a similar version of this
> problem").
>
> - close clearly invalid tickets, such as requests for help,
>
> - where a ticket doesn't contain enough information to repeat
> (or understand!) the problem, post a request for more
> information -- and explain the information needed. Drop in a
> note to say this is done as part of triage.
>
> - review patches, whether they be tests -- look for likely cases
> that are missed -- or docs -- read them and see if you
> understand -- or code.
I'd add:
- for Approved or Ready to Checkin:
check patches whether they solve the described problem.
Run the test suite for patches. If relevant, check this for
different database engines.
Michael
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk -
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
Jeroen van Dongen
On a personal level I'll take the advise given to heart for future
contributions.
Rgds,
Jeroen