Last modified: 2004-09-19 06:14:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2520, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 520 - Let more people contribute to bug voting
Let more people contribute to bug voting
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
Bugzilla (Other open bugs)
unspecified
All All
: Lowest trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-18 16:22 UTC by kissall
Modified: 2004-09-19 06:14 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description kissall 2004-09-18 16:22:44 UTC
No offend. I am just wondering: who has more rights to decide the 
priority for a reported bug? Or everybody has the equal right to change 
it? 

I would say a faster and more convenient navigation bar is always in 
first priority because every user and editor can benefit a lot from it. 
However, I conservatively gave it a normal priority when I reported it 
and now found somebody is even more conserative than me by changing it 
to a lowest. :-)

Since there is already a voting system for bugs. Maybe we can let 
people *regularly* (put a link in "in what you can do" in MetaWiki? ) 
vote for them and derive priority automatically from voting number and 
assign work better based on the vote result. And Let *unregistered* 
users have right to vote is even more better I think. The scale of 1000 
may be changed to other grading scale to accept more general opinions.

The goal: not only just encourage people to report new bugs, but also 
let them say which existing bug is they hate most and which reported 
feature is they want most. MediaWiki developers can then use the poll 
from users to guide what they really need to do.
Comment 1 Jamesday 2004-09-18 21:45:17 UTC
Priorities depend in part on the release schedule for the MediaWiki software and
what affects the Wikimedia and other MediaWiki sites. High priority items could
include items needed for that next release to be on time or bug fixes or
enhancements which will significantly effect the reliability, security or load
handling capability of sites using the software. Low priority are items which
are nice or interesting but do not need to be done in any specific time period. 

Priority is more a measure of time urgency than whether anyone thinks that it is
a good or bad idea.

For all enhancement requests, it's useful or important to point to one or more 
wiki pages showing broad community support, and ideally little opposition to,
the request. Requests without that supporting documentation are much less likely
to be done, particularly if they affect the appearance of the site, which is
often a subject of great controversy.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links