Also, I'm not sure how priority is decided and what difference it actually makes, but I wanted to recommend that 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.