hello.
we currently have some problems with identifying current issues on the site, and knowing what needs to be done, and so on. i've decided it would be a good idea to spend some time on 'management' stuff like this, so i'm trying to come up with a suitable procedure to make sure things work smoothly.
as such, i'd like to propose a new way to manage issues:
the primary point of contact for site issues will be the existing NOC ticket system, noc@wikimedia.org. users should mail this address with any technical issues *relating to the Wikimedia sites* (i.e., it does not replace bugzilla for MediaWiki). confirmed issues will be moved to the new "issues" queue by the "issues manager" (well, you know everyone needs a title). this will also apply to requests from developers; for example, things that need to be done by the on-site developer (previously Chad), and other developers (paid developers in particular).
the issues manager can then formulate a list of tasks required to resolve each issue, and place them on a wiki page somewhere (probably split by particular people, and tasks for all developers). there's then a central place to look to know what needs to be done. further, this can be used to produce a list of open and resolved problems on the site, and what was done to fix them, to keep users and the board better informed of what's going on. (for example, a weekly 'issues summary' mail to the list).
this can also be used as central point of contact for communications with outside partners, such as Kennisnet and Lost Oasis (although purely for technical matters, not negotiations).
unless anyone has strenuous objections to this, i'd like to try it immediately; we can see how well it works, or whether anything needs to be changed. as i'm not doing much actual developer work recently, i'll probably take on the role of issues manager...
any comments appreciated.
regards, kate.
Kate Turner wrote:
hello.
we currently have some problems with identifying current issues on the site, and knowing what needs to be done, and so on. i've decided it would be a good idea to spend some time on 'management' stuff like this, so i'm trying to come up with a suitable procedure to make sure things work smoothly.
as such, i'd like to propose a new way to manage issues:
the primary point of contact for site issues will be the existing NOC ticket system, noc@wikimedia.org. users should mail this address with any technical issues *relating to the Wikimedia sites* (i.e., it does not replace bugzilla for MediaWiki). confirmed issues will be moved to the new "issues" queue by the "issues manager" (well, you know everyone needs a title). this will also apply to requests from developers; for example, things that need to be done by the on-site developer (previously Chad), and other developers (paid developers in particular).
Hi,
As I understand your plan, 'Wikimedia web' product on bugzilla will be closed/deleted and bug moved to otrs. What about an issue reported to the noc that then need to be moved to bugzilla ?
Looks like dev/sysadmin will have to look at both interfaces if they want to get the full history of the problem.
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.
the issues manager can then formulate a list of tasks required to resolve each issue, and place them on a wiki page somewhere (probably split by particular people, and tasks for all developers). there's then a central place to look to know what needs to be done. further, this can be used to produce a list of open and resolved problems on the site, and what was done to fix them, to keep users and the board better informed of what's going on. (for example, a weekly 'issues summary' mail to the list).
Isn't what http://wp.wikidev.net/ is for ? Some troublechecking guide would probably be useful.
this can also be used as central point of contact for communications with outside partners, such as Kennisnet and Lost Oasis (although purely for technical matters, not negotiations).
noc@wikimedia.org looks like the 'normal' way to contact netadmins :)
unless anyone has strenuous objections to this, i'd like to try it immediately; we can see how well it works, or whether anything needs to be changed. as i'm not doing much actual developer work recently, i'll probably take on the role of issues manager...
Maybe you can start writing some documentation about the server farm, the kennisnet cluster, the way stats are generated ... That should ease the issue management.
Just one last thing: what about issues being reported on IRC ? Should users be redirected to the new interface ? If so we might as well moderate the channel.
cheers,
Ashar Voultoiz wrote:
As I understand your plan, 'Wikimedia web' product on bugzilla will be closed/deleted and bug moved to otrs.
i've created a new bugzilla product, "Issues". i don't think "Wikimedia websites" will disappear, since it's still a reasonable method to report problems, whereas Issues is only editable by developers.
bugs get opened in issues when someone sends a problem report to OTRS. at the moment they're assigned to me, but i'll probably create another mailing list (announce-only, like wikibugs-l) for it.
What about an issue reported to the noc that then need to be moved to bugzilla ?
someone can open a bug in bugzilla on behalf of the person who mailed noc about it. (or just tell them to do that.. as long as it gets moved somehow).
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.
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).
the issues manager can then formulate a list of tasks required to resolve each issue, and place them on a wiki page somewhere (probably split by particular people, and tasks for all developers). there's then a central place to look to know what needs to be done. further, this can be used to produce a list of open and resolved problems on the site, and what was done to fix them, to keep users and the board better informed of what's going on. (for example, a weekly 'issues summary' mail to the list).
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).
this can also be used as central point of contact for communications with outside partners, such as Kennisnet and Lost Oasis (although purely for technical matters, not negotiations).
Just one last thing: what about issues being reported on IRC ? Should users be redirected to the new interface ? If so we might as well moderate the channel.
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_...
kate.
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,
wikitech-l@lists.wikimedia.org