On Wed, Nov 6, 2013 at 10:13 AM, Brion Vibber <bvib...@wikimedia.org> wrote:
> * However, I would consider avoiding using the term "Architect" for its > members as it's easily conflated with existing WMF job titles. I think job > titles are pretty unreliable indicators at the best of times, and of course > can be wildly inconsistent across companies. > [...] > As such, I'd recommend a slightly more formal role for additional "lead > reviewers" or "module owners" in the code review & RFC processes; not as > *gatekeepers* so much as to provide a next-step for getting something > moving that's stalled -- a potential contributor or a team within WMF > working on a feature should be able to easily determine who to talk to > about getting a go/no-go or advice on what to do in case of a no-go. > My thoughts were similar. I thought it might be useful to have a hierarchy of 'architects'. If there are 20 architects, then maybe it doesn't seem like such a big deal. (And maybe they shouldn't be called 'architects' but rather 'module owners'.) Basically, every major piece of WP should have a module owner. For example, gwicke owns Parsoid. Maybe at some point he gets bored and moves on to something else, and names someone else the module owner. (That shouldn't involve any adjustment to WMF salary!) Certain people 'own' larger collections of modules -- like there are subsystem owners in the linux kernel dev world. For example, ideally there should be someone who owns "the WMF deployed mediawiki" who can weigh in on changes which affect the configuration and collection of modules which actually constitute wikipedia. And then there are the big three ("architects") who are really just the top-level module owners (the Linus Torvalds, if you will). I guess what I'm really proposing is subdividing the architectural responsibility further, so that the BDFLs can delegate to the appropriate "subsystem maintainers" more often. Their jobs should mostly be selecting trusted lieutenants, and signing off on the decisions of the lieutenants. The fact that they are currently so overworked means that we haven't really delegated enough authority (or found enough trusted people?). So I guess I'm in favor of getting rid of the "Architect" title and replacing it with a more aggressive and hierarchical use of "Module Owner" (and co-owner). WMF may use the fact that historically someone has been a trusted module owner in setting salary, but handing off ownership should be something *encouraged* not penalized by a salary cut. (If Tim ever wanted to go off and work on a skunkworks project for a while, he should be able to temporarily take off his 'Architect' hat without consulting HR and losing salary.) --scott ps. in the linux-kernel world, "subsystem maintainer" is an excellent title to put on your resume. I don't think we need to be hung up too much on the particular word "architect". We can invent a "Senior Fellow" or some such title if we need to for HR reasons. Let's not conflate technical leadership with salary negotiation. In a meritocracy the former will always precede the latter; we should try to make sure that HR appropriately recognizes the evolving technical situation without unnecessary delay, rather than putting the cart before the horse. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l