Στις 03-09-2010, ημέρα Παρ, και ώρα 05:34 -0700, ο/η Conrad Irwin έγραψε: > On 3 September 2010 00:51, Danese Cooper <[email protected]> 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.
I think of the "who to talk to" issue (which in part reduces to a "who can officially sign off on your code so it may be deployed" issue) as #1, bottlenecks. Over the past few years that I have been involved in various ways in the Wikimedia projects, I have seen people give up after waiting a couple of years for their code to make to the deployable stage. This in term impacts both #3 (getting/attracting volunteers who can later turn into paid staff) and #4 (dynamics between WMF and the community, to the extent that WMF staff are not considered community members. It sort of puts a new spin on the old "If you want it done, write it yourself because we are too busy" line. When writing it yourself (and being willing to revise it until it's considered good) isn't available as an option any more, an open source project is rather less open. I know that is by no means the only bottleneck we have; it's just the one that looms large in my mind at the moment. > 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. Having teams responsible (and with authority) for different areas, able to approve features and code, sounds fabulous. I know we are moving towards broader team structure already. Ideally there might be more than one person on each team who could give the thumbs up/down. > 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'm one of those who posts almost never to this list (in fact almost never to any list, I have an allergy :-P). However I live in IRC in public channels where anyone can and does find me. Between those two sets of tools, I would hope that everyone could be similarly available and that their development processes would be accessible for public participation. A brief comment about closed mailing lists, since this has come up a few times: We have a mailing list that is typically used for operations matters. I'm not sure how much of that *has* to be private but I am sure some of it does: things like Sun contract numbers and invoices don't belong on a public mailing list. If we were to close it, we would simply have to find another way (less convenient I suppose) to communicate that same information. AFAIK we don't have a s3krit mailing list for development. (Now someone will prove me wrong by revealing the existence of wmfdevcabal-l. :-P) > 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. We hope to produce enough quality spam to keep you and everyone else happy :-) Ariel > Conrad > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
