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