Since I have run out of ideas of where to nag devs with shell access (bugzilla is completely ignored most of the time, and mail/irc didn't have much effect either), I'll try here. The following are all one-line configuration changes:
Bug 14716 – Grant noratelimit right to the editor group in the Hungarian Wikipedia (open for over a year) Bug 19109 – Enable AbuseFilter in Hungarian Wikipedia (open for two months) Bug 19315 – Set $wgCategoryPrefixedDefaultSortkey=false on Hungarian Wikipedia (open for one and half month) Bug 19885 – Restore autoreview for confirmed usergroup on huwiki (severity:major, open for 10 days)
It would be really nice if someone could finally take a look at these, especially the last one which completely sabotages the use of FlagRev on huwiki (and which resulted from careless sysadmin action in the first place).
More generally, I think the procedure for responding to site requests (if there is a procedure at all) needs fixing. My impression is that some requests are resolved quickly, and the rest leave the range of whatever method shell people use to monitor new requests, and are never picked up again (much like recent changes patroling on the wiki). Some sort of backlog of open site requests might help the situation. (Again, these are one-liners that need neither much thought nor much effort, nor are they terribly frequent - there were 3 site requests alltogether this year for huwiki, which is a top20 wikipedia - so I'm sure it's an attention problem, not a resource problem.)
convenience links: https://bugzilla.wikimedia.org/show_bug.cgi?id=14716 https://bugzilla.wikimedia.org/show_bug.cgi?id=19109 https://bugzilla.wikimedia.org/show_bug.cgi?id=19315 https://bugzilla.wikimedia.org/show_bug.cgi?id=19885
On Thu, Aug 6, 2009 at 9:39 AM, Tisza Gergőgtisza@gmail.com wrote:
More generally, I think the procedure for responding to site requests (if there is a procedure at all) needs fixing. My impression is that some requests are resolved quickly, and the rest leave the range of whatever method shell people use to monitor new requests, and are never picked up again (much like recent changes patroling on the wiki). Some sort of backlog of open site requests might help the situation. (Again, these are one-liners that need neither much thought nor much effort, nor are they terribly frequent - there were 3 site requests alltogether this year for huwiki, which is a top20 wikipedia
- so I'm sure it's an attention problem, not a resource problem.)
Isn't Rob supposed to be doing these? This should be the full list:
https://bugzilla.wikimedia.org/buglist.cgi?keywords=shell&bug_status=NEW...
There are a lot of things on there that aren't simple fixes, though. Maybe the one-line changes are lost in all the clutter. Things like "Enable .odt upload" or "Install PdfHandler extension" probably need consideration and testing, and things like "Configuration files should have versioning system" or "Support OpenID extension on all wikimedia projects" would require nontrivial development effort.
Perhaps we should make a new component "Configuration requests", mandate that it only be used for simple one-line changes, and ensure that there's a good default assignee who will clear the backlog every workday? Either by making the change, or marking LATER/WONTFIX if it's against policy or doesn't have demonstrated consensus, or changing the component if it's not a simple fix. Something like that. It used to be we didn't really have the manpower to keep on top of shell bugs, but that should no longer be true.
Hoi, Do the creation of new projects qualify as "configuration requests" ? Thanks, Gerard
PS at the moment 5 are in front of the board of trustees.. It would be cool to have them go life by Wikimania
2009/8/6 Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
On Thu, Aug 6, 2009 at 9:39 AM, Tisza Gergőgtisza@gmail.com wrote:
More generally, I think the procedure for responding to site requests (if there is a procedure at all) needs fixing. My impression is that some requests are resolved quickly, and the rest leave the range of whatever method shell people use to monitor new requests, and are never picked up again (much like recent changes patroling on the wiki). Some sort of backlog of open site requests might help the situation. (Again, these are one-liners that need neither much thought nor much effort, nor are they terribly frequent - there were 3 site requests alltogether this year for huwiki, which is a top20 wikipedia
- so I'm sure it's an attention problem, not a resource problem.)
Isn't Rob supposed to be doing these? This should be the full list:
https://bugzilla.wikimedia.org/buglist.cgi?keywords=shell&bug_status=NEW...
There are a lot of things on there that aren't simple fixes, though. Maybe the one-line changes are lost in all the clutter. Things like "Enable .odt upload" or "Install PdfHandler extension" probably need consideration and testing, and things like "Configuration files should have versioning system" or "Support OpenID extension on all wikimedia projects" would require nontrivial development effort.
Perhaps we should make a new component "Configuration requests", mandate that it only be used for simple one-line changes, and ensure that there's a good default assignee who will clear the backlog every workday? Either by making the change, or marking LATER/WONTFIX if it's against policy or doesn't have demonstrated consensus, or changing the component if it's not a simple fix. Something like that. It used to be we didn't really have the manpower to keep on top of shell bugs, but that should no longer be true.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Creation of new projects do indeed fall under site requests. Just make sure to link to consensus that the project is needed/required/approved.
Gerard Meijssen wrote:
Hoi, Do the creation of new projects qualify as "configuration requests" ? Thanks, Gerard
PS at the moment 5 are in front of the board of trustees.. It would be cool to have them go life by Wikimania
2009/8/6 Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
On Thu, Aug 6, 2009 at 9:39 AM, Tisza Gergőgtisza@gmail.com wrote:
More generally, I think the procedure for responding to site requests (if there is a procedure at all) needs fixing. My impression is that some requests are resolved quickly, and the rest leave the range of whatever method shell people use to monitor new requests, and are never picked up again (much like recent changes patroling on the wiki). Some sort of backlog of open site requests might help the situation. (Again, these are one-liners that need neither much thought nor much effort, nor are they terribly frequent - there were 3 site requests alltogether this year for huwiki, which is a top20 wikipedia
- so I'm sure it's an attention problem, not a resource problem.)
Isn't Rob supposed to be doing these? This should be the full list:
https://bugzilla.wikimedia.org/buglist.cgi?keywords=shell&bug_status=NEW...
There are a lot of things on there that aren't simple fixes, though. Maybe the one-line changes are lost in all the clutter. Things like "Enable .odt upload" or "Install PdfHandler extension" probably need consideration and testing, and things like "Configuration files should have versioning system" or "Support OpenID extension on all wikimedia projects" would require nontrivial development effort.
Perhaps we should make a new component "Configuration requests", mandate that it only be used for simple one-line changes, and ensure that there's a good default assignee who will clear the backlog every workday? Either by making the change, or marking LATER/WONTFIX if it's against policy or doesn't have demonstrated consensus, or changing the component if it's not a simple fix. Something like that. It used to be we didn't really have the manpower to keep on top of shell bugs, but that should no longer be true.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Aug 6, 2009 at 1:48 PM, Rob Halsellrhalsell@wikimedia.org wrote:
Creation of new projects do indeed fall under site requests.
...but there's also a specific tracking bug to make everyone's lives easier. :-) https://bugzilla.wikimedia.org/show_bug.cgi?id=16976
Aryeh Gregor wrote:
Perhaps we should make a new component "Configuration requests", mandate that it only be used for simple one-line changes, and ensure that there's a good default assignee who will clear the backlog every workday? Either by making the change, or marking LATER/WONTFIX if
Or perhaps just a new keyword for these one-line config changes? I'm thinking either "oneliner" or "trivial" -- the latter may be usable for two-lines changes as well ;)
Obviously, anyone tagging nontrivial requests with these keywords should have a suitable clue-imparting implement applied to them.
(Or we could use the existing "easy" keyword, if we're not afraid of confusing the "noob developers" with occasional configuration requests in the "easy" bug list. I just checked, and there currently seem to be two open bugs tagged as "easy, shell": 19310 and 19437.)
On Thu, Aug 6, 2009 at 2:12 PM, Ilmari Karonennospam@vyznev.net wrote:
Aryeh Gregor wrote:
Perhaps we should make a new component "Configuration requests", mandate that it only be used for simple one-line changes, and ensure that there's a good default assignee who will clear the backlog every workday? Either by making the change, or marking LATER/WONTFIX if
Or perhaps just a new keyword for these one-line config changes? I'm thinking either "oneliner" or "trivial" -- the latter may be usable for two-lines changes as well ;)
Obviously, anyone tagging nontrivial requests with these keywords should have a suitable clue-imparting implement applied to them.
(Or we could use the existing "easy" keyword, if we're not afraid of confusing the "noob developers" with occasional configuration requests in the "easy" bug list. I just checked, and there currently seem to be two open bugs tagged as "easy, shell": 19310 and 19437.)
-- Ilmari Karonen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Typically, "easy" is reserved for newbie dev stuff. If the shells (ie Rob) don't mind, I'm sure it would be pretty easy to use it for both. Then Rob (or whoever) can have a simple query set up for 'shell, easy' for those 1-line config changes that can easily (through nobody's individual fault) slip through the cracks.
-Chad
On 8/6/09 10:08 AM, Aryeh Gregor wrote:
Perhaps we should make a new component "Configuration requests", mandate that it only be used for simple one-line changes, and ensure that there's a good default assignee who will clear the backlog every workday?
For reference, here's the rough current workflow:
* items get filed into Bugzilla into site requests category * generally a couple folks will peek at it, add the 'shell' keyword or recategorize as appropriate, and add some clarifying comments helping to flesh out the request w/ implementation details or making sure there's consensus * once or twice a week I try to do a quick pass through all the still-open reqs; the ones that are ready to go I'll stick in Rob's queue. Ones that aren't, I may put additional comments on them to ask for clarification. * Rob goes through his assigned queue intermittently between other things
If there are questions about how it works or requests for more detail on consensus, usually these responses are already put on there by the time we reach it.
Some reqs have slipped through the cracks, unfortunately, especially older ones which haven't come up on scans of recent bugs. :(
-- brion
All outstanding requests in the original email for this thread have been addressed and processed to completion.
Now, I am nearly always in IRC, even when I am not at the keyboard. While it is not a permanent solution, everyone should feel free to PM me with any requests that seem to have been outstanding and ready for processing a bit too long. I may not be able to get to them right that second, but I am trying my best! =]
Rob Halsell <rhalsell <at> wikimedia.org> writes:
All outstanding requests in the original email for this thread have been addressed and processed to completion.
The urgent one (autoreview not working, https://bugzilla.wikimedia.org/show_bug.cgi?id=19885 ) is still unsolved, with no activity for days. Sorry for being obstinate about this, but it really is important. It took a lot of effort to convince huwiki patrollers that flagged revisions will be good for them and get them to use it regularly, and now it's been a huge amount of extra work for them, for two weeks. They can't keep up with the load for long, and I'm worried they will get fed up, and the current technical failure will turn into a social failure, and that one is much harder to fix.
Now, I am nearly always in IRC, even when I am not at the keyboard. While it is not a permanent solution, everyone should feel free to PM me with any requests that seem to have been outstanding and ready for processing a bit too long. I may not be able to get to them right that second, but I am trying my best! =]
I contacted RobH@freenode, but got no reply. I'm not sure it was you though, since the user did not identify himself to nickserv, and was not on any Wikimedia-related channel. (The hostmask was n=rob@5ad4934d.bb.sky.com.) If it was you, you should probably set your client to autoident so people can be sure it is you they are talking to. If it wasn't, you can tell nickserv to guard your nick more aggressively by /msg nickserv set enforce.
On Thu, Aug 6, 2009 at 2:34 PM, Brion Vibberbrion@wikimedia.org wrote:
For reference, here's the rough current workflow:
- items get filed into Bugzilla into site requests category
- generally a couple folks will peek at it, add the 'shell' keyword or
recategorize as appropriate, and add some clarifying comments helping to flesh out the request w/ implementation details or making sure there's consensus
- once or twice a week I try to do a quick pass through all the
still-open reqs; the ones that are ready to go I'll stick in Rob's queue. Ones that aren't, I may put additional comments on them to ask for clarification.
- Rob goes through his assigned queue intermittently between other things
If there are questions about how it works or requests for more detail on consensus, usually these responses are already put on there by the time we reach it.
Some reqs have slipped through the cracks, unfortunately, especially older ones which haven't come up on scans of recent bugs. :(
It seems like it would help if there were some way for you/Rob to get a clear list of open issues that should be resolved soon (simple config changes). Currently it looks like some of those get lost in a sea of vague or hard-to-fulfill requests.
wikitech-l@lists.wikimedia.org