robchur wrote:

Report upstream as applicable.

(In reply to comment #1)

Report upstream as applicable.

Upstream? this are "local" changes, not "upstream" changes.

robchur wrote:

(In reply to comment #0)

The Priority field should be changed to have less ambigious field. I would
suggest simlar fields as the default mantis installation:

If you don't understand the priority and severity fields, don't mess about with
them. They're not for end users to play with, anyway; they're there for us to
set a level as we see fit to organise this stuff.

Also from mantis, a field defining reproducibility:

*always
*sometimes
*random
*'''have not tried'''
*unable to reproduce
*N/A

This isn't Mantis. Reproducibility of bugs can be detailed in the comment;
ideally, one-off cases will be closed as not-bugs anyway.

The field Platform/Hardware is in my opinion irrelevant, better to change it to
something relevant, like a field for used browser.

Well, it's not irrelevant in all cases. It's not irrelevant when users are
reporting incompatibilities which arise on different systems. It's not
irrelevant for server-side stuff. It's not really irrelevant at all, in fact.

The system for voting for bugs seems to be useless (is there any dev that goes
after the votes anyway).

It's a useful "watchlist" feature, I find.

We've got bigger fish to fry than to mess about with BugZilla...

I understand the priority field, but most people don't, thats why I suggest to
rename them to something less ambiguous. And I know this isn't mantis, I just
took the examples from there.

Please don't close a bug, just because you dislike some part of it. it's not
fair to others.

robchur wrote:

Who cares about fairness? It's not about that, it's about not wasting time and
about things making sense.

ayg wrote:

One thing that *would* be useful is tweaking some of the component names,
because their meanings often aren't immediately obvious even if the intended
meanings (as listed in the component descriptions) are sensible divisions of
requests.

Wikimedia/Site requests -> Site creation
Wikimedia/Language setup -> Site configuration (actually this apparently
includes setting up new languages at present, but it makes more sense to have a
dedicated field for the overwhelmingly most common Wikimedia-product request)
MediaWiki/Page rendering -> Wikitext rendering

As for priority, that field *is* definitely useless. There are about five bugs
in the system whose priority was actually set by devs to something other than
Normal. Actual priority is set by every dev for himself, and is manifested in
bugs being self-assigned. The field mainly serves to give Rob, me, and other
anal-retentive people an excuse to clog up wikibugs-l.

(In reply to comment #0)

The system for voting for bugs seems to be useless (is there any dev that goes
after the votes anyway).

Yes. At least sort of. I often find it convenient to order by number of votes
when searching for bugs, too. And it hopefully gives us somewhere to send
people who would otherwise be inclined to post "FIX THIS BUG NOW IT'S REALLY
IMPORTANT". Plus, it's a watchlist that doesn't spam everyone who's watching it
telling them you added the bug to your CC list.

about the graph problem, seems to be a permission problem on the server:

[0:1][azatoth@azabox tmp]$ wget
http://bugzilla.wikimedia.org/data/webdot/d8RSx6TUcO.dot.map
--20:14:20-- http://bugzilla.wikimedia.org/data/webdot/d8RSx6TUcO.dot.map

=> `d8RSx6TUcO.dot.map'

Slår upp bugzilla.wikimedia.org... 145.97.39.130, 2001:610:672:1:145:97:39:130
Connecting to bugzilla.wikimedia.org|145.97.39.130|:80... ansluten.
HTTP-begäran skickad, väntar på svar... 403 Forbidden
20:14:20 FEL 403: Forbidden.

One issue per bug please. I am creating new bug for
comment 6 (bug 9952) and comment 7 (bug 9953).

Reclosing bug as per comment 3 by Robchurch.