0003859: Priority should be owned by the Customer! (Reporters) - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0003859	mantisbt	feature	public	2004-05-19 10:43	2014-10-10 17:53

Reporter	Sire	Assigned To
Priority	normal	Severity	feature	Reproducibility	N/A
Status	new	Resolution	open

Summary	0003859: Priority should be owned by the Customer! (Reporters)
Description	This behaviour should be configurable. It should either work as now (developers and above owns the priority), OR the customer (reporters) should own the priority. Reporters should both be able to set priority when reporting an issue, and update it themselves. When using Mantis in external projects, it's always the customer who decides which bugs are most important to fix first. However, when using Mantis in internal projects (like on this site!) it's the developers who decide priority of reported bugs. (Developers and above should ofcourse be able to update priority also).
Tags	No tags attached.

theduke 2004-05-19 17:37 reporter ~0005546	I'll second this recommendation!

brody 2004-05-28 02:13 reporter ~0005613	Also our projects - internal ones - make no use of the priority field, my experience with this feature is, that a customer (reporter) mostly thinks, that its report is the most important to fix. The developer will have another look at this and at least the project leader will prioritize on other more management facts.

Sire 2004-05-28 02:59 reporter ~0005614	If you don't even use the field, I assume you don't have any objections to the change. Remember, this feature doesn't change anything in Mantis unless you configure it to be enabled. I'd like to hear what the Mantis team thinks of this! Am I welcome to make the change myself, and suggest the changes into CVS?

Sire 2005-02-15 04:15 reporter ~0009320	Mantis team, any comments? My team, and I think many other software developers working against customers, would love this feature.

mgerben 2005-02-15 10:55 reporter ~0009322	I disagree. In my experience a tester far too often finds the bug he found to be of tremendous importance. Only the development team has a full overview of all the bugs, they know the impact and they know what bugs have higher priority than others. You can easily run into situations where 'low' priority is never ever assigned because the reporter fears it will not be picked up if it's 'low'. You will also create angry customers when, with respect to all the work you have to do and the overhauls you have planned, you reassign a lower priority to someone's bug. Either the development team or a manager should decide on the priority of bugs.

gtomlin 2005-02-15 11:49 reporter ~0009324	It's necessary to distinguish between "political priority" set by the customer and "workload priority" established by the support organization. If you need both, then maybe you should create a custom enumeration field for one of them, and hide the one used by the support organization to actually prioritize work from the customers. I'm being a bit facetious here, but as brody said most customers will consider their problems to be critical thereby defeating the real usefulness of the priority field.

grangeway 2014-10-10 17:53 reporter ~0041535	This was reported in 2004, it would be good for someone to post some suggested changes against 1.3 that could be easily implemented to resolve this issue.

View Issue Details

Activities