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

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 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

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.