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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 520 - Let more people contribute to bug voting
Let more people contribute to bug voting
Product: Wikimedia
Classification: Unclassified
Bugzilla (Other open bugs)
All All
: Lowest trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  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: ---


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 

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.