On Thu, Aug 6, 2009 at 9:39 AM, Tisza Gergő<gti...@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&bug_status=ASSIGNED&bug_status=REOPENED 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
