On Jan 15, 2015 8:33 PM, "Chad" innocentkiller@gmail.com wrote:
On Thu Jan 15 2015 at 8:05:18 PM Rob Lanphier robla@wikimedia.org wrote:
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?
The thing about a BDFL is they don't tend to be appointed or picked, they just naturally emerge from the developer community. In that respect, Brion and Tim are MW's BDFLs regardless of what committee they may or may not be a member of.
Are they really? We have a large number of developers at WMF that have no obvious accountability to what either of them says. Neither of them has asserted that power in quite some time and frequently deny any desire to do so.
We could hire someone to facilitate the process perhaps, but it would take a very long time for them to be in a position to really help arbitrate any disputes that may arise. And I would be hard pressed to call them a BDFL as they just haven't been around for over a decade.
What if that person very quickly received the respect of the vast majority of the WMF staff developers, even if they were unpopular here on this list? Given our staff/not ratio, wouldn't our newly minted BDFL win?
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 committee and more of a group who help facilitate RfCs? Such a group could be very fluid (people joining/leaving as they have interest and
time)
and would probably end up with more people from various areas of expertise.
The egalitarian aspects of this are appealing. However, that seems to leave no one really in charge of *making sure* we have forward progress. Instead, this is largely a defensive posture where people are left to figure out which way the winds are blowing, and make sure that whatever they propose is in accordance with that. No one would be specifically responsible for making sure that the RFC queue is full of high-quality, important proposals, and for the rejected proposals, no one would be accountable for coming up with alternative solutions to the problems that the important rejected RFCs were designed to address.
In projects with an effective BFDL, that person feels at least some implicit responsibility and urgency to address the problems identified by erstwhile developers who come up with a misguided solution to a real problem. By "address", I don't necessarily mean "solve", but I think there's a reasonable expectation that someone rejecting a proposal to say something to the effect of "we don't think we should solve problem A using your solution X, because we plan to tackle solution Y in a few months, which solves not only problem A, but also problems B, C, D, and E", or at least "solving problem A really isn't what MediaWiki is about. If that's really important to you, you should use some other software". If the second answer is their answer, then that person should have at least some responsibility to the forward progress of the software, and should be giving that answer because we have a clear direction we are headed in (rather than merely a comfy spot we're nestled in), and the proposed solution takes us off course or slows us down.
Rob