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
