On 3 September 2010 00:51, Danese Cooper <dcoo...@wikimedia.org> wrote: > > 1. Eliminate single points of failure / bottlenecks > 2. Reconfigure into teams designed to encourage faster (shorter > duration) and more accurate projects / deployments > 3. Develop programs to encourage / grow volunteers into paid > staff...recognizing that as a non-profit WMF needs to plan for more > frequent turnover in the Tech department to ensure that we can grow > expertise across the dev community rather than concentrating it in a few > core people. > 4. Restore the balance between community-led and foundation-led efforts > so WMF feels again like a partnership rather than concentric circles of > permission / blame >
I really like item 2. When I was working on MediaWiki related stuff, the main problem I had was working out who to talk to. The answer, if you ask, seems always to be "Tim" — which is not very scalable (brilliant though Tim is). I'd hope that along with an organisation into more formal teams would come a structure where individuals are responsible (either permanently, or on rotation like the chromium) for subsets of MediaWiki/Wikimedia. This would imply that the structure used by the Usability Initiative is something we want to emulate — a few tight-knit teams that can focus on specific concerns, containing people with the power to say "yes" or "no" to particular features/ideas. Having a person responsible for saying "no" is essential; as Danese says, you can't accept every random patch or idea that gets thrown your way, and leaving things languishing forever is less kind than just saying no (ideally with a reason). Hiding behind team decisions is impersonal to the point of rudeness — if I'm committing into your area of interest, I am part of your team. The other advantage of having teams is that it makes it more explicit which areas of development are being focussed on, and by whom. Wikimedia obviously concentrates a reasonable amount on fundraising, which is essential as a means, but it doesn't achieve anything directly. I'd hope that having some kind of explicit structure would expose any less obvious blind-spots — my personal gripe is that no time gets spent on Wiktionary (cf. bug 20246). Clearly there are downsides, cliques are likely to form. I'd certainly regard it as a failure of the system if it stopped someone from doing something merely because they were currently on the wrong "team" — there's not much point in keeping lists of team members, perhaps all that is needed is a team leader (responsible for accepting or refusing changes/ideas), and the team is simple those who are talking to him. In case it's not obvious, I would not make team leaders exclusively employees, but use the meritocracy previously described that would only make it likely that most of them would be. The other sentiment I very much agree with is that more communication should be public — for the simple reason that if I don't know what you're doing, I can't help. Keeping track (however loosely) of what's being worked on is much more efficient than trying to second guess. If the channels we have are too noisy, it's easy to split them by topic. I like the idea of making #mediawiki the support channel, and having #mediawiki-dev for development — this is a model used by lots of projects on freenode. We could even have #mediawiki-offtopic too, if people want to do a lot of misc chatting. Being able to talk to other developers is very useful for getting things done, whereas having some developers who can't be contacted at all by others is very troublesome indeed. I had assumed that it was a requirement for a wikimedia staff member to be somewhere public on freenode — clearly I was mistaken. I hope that items 1, 3 and 4 will become much easier if we solve 2 correctly, and communications will always be improvable. Good luck with your plans, and please keep us updated — I'd much rather have to add you to my spam filter than to not know what's happening. Conrad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
