Rob Lanphier wrote: >So, here we are today. I believe no one would dispute the credentials >of every member of the group. Brion, Tim, and Mark have an extremely >long history with the project, being employees #1, #2, and #3 of the >WMF respectively, and all having contributed massively to the success >of Wikipedia and to MediaWiki as general purpose wiki software. In >most open source projects, one of them would probably be BFDL[5]. >Roan and Daniel are more "recent", but only in relative terms, and >also have very significant contributions to their name. All have the >widespread respect of pretty much everyone in the MediaWiki developer >community.
Yes, absolutely. My general thoughts: * I really like and respect the five people on the committee, but from my perspective, it's only been one person actively involved most often. ** Perhaps the weekly meeting time is bad. ** Perhaps people on the committee can't commit to the necessary time and we need to find other trusted, senior developers. * As the number of projects and size of Wikimedia development grows, it's even more important to have people looking at the big picture. * The weekly IRC meetings are hugely valuable. Whether or not we continue to have an Architecture Committee, we should continue holding these weekly meetings. ** The scope of these weekly meetings should always be clearly defined, but it doesn't need to be limited to purely RFCs, per se. As this most recent week's meeting demonstrated, not every discussable idea must be shoehorned into the "Requests for comment/" pseudo-namespace (not that there's anything wrong with that). ** We need more people involved in discussions about and scrutinizing the components of big ideas (including people like Rob!). I'm getting increasingly concerned that really smart people such as Brion and Roan and others are not looking at and poking holes in the larger ideas being proposed. (Or, more worryingly, bigger ideas aren't even being proposed and instead are skipping straight into implementation.) Architectural review is most definitely needed in some areas and a lack of upfront discussion and criticism and debate is going to result in a lot of future pain. Poor planning leads to poor execution. Doing everything twice (badly the first time, better the second) is really costly and we simply have too many ideas to be paying double for them. Instead, we need to find the larger patterns in order to build the most modular and scalable solutions. This requires lots and lots of thinking. >Still, the uncomfortable shrugging continues. The group is broader, >but still lacks the breadth, particularly in front end and in the >development of newer services such as Parsoid and RESTBase. This >aspect is pretty obviously something that can be fixed. Another >problem is that the scope of the group isn't clear to everyone. Is >this group responsible for leading, or merely responsible for >reviewing big ideas from others to ensure continuity and sanity? How >big does an idea need to be before an RFC needs to be written (as >opposed to just dropping a patch in Gerrit)? Defining the scope of >the group is also a fixable problem. Thanks for expressing two problems that you see. For the first, we can always add people if certain areas are lacking. I agree that having someone a bit closer to the design/front-end side would be good, though I'm not sure how many trusted, senior people we have in that area. The scope of the group is to discuss concrete, cool ideas for Wikimedia development and try to move them forward. Some of these ideas are supported by the Wikimedia Foundation, others are supported by volunteer developers, but that's irrelevant as it's a forum for ideas alone. Architectural guidance is hugely important in technical projects, so having a weekly forum to hash out ideas and look for potential security or performance or design or community concerns is a Very Good Thing, in my opinion. I don't think this is a hard sell. >However, I don't sense much of a desire to fix things. The dominant >meme that I hear is that we should go back to the day before >uncomfortable shrugging led to a committee becoming BFDL. What I >fear, though, is that we will develop a system lacking in conceptual >integrity[6], as individual warring fiefdoms emerge. It's quite >simple to argue this is already happening. Right, I think this is the third problem you've identified. We're definitely already seeing the formation of fiefdoms. This should be addressed. Requiring architectural sign-off for large projects is worth at least considering. We currently require security and performance sign-off prior to deployment to Wikimedia wikis. Requiring architectural sign-off (much earlier than deployment, obviously!) wouldn't be unprecedented. >Team-level pride in fantastic work drifts into project-level despair, as >many excellent engineers fail to grasp how to make big changes outside of >their limited domains. Respectfully, this is garbage. Excellent engineers don't have a problem moving their ideas forward. Why? Because excellent engineers carefully study and interact with a project until they're comfortable with it and secure in the knowledge that they understand it well enough to improve, rather than hurt, the project. The people who struggle to move their ideas forward are the ones who don't understand wiki projects or wiki culture. It's really difficult to build tools and scripts and interfaces for projects that you don't use and that you don't understand. >Perhaps I'm also suffering from living inside the WMF echo chamber for >too long. It could be that the general pessimism about the direction >of MediaWiki (or lack thereof) is not shared out here. What general pessimism? I don't see evidence to support such a claim. MZMcBride _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
