Hi! I am very new here so I would probably be saying a lot of generic things which may or may not apply to the MW situation, if it is the latter please feel free to either ignore, or, much better, educate me on where I am wrong or what I am missing, but I hope it may be relevant.
>> So, where does that leave us? Do we need a BFDL? If so, who should >> pick? Should it be someone in the project? Should the WMF hire >> someone to lead this? If not, do we keep the committee? Do we just >> let this be consensus based? I think BDFL thing hugely depends on the willingness and ability of the person(s) to do the BDFL job over the long term (the FL part :). I have no idea about MW position in this regard, but in general that is a risk. Which can be reduced by replacing a person with a process or organizational structure (which may be, initially or permanently, still including same person(s) but can change if needed without losing function). From this, having a some kind of a committee/group sounds like a good idea to me. > I'm a huge fan of consensus. And even though we've invested the current > committee with the power to decide, they've basically let the process > run by consensus as it should be. So maybe we need less of a BDFL I agree on the consensus point. Extending that, I am a member of a project which has been all in on "governing by consensus" for years. The downside of it is that it starts to be chaotic unless there are means and processes of sampling the consensus, establishing the consensus and resolving the lack of consensus in a clear way that is agreeable and clear to the overwhelming majority of the participants. So the RFC process sounds good here, provided it leads to a definite result (which can be yes, no, redo from start and resubmit, etc. but it has to be clear what is going on and where it is going) and it is predictable and has defined responsibilities and procedures. With the above, though, the architecture committees and the RFCs can serve two purposes, and it wasn't clear for me which one is the one we're looking for (or both?) 1. Technical leadership/stewardship - i.e. "implementing X a good idea because it would make MediaWiki 42% more awesome, yes or no?" I'd say most of everyday RFCs would go here. 2. Planning/prioritization/driving the project forward - i.e. "next year, we want to have X, Y and Z implemented, to lay groundwork for Foo and Bar, and also we dearly need to improve A and phase out B, because that is awful". Something like "Mediawiki 2.0" would be here, I think. These roles are slightly different and the management interaction with these roles should IMO be different too. They may be still served by the same unit, or maybe different units with intersecting sets of people. -- Stas Malyshev smalys...@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
