[isf-wifidog] Best practices for using the ticket system
bock at step.polymtl.ca
Lun 18 Sep 10:07:46 EDT 2006
On Friday 15 September 2006 22:36, Michael Lenczner wrote:
> Pushed send too quickly. I meant to send it with "normal" priority
> and it should be assigned to Auth server - content, not Auth server:
> 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
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
-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
-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
Plus d'informations sur la liste de diffusion WiFiDog