Kate wrote:
Looks like dev/sysadmin will have to look at both interfaces if they want to get the full history of the problem.
well, the idea is that only one person has to look at OTRS, and any other developers can see all current issues in bugzilla (via the Issues product). the reason i used OTRS for that is to act as a 'filter' between users reporting problems, and extracting actual issues which need to be solved from that.
I fully understand the need for filtering issues but bugzilla got an UNCONFIRMED status (actually disabled) that can probably be used for that. Instead of using OTRS to filter new requests, we could search for bugs in product 'Wikimedia Web' with status 'UNCONFIRMED'.
Then either the issue is: - confirmed and a dev mark it as NEW, eventually correct the subgroup, severity and priority - the issue is resolved and dev resolve it as wontfix/worksforme/invalid.
Is there any software for mail <> bugzilla gateway ? That will allow us to bypass OTRS entirely.
You can probably set up bugzilla to have several virtual admin teams (dns, squids, apaches, hardware, kennisnet). All new messages could be assigned to the issue manager with an 'unconfirmed' status he will then give out the bug to one of the virtual teams that can then deal with the problem.
would each team be a mailing list? i was thinking of an all-developers@ list to assign bugs to by default (at the moment they're assigned to me, but that's not a very good solution).
New unconfirmed bugs should probably be assigned to an all-developers mailing lists. But issues concerning squids (for example) should only send notification to developers that actually manages or know about squid. Same for dns, apaches, perlbal, database dumps etc..).
It's more an internal issues among developers, actually we are like a big group supposed to manage everything when its not the case. Some devs do not have root access, some do not know about DNS, some other know only about squid (that last example is fictional).
I think the main issue is our organisation, we should stop acting as a 'wikidev' group and split in virtual teams instead. Then we can assign issues to the virtual teams and give rights to those teams on servers.
A really simple and _fictional_ example: - devA got root access to manage database backup but don't know how DNS work. It happens devA made some modification to DNS and made the site for some unaccessible for sometime, he also crash squids from time to time when trying stuff. - devB know alot about DNS but does not have root access, he doesnt know about mysql.
Solution: - create a mysqldev group, remove devA root access and assign him in mysqldev group - assign devB in dnsdev group.
Issues about dns will be moved from developer-all to the dnsdev team and devB will receive notification when devA will receive nothing. Same for mysql issues that will be sent only to devA and not to devB.
I really think we should get ride of the actual way of doing things (aka wikidev for somestuff, root access to change configuration, and every developers seen as the same big team). Your proposition is a good step for that :)
Isn't what http://wp.wikidev.net/ is for ? Some troublechecking guide would probably be useful.
i was going to use wikidev for it, but i think it's more useful for that to go on bugzilla now. of course, documenting things on wikidev is still a good idea ;-) (and the server admin log shouldn't go away).
Bugzilla should only be about solving issues. Documentation should really be on a different tool unless bugzilla got a kind of faq-o-matic pluging that could let us create documentation (but probably a mediawiki installation such as wikidev is a better idea as you wrote).
If there is an interesting bug that can be later referenced, it should be rewrote cleanly and added as a FAQ/HOW-TO on wikidev. That will let developers enhance it later instead of adding comments in a bug report. Example: developer willing to correct a comment will probably add a comment like "comment #3 is wrong, use foobar instead", if its comment #54, one dev will probably use the command in comment #3 before figuring its wrong).
well.. if people want to report issues via IRC, it's fine, but i think the general attitude should be that if it's not sent to noc@, there's no guarantee it'll get fixed. the user doesn't have to do that, of course
- a developer who happens to be on IRC, or whatever, can open a new
ticket. i definitely don't want to start ignoring people trying to report problems, however they do it, since the idea of this is to make it _easier_, not _harder_...
Totally agree.
I will be out until monday or wednesday.
cheers,