Flyspray - The bug killer!

This sounds backwards to me: currently, submitters can choose the severity, but managers choose the priority.

I can’t think of a reason why one of those two columns should be hidden from people who can view the task. Can you explain why you think this should be added?

First of all, you need to understand the definition of “Severity” and “Priority”.

“Severity” refers to the degree of effect on the software. This is only useful to developers. In addition, “Severity” is typically only assigned by developers. This instance of Flyspray is incorrectly configured. “Priority” refers to the degree of importance or value placed on the task, such as the desires of a customer or a schedule requirement. Project managers (also producers) deal with priorities. In organized development environments, the project manager(s) determines and prioritizes the distribution of tasks. Non-developers should not be able to submit “Severity” levels, and non-managers should not be able to submit “Priority” levels. That’s the correct method of operation. Reporters should not be concerned with Severities or Priorities.

A defect report regarding a prominent misspelling of the client’s name, for instance, would be properly classified as a low-severity and high-priority task. A defect report regarding an obscure error resulting from psychotic user behavior could be properly classified as a high-severity and low-priority task.

But this narrow focus you’ve on “Severity” and “Priority” is not the issue.  FS#743  concerns providing administrators and project managers a permissions capability for displaying certain columns to certain users, not just Severity and Priority columns to certain users. Currently, Flyspray allows only large-scale permissions for column views. For example, an administrator can access the Admin Toolbox and alter the Look and Feel settings for the installation’s default column view, or a project manager can alter the Look and Feel of a project’s column view; however, the column view cannot be configured per user.

Calm down, I understand perfectly what Severity and Priority are, and what they mean. And I use a very similar example when comparing their two extremes. I’m not narrowly focused on Severity and Priority, they just happened to be the two you mentioned in your description.

While we’re on the subject, I don’t see how this issue can be classified as High severity, but that’s beside the point.

I understand perfectly that you would like to be able (as an administrator/manager) to control what fields are viewable and settable by which groups of users. What I am not understanding is why you think it should work that way. To me, it just sounds complex, confusing, and I can’t think of a single good reason when I would ever use it (beyond the duplication of Flyspray’s current behavior). I’m just trying to understand why this should be done in the first place.

Since you completely misunderstood  FS#744 , describe to me how you think  FS#743  would work.

Morgan: The onus is not on Mac to explain how your requested feature should work. The developers’ task is to try and understand what the users desire, and then consider whether or not to implement said features. It seems to me that Mac is trying to understand the usefulness of a feature that will take many man-hours to implement, but only be used by less than one percent of Flyspray admins.

Now, *you* please explain it to Mac. I suggest you be polite about it, or he is likely to lose whatever interest he has left in this task.

In case my previous comments were unclear, I don’t see a reason why particular fields should be hidden from someone who has permission to view the task. So I don’t have any idea how you think this should work, because I don’t think it should happen at all. Unless you would like to clarify _why_ this is important, and a bit on _how_ you think it should work, I’m going to recommend closing this task, or at least deferring it until there is both a clear need for it and a person who wants to implement it.

I’ve given up on this team. Only one contributor has prior professional experience in quality assurance.

I’ll just wait for 0.9.9 and have my team implement the features that are needed in a *real* QA environment since this team is clearly incapable.