Changes between Initial Version and Version 1 of TicketBestPractices

10/27/06 22:47:31 (12 years ago)

Pull ticket best practices from the mailing list, feel free to edit/comment


  • TicketBestPractices

    v1 v1  
     1> Also,  I'm not sure how priority is decided and what difference it 
     2> actually makes, but I wanted to recommend that 
     3> gets up to "normal" priority. 
     5> "Content types should be displayed with meaningful names instead of 
     6> their class names." 
     8> If I understand that request properly then it, along with the 
     9> request/comment I added underneath it are necessary features to have 
     10> the content features be usable and therefore shouldn't be low 
     11> priority.  But maybe priority is assigned by release goals and content 
     12> might not be important for this upcoming release.  Let me know if I 
     13> misunderstood. 
     15Humm, good point, this is not explained anywhere, and has never been formally  
     16discussed before.  The following is my opinion, and pretty much the way  
     17things currently work.  The tracker in a tool to make the developer's and the  
     18community's job easier, so anyone is welcome to comment on any changes they  
     19would like to see in this. 
     21Priority are assigned by developers.  The priority and milestone given by the  
     22bug submitter is considered a mere suggestion.  Changing priority for  
     23non-developers will at best not matter, and at worst annoy the developers  
     24trying to coordinate efforts.  The proper way to indicate that a particular  
     25ticket is very important to an individual/group is to comment on the ticket  
     26explaining why.  That IS likely to have an impact.   
     28The goal of priority is to give an indication of the priority currently given  
     29by developers to fixing that ticket quickly, in the context of the goals of  
     30the milestone the bug/request is assigned to.  So basically the priorities  
     31and milestone are balanced by: 
     33 * How easy to resolve it is (usually easy => priority+) 
     34 * How disruptive the change is (disruptive => priority-) 
     35 * How likely someone is to commit resources (developer time or money) to fixing it.  (unlikely => priority-, no matter how important the issue objectively is). 
     36 * 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) 
     37 * How many people in the wifidog community care about the bug/feature request (more => priority+) 
     38 * Has the bug been confirmed or reproduced (not-confirmed => priority-) 
     40All of those are subjective, so the priority is also subjective.  The reason  
     41only developpers (or the people who pay them) should change them isn't that  
     42they have perfect knowledge of all those issue, it's very simply that their  
     43individual opinion is, in the end, the only thing that truly will decide in  
     44what order everything is adressed.  It's also what makes priority usefull to  
     45non-developpers: it's should give a realist indication of where wifidog is  
     46headed, at a specific point in time.  As such, it gives them an indication of  
     47what to do if they want a specific thing adressed more quickly in the current  
     48milestone, or moved from a later milestone.   
     50Basically, to increase the priority of a bug, a non-current-developper can: 
     51 * Send a patch  
     52 * Try to convince a current developper tathat the bug should be given more attention.  (Best way is comment on a ticket) 
     53 * 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) 
     54 * Pay a developer to work on it. 
     56Keep in mind that 
     57 * 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). 
     58 * 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. 
     59 * 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. 
     60 * 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. 
     61 * 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. 
     63Note that curently the different priorities (lowest, low, normal, high,  
     64blocker) do not have formal meanings, except for blocker, which means that   
     65the release can't possibly happen without the ticked closed (and normally.  
     66the ticked can't change milestone).  Formally defining them may be a good