[isf-wifidog] Best practices for using the ticket system

[Benoit Gregoire]

On Friday 15 September 2006 22:36, Michael Lenczner wrote:
> http://dev.wifidog.org/ticket/248
>
> Pushed send too quickly.  I meant to send it with "normal" priority
> and it should be assigned to Auth server - content, not Auth server:
> Authentication
>
> Also,  I'm not sure how priority is decided and what difference it
> actually makes, but I wanted to recommend that
> http://dev.wifidog.org/ticket/243 gets up to "normal" priority.
>
> "Content types should be displayed with meaningful names instead of
> their class names."
>
> If I understand that request properly then it, along with the
> request/comment I added underneath it are necessary features to have
> the content features be usable and therefore shouldn't be low
> priority.  But maybe priority is assigned by release goals and content
> might not be important for this upcoming release.  Let me know if I
> misunderstood.

Humm, good point, this is not explained anywhere, and has never been formally 
discussed before.  The following is my opinion, and pretty much the way 
things currently work.  The tracker in a tool to make the developer's and the 
community's job easier, so anyone is welcome to comment on any changes they 
would like to see in this.

Priority are assigned by developers.  The priority and milestone given by the 
bug submitter is considered a mere suggestion.  Changing priority for 
non-developers will at best not matter, and at worst annoy the developers 
trying to coordinate efforts.  The proper way to indicate that a particular 
ticket is very important to an individual/group is to comment on the ticket 
explaining why.  That IS likely to have an impact.  

The goal of priority is to give an indication of the priority currently given 
by developers to fixing that ticket quickly, in the context of the goals of 
the milestone the bug/request is assigned to.  So basically the priorities 
and milestone are balanced by:

-How easy to resolve it is (usually easy => priority+)
-How disruptive the change is (disruptive => priority-)
-How likely someone is to commit resources (developer time or money) to fixing 
it.  (unlikely => priority-, no matter how important the issue objectively 
is).
-How bad it would be if the ticket isn't fixed, in the context of the current 
milestone.  1.0 is an architecture/basic functionnality milestone, so UI 
issues take lower priority if they are mainly cosmetic.  (no functional 
difference -> low or lowest priority)
-How many people in the wifidog community care about the bug/feature request 
(more => priority+)
-Has the bug been confirmed or reproduced (not-confirmed => priority-)

All of those are subjective, so the priority is also subjective.  The reason 
only developpers (or the people who pay them) should change them isn't that 
they have perfect knowledge of all those issue, it's very simply that their 
individual opinion is, in the end, the only thing that truly will decide in 
what order everything is adressed.  It's also what makes priority usefull to 
non-developpers: it's should give a realist indication of where wifidog is 
headed, at a specific point in time.  As such, it gives them an indication of 
what to do if they want a specific thing adressed more quickly in the current 
milestone, or moved from a later milestone.  

Basically, to increase the priority of a bug, a non-current-developper can:
-Send a patch 
-Try to convince a current developper tathat the bug should be given more 
attention.  (Best way is comment on a ticket)
-Propose a detailled, simple solution (you don't necessarily need to be a 
developper, several UI-bugs are lingering in the tracker not because the 
developpers don't realise the issue, but because the solution the can 
immediately think of isn't much better than the current state of things)
-Pay a developer to work on it.

Keep in mind that
-Even low priority things are scheduled to be adressed as the milestone they 
are part of (though they may not block it if they are the only thing 
preventing it's completion).
-Some tickets depend, directly or indirectly on other tickets (or even things 
that do not have tickets).  For example, several access control technical or 
UI issuess are currently on hold pending a decision on wether or not the new 
role system will make it into 1.0.
-The goal of the ticket system is to open part of the software engineering 
process to the community.  But it is important to remember that it's finality 
is actual changes in code and documentation.
-The ticket system isn't a forum.  The comment system is there to clarify and 
collectively understand the issue at hand, and determine a solution.  Debates 
(importance, nature of the issue) should move to the mailing list if there is 
repetitive disagreement.
-It is frequently necessary for developpers to re-title tickets.  This is 
normal.  However, should a developper edit the description of the ticket 
(frequently because the submitter didn't understand the real nature of the 
issue), he should keep the original text at the end of the description, 
unless his corrections are mere clarifications.

Note that curently the different priorities (lowest, low, normal, high, 
blocker) do not have formal meanings, except for blocker, which means that  
the release can't possibly happen without the ticked closed (and normally. 
the ticked can't change milestone).  Formally defining them may be a good 
idea.