Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Tyler Romeo]

On Mon, Nov 11, 2013 at 1:51 AM, Tim Starling wrote:

> My concern with this kind of maintainer model is that RFC review would
> tend to be narrower -- a consensus of members of a single WMF team
> rather than a consensus of all relevant experts.
>

I'd also like to point out that we can still implement a maintainer system
without changing the RFC process. There's no requirement that RFC review
and maintainers be the same people. This thread is mainly a discussion
about "Architects" (or the concept thereof), and how we might want to
change the MediaWiki code review structure.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[C. Scott Ananian]

On Mon, Nov 11, 2013 at 1:51 AM, Tim Starling wrote:

> On 08/11/13 03:40, C. Scott Ananian wrote:
> > Basically, every major piece of WP should have a module owner.
>
[...]

> > 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).
>
> My concern with this kind of maintainer model is that RFC review would
> tend to be narrower -- a consensus of members of a single WMF team
> rather than a consensus of all relevant experts.
>

To clarify, I wasn't actually suggesting that RFCs would be reviewed by the
minimal set of module owners.  The opposite, actually: I think that
explicitly creating a hierarchy of ownership would allow the review process
to efficiently progress from narrow to broad focus, ensuring that neither
end gets short shrift.  The line down the tree from "big three" to "person
who last touched a particular file" is a way to capture everyone who is
relevant to an RFC, making sure that neither the forest nor the trees are
neglected.  The main thrust is to flesh out the middle levels of the
hierarchy, lieutenants who have a moderately broad focus and who are
trusted to offload some of the work from the top 3 architects.  The top
three would still weigh in, but hopefully they can concentrate on the
broadest scale issues and wouldn't have to do as much of the heavy lifting.

I'm not proposing that RFC review should be done solely by the narrow-focus
people who happened to last touch the affected files, obviously.

That said, this is a relatively minor point; it seems we've reached good
consensus regarding the bigger picture decoupling of architectural
responsibilities and job titles.  Quibbling over the number and scope of
'architects' can be deferred (esp since the big 3 don't seem to be loudly
complaining of overwork at present).
  --scott

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Gabriel Wicke]

On 11/10/2013 10:51 PM, Tim Starling wrote:
> On 08/11/13 03:40, C. Scott Ananian wrote:
>> Certain people 'own' larger collections of modules -- like there are
>> subsystem owners in the linux kernel dev world.
> 
> My concern with this kind of maintainer model is that RFC review would
> tend to be narrower -- a consensus of members of a single WMF team
> rather than a consensus of all relevant experts.

I am skeptical about such a narrow maintainer model too.

Architecture should have a broader perspective than one module at a
time. An important part of the role of architects is driving a consensus
process both in the foundation and also in the larger MediaWiki
community about how modules should interact and maybe also which modules
we need, especially in the back end. They should also make sure that
longer-term global issues are considered before they become pressing.

Like others, I see WMF job titles fairly separate from roles in the
wider MediaWiki community. The goals of the foundation are also not
always the same as those of each member of the community. Wikia for
example might have priorities that differ from somebody running
MediaWiki in an intranet. Because of this, I think it would help to
separate the issue of MediaWiki governance from that of Wikimedia
Foundation roles and architectural leadership within the Wikimedia
Foundation.

Within the Foundation I can see advantages to holding more people
responsible for looking out for architectural issues, just to make sure
it happens and scales. I don't think that it matters much *internally*
whether those are called 'principal engineer' or 'architect'. Lets use
the title whose common definition fits the actual role most accurately.

Gabriel

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Matthew Flaschen]

On 11/08/2013 12:00 PM, Bryan Davis wrote:

I think the second is more consistent with the tenor of the discussion
here so far, because in the first case, the coupling between job
titles and responsibilities in our community might be too tight to
maintain flexibility and openness. It would also recognize that
technical leadership doesn't _just_ mean taking on broad architectural
responsibilities. So for example development of unique and
mission-critical domain expertise might be another way to progress
into Sr. II.


I personally think this route (separating the role of architectural
leadership from the title/pay band of WMF employees) is the most
reasonable way forward.


+1 on separating WMF job titles with community technical leadership 
positions.  This will work best if it applies to the current architects too.


I.E. all three are changed to Principal Platform/Software/Operations 
Engineers on the WMF side, while remaining architects on the MW side.


I like the "Principal Software Engineer" and "Senior Fellow" suggestions 
for the WMF part.


Matt Flaschen


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Matthew Flaschen]

On 11/06/2013 06:35 AM, Antoine Musso wrote:

I would have a look at the way IETF is handling its RFC process. I wrote
about it back in July in the thread "proposed RFC process":

  http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070241.html


The IETF does have a long, successful track record.  But I'm not sure 
this is really a good fit for a single software project.



The workflow is as bureaucratic as you can imagine given the number of
parties involved and all the political / commercial context that goes
behind creating internet standards. You can still achieve a RFC pretty
"quickly".


It has to be more structured, since the scope is so big.  The IETF's 
overall scope is basically, "Any standard relevant to the Internet", so 
they can't simply let the whole technical community on every issue on a 
single mailing list.  First, people who are experts in audio codecs 
(https://tools.ietf.org/html/rfc6716) are a very different set from the 
QoS experts (https://tools.ietf.org/html/draft-ietf-dime-qos-parameters).


MW is much smaller, so it doesn't have the same problem.  Such working 
groups could work here, but we wouldn't want a new group every time 
there was an RFC.  However, having front-end working groups, database 
working groups, Wikidata working groups, etc. might work.



https://www.mediawiki.org/wiki/Requests_for_comment/LESS

Working group was Ori Livneh, Jon Robson, Steven Walling. They came with
a draft and implementation after a few review cycles.

Along the process Brion stepped in to offer technical reviews/guidance.

Brion eventually accepted it by marking the RfC complete and merging the
implementation.


I don't think this example supports the need for formality.  In this 
case, Ori proposed a POC change, the RFC was created to document why it 
would be useful and discuss the proposal, a lot of people commented on 
both the code and the RFC, and Brion eventually merged it.


I don't think it would have been better with more discussion before 
coding, or with more formality (e.g. who is in the working group, versus 
just a participating engineer).


Matt Flaschen

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Matthew Flaschen]

On 11/06/2013 05:50 AM, Ori Livneh wrote:

What you are proposing is that we determine who is infallible and
benevolent, so we can style them dictators for life. This kind of
wide-eyed earnestness about the term "architecture" is very dangerous.
It misses the essential irony, and in so doing it risks transforming
an institution which satirizes (and thus curbs) inscrutable authority
with one that enshrines it.


We don't have any benevolent dictators for life in MediaWiki currently. 
 The three architects don't really fit that term.


They do have the final call on whether an RFC should be done (which as 
you say is good, both because they have experience, and because 
sometimes we just have to choose without endless discussion).  However, 
other important community decisions (most notably +2 rights) are made by 
the broader community of developers.


I don't see anyone saying we need a BDFL currently, or that architects 
are infallible.


As far as what we should do, I think the status quo is okay for now. 
It's worth thinking about making more people architects (or replacing a 
slot if one of the current ones leaves), but it's not currently urgent.


Matt Flaschen


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Tim Starling]

On 08/11/13 03:40, C. Scott Ananian wrote:
> 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).

My concern with this kind of maintainer model is that RFC review would
tend to be narrower -- a consensus of members of a single WMF team
rather than a consensus of all relevant experts.

The module maintainer is not necessarily going to know all of the
potential relevant experts from across the organisation and the
community. Someone who has experience in soliciting comments across a
wide range of RFCs is more likely to choose a wide range of commenters
for any given proposal.

-- Tim Starling



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Tim Starling]

On 06/11/13 12:57, Erik Moeller wrote:
> However, Brion, Tim and Mark are not infinitely scalable, nor are they
> immortal (except in our hearts). They can’t be in every conversation,
> know every part of Wikimedia’s technical ecosystem, review every RFC,
> etc. 

Well, we can't be in every conversation, but I think we could probably
review every RFC, on some level of detail.

Obviously we can't identify every potential technical issue in every
RFC. RFC review should be a process of gathering comments from people
with relevant technical expertise, and then making a decision on the
basis of the consensus of those experts. Personal judgement should
rarely be required.

There is obviously a need for people to drive the process -- and since
driving the process is time-consuming, the people who do it will
probably have time allocated for the purpose by their managers. This
is the reason for the current connection between RFC review and WMF
management.

I'm not sure if I'm the ideal person to organise meetings, solicit
comments, ensure that action items are completed, etc. It hasn't
traditionally been my core competency. But I'm sure that the amount of
time required could be met by a very small group of people.

> We also have many other deeply talented technical contributors,
> including some who have many years of experience in our technical
> context specifically -- not just at WMF. Beyond just making technical
> decisions, architectural leadership creates opportunities for
> mentorship, modeling and nurturing the kind of behavior we want to
> foster in our technical community.

I think the best way to respect technical talent is by consensus
decision making -- that is, objections made by actively involved,
technically competent participants should be addressed by modification
or rejection of the proposal.

Leaders are still needed, to evaluate consensus, and to make a
decision as a last resort in the case of intractable conflict. Such
leaders should have the respect of the community. An RFA-style process
would be one way to ensure that leaders have that respect.

I understand from comments in this thread that an RFA-style process is
generally not a popular solution. An alternative is to have WMF
carefully choose people to lead the RFC process, taking into account
the amount of respect the community is likely to have for them.

-- Tim Starling



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[rupert THURNER]

On Wed, Nov 6, 2013 at 2:57 AM, Erik Moeller  wrote:
...
> in March 2011 and June 2011, Brion Vibber, Mark Bergsma and Tim
> Starling were announced as Lead Software Architect, Lead Operations
> Architect and Lead Platform Architect of the Wikimedia Foundation,
> respectively.

> At WMF, this has increasingly raised the question how the architecture
> of Wikimedia’s technical infrastructure can be evolved at this new,
> larger scale, and how we can bring more voices into that conversation.
> I've shared this note with the architects ahead of time and taken some
> initial feedback into account.

> So how should this role evolve going forward? Some possible paths (you
> know I like to present options ;-):
...

> Option D: We come up with some kind of open process for
> designating/confirming folks as architects, according to some
> well-defined criteria (including minimum participation in the RFC
> process, well-defined domain expertise in certain areas, a track
> record of constructive engagement, etc.).

besides beeing technically very capable, mark, brion, and tim are
really nice persons on a personal level. they stay out of political
discussions, are not arrogant, always concentrate on helping to evolve
technically, and do not shy away from dirt work. as imo people tend to
attract theirlikes, i would see also an option that each of them is
allowed to choose the person who helps in their respective domain.

but, if you think its better to take option D, and mark, brion and tim
think this helps i am all for it.

rupert.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Erik Moeller]

On Fri, Nov 8, 2013 at 9:00 AM, Bryan Davis  wrote:
> I think that picking the title "Senior Software Engineer II" may be
> underselling the value of this highest tier to the outside world. In
> my recent job search I saw a bit of the tech ladder side of the org
> chart for several companies. Most of the ladders I saw had a title of
> "Principal Engineer" for the top level of non-management engineers.

That's totally fair, and I like "Principal" as an alternative. It has
strong leadership implications, but leadership can take many forms,
and the criteria for a promotion from "Senior" to "Principal" could
make that clear.

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Bryan Davis]

On Thu, Nov 7, 2013 at 10:38 PM, Erik Moeller  wrote:
> 2) We don't award Architect as a job title beyond the original
> triumvirate, but we _do_ introduce a Senior Software Engineer II (same
> band as the Architect band), and would define some criteria for that,
> among which proven architectural leadership could be one. We can
> choose to still recognize any continued membership in something like a
> core maintainers groups etc. in a person's role, but that's decoupled
> from the salary band and can change, consistent with the idea that it
> should be OK for an architect to spend time doing other fun &
> important things, rather than being locked into one set of
> responsibilities forever.
>
> I think the second is more consistent with the tenor of the discussion
> here so far, because in the first case, the coupling between job
> titles and responsibilities in our community might be too tight to
> maintain flexibility and openness. It would also recognize that
> technical leadership doesn't _just_ mean taking on broad architectural
> responsibilities. So for example development of unique and
> mission-critical domain expertise might be another way to progress
> into Sr. II.

I personally think this route (separating the role of architectural
leadership from the title/pay band of WMF employees) is the most
reasonable way forward. I also think it fits well with the concepts of
role flexibility that Erik has been expressing. Being given the title
of Architect was a nice recognition of my value to the organization at
my last employer, but it was actually a bit of a hindrance during my
recent job search. Many recruiters were initially reluctant to put my
resume forth for positions that required hands-on software development
because they equated the Architect title with strategic planning more
than top-tier development. I don't think that Tim, Brion or Mark would
have any trouble demonstrating their abilities to anyone they decided
they would rather work for, but it's something to be cognizant of.

I think that picking the title "Senior Software Engineer II" may be
underselling the value of this highest tier to the outside world. In
my recent job search I saw a bit of the tech ladder side of the org
chart for several companies. Most of the ladders I saw had a title of
"Principal Engineer" for the top level of non-management engineers.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[C. Scott Ananian]

On Fri, Nov 8, 2013 at 12:38 AM, Erik Moeller  wrote:

> What might have some degree of traction, based on the
> discussion, is to have some blessed delegation coming from the
> original triumvirate of architects.

+1

I'd personally like to see this kept flexible, so that it's relatively easy
to both assign and to hand off projects.  Gerrit is littered with abandoned
bits and pieces.  It should be easy to 'assign' a new owner/"architect" to
a component when maintainership seems to be flagging, and owners should be
encouraged to hand off ownership when they've moved on.  Having to go
through a formal process would be a drag.

Perhaps every module owner should be required to write a quarterly report,
and the next level up in the hierarchy has to write the report for any
unowned modules. That would encourage people both to delegate and to
hand-off when possible. ;) [mostly joking, we shouldn't be inventing
busywork, but I do feel that ownership/"architect" status should ideally
come with real responsibilities.]

2) We don't award Architect as a job title beyond the original
> triumvirate, but we _do_ introduce a Senior Software Engineer II (same
>
[...]

> I think the second is more consistent with the tenor of the discussion
>

+1

I'm not a big fan of the actual wording of the "Senior Software Engineer
II" title, but I'm sure HR could come up with some comparable titles among
our peers.  (Maybe "Principal Software Engineer", or something with
"Fellow" in it.  Other organizations apparently use "Staff Software
Engineer" but I'm not a fan of that. [1])  But those are details...
 --scott

[1] see "Fellow" in https://en.wikipedia.org/wiki/Corporate_title ; also
see
http://programmers.stackexchange.com/questions/117179/what-is-the-job-title-hierarchy-amongst-software-engineersfor
some alternatives used elsewhere

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Quim Gil]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/07/2013 08:55 AM, C. Scott Ananian wrote:
> On Thu, Nov 7, 2013 at 11:44 AM, Quim Gil  wrote:
> 
>> Is your proposal different from
>> https://www.mediawiki.org/wiki/Developers/Maintainers ?
>>
> 
> No, it builds on it.  The current wiki page isn't official, nor complete.
>  I'm suggesting that we embrace it officially, and that we further add

Yes, that would be useful indeed.

Together with this, we could also map the software components developed
upstream that we are using and, hopefully, contributing to. For
instance, Chad is our expert in Gerrit, he follows the development
upstream and he has an idea of what we need and what could we eventually
contribute.

Which are the other key upstream projects, and who are the respective
owners? A solid architecture relies in solid foundations.

- -- 
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSfI7nAAoJEF0lRQxG2NZBsNkP/2uc+YALsoh694ObEj8nV4o+
jXqm15mxQtCYnYklPWu333op+f6rzE9+9X0HMVgsRCW/xrLl+1gg6vnr0MLHLE6L
1uqC7KISj78U71NSXl0RObE+kI4hVOWKOjQMYB/yuoGDmQRhpYDk0bUleo4HfvdU
z7U5BIhjAxQIXtLsqK6CYMevGMntZgusya7xxtXeL7VlegnlL8oQjH69x2e/NBfe
xSbWLZRre93sNwUfBNnpcvgT1kbQdJSY0mhV3513shAGYaPJNC0PN5UN8RHPgUjv
GWRkxwmA1ZVIgjf8ME7wbj6Wc+0YFc35OnTwe9iyUfUae7XJzYIEiohFWKeTLIhJ
iCbPRd3vP9QrF5YDgS4hH9nxJDWAPhW1Clgb9yJwvJ0CioantjzHfyQySMrqHZcs
hX7sHfS1U5TU0OEQBsEZnplK39rsZhoM853VgjoJ8Dh6B+fVYyWL7TGiroGHMzr5
Y2O6n5Avp8z9gXEHl/BYC8r9X5v+XiJiAWDVLB7Cdd49OYhQqeubkthRmVnGBr/p
rZrvfXkm9lbrthmbPT+zvQFmsk5J4bDq9EKgP0keNpnv4+xAYITWMo/vYCIHpkuN
7S37fdfHEMdVKpR/j7DSVn/t1sqkEz7MOwzxoWGni1BBT8f/8EO7dDOT2c2RRrsG
PL09LgsEQpm1CrRw0kCq
=gjHK
-END PGP SIGNATURE-

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Erik Moeller]

On Thu, Nov 7, 2013 at 1:15 AM, Faidon Liambotis  wrote:

Faidon,

great questions.

> The "architect" title, besides the job description that you described, is
> also a seniority level within the WMF's engineering department.  Other
> organizations do e.g.  "sr./staff/sr. staff" and/or numeric levels, we do
> "associate / (blank) / sr. / (lead) architect". At least that's my
> understanding of what was presented during the last all-staff and documented
> on officewiki.

On mediawiki.org:  https://www.mediawiki.org/wiki/Wikimedia_Engineering/Careers

> What would happen to this seniority level, if any of the options you
> presented were to be adopted? You seem to hint that there would be a mapping
> with option D ("salary increases") but it's not clear to me how direct of a
> mapping or a prerequisite would that be.

Let me try to respond to this and your other comments in one go. Folks
who don't care about WMF internals should stop reading at this point.
This stuff doesn't matter to everyone, if it doesn't matter to you,
that's OK. :)

There are four main salary band levels we work with in engineering:
entry-level, mid-level, senior level, and director/architect level.
Each of these bands is pretty wide, i.e. tens of thousands of dollars
for an SF-based hire between the lowest and the highest point. There's
a lot of room for progression within a given band, and it's OK for
folks to live outside a given band, which tends to make this somewhat
less urgent in practical terms. That said, one of the fundamental
principles I believe in is that it should be possible to progress to
the highest salary band on either the development or the management
side.

It seems that based on the discussion, nobody's particularly in favor
of a broad community process regarding architecture roles, so some of
the intricacies of progression tied in any way to such a process may
be moot. What might have some degree of traction, based on the
discussion, is to have some blessed delegation coming from the
original triumvirate of architects.

In practice, I could see this tie into the career progression at WMF
in two main ways:

1) We continue to (rarely but sometimes) use the Architect title as
the highest salary band in engineering, and promote people into it
based on a track record of continued architectural leadership, as
proven in a do-o-cracy framework like the one suggested by Brion.

2) We don't award Architect as a job title beyond the original
triumvirate, but we _do_ introduce a Senior Software Engineer II (same
band as the Architect band), and would define some criteria for that,
among which proven architectural leadership could be one. We can
choose to still recognize any continued membership in something like a
core maintainers groups etc. in a person's role, but that's decoupled
from the salary band and can change, consistent with the idea that it
should be OK for an architect to spend time doing other fun &
important things, rather than being locked into one set of
responsibilities forever.

I think the second is more consistent with the tenor of the discussion
here so far, because in the first case, the coupling between job
titles and responsibilities in our community might be too tight to
maintain flexibility and openness. It would also recognize that
technical leadership doesn't _just_ mean taking on broad architectural
responsibilities. So for example development of unique and
mission-critical domain expertise might be another way to progress
into Sr. II.

Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Antoine Musso]

Le 07/11/13 17:55, C. Scott Ananian a écrit :
> Note that there are also quasi-technical solutions here: if I want to get a
> patch reviewed for a particular SpecialPage, for instance, usually I will
> do a git log on that piece of the source and assign the last three
> committers to the file as reviewers.

I do the same thing when asking for review with OpenStack (they are
using Gerrit).  Basically:

# get the Gerrit reviews
git fetch -v gerrit refs/notes/review:refs/notes/review

# Then look at voters:
git log -n20 --notes=review|egrep '(Code-Review|Verified)'


But I am diverging from the main topic ...

-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[C. Scott Ananian]

On Thu, Nov 7, 2013 at 11:44 AM, Quim Gil  wrote:

> Is your proposal different from
> https://www.mediawiki.org/wiki/Developers/Maintainers ?
>

No, it builds on it.  The current wiki page isn't official, nor complete.
 I'm suggesting that we embrace it officially, and that we further add
additional hierarchical "modules" as needed to fill in the gap between the
big three and an individual extension owner.  In the process we might also
have to decide who owns, (for example), "Special Pages".  Should we recruit
someone, fold that into the maintainership of "mediawiki as a whole", or is
it not really a separate module.  The former option encourages more
granular maintainer ship, the middle option devolves into the current "big
3 architect" system in the limit case, and the latter option is a technical
finding.

Note that there are also quasi-technical solutions here: if I want to get a
patch reviewed for a particular SpecialPage, for instance, usually I will
do a git log on that piece of the source and assign the last three
committers to the file as reviewers.  One could imagine that something like
that might scale: the last three committers are the defacto owners of a
given component, if there aren't other owners given.  This would work well
with a more hierarchical system.  I might end up as the defacto owner of
the SpecialRedirect page, but changes could also be reviewed by other
owners up the chain: the owner of SpecialPages as a whole (no current
owner), ..., the owner(s) of mediawiki as a whole, the owners of
mediawiki-as-deployed-by-WMF, ..., the big three.

We haven't really thought much about the hierarchy and intermediate owners
here; I guess that's where my proposal differs most from the flat list at
https://www.mediawiki.org/wiki/Developers/Maintainers .
 --scott

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Quim Gil]

On 11/07/2013 08:40 AM, C. Scott Ananian wrote:
> 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!)

Is your proposal different from
https://www.mediawiki.org/wiki/Developers/Maintainers ?

-- 
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[C. Scott Ananian]

On Wed, Nov 6, 2013 at 10:13 AM, Brion Vibber  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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Faidon Liambotis]

On Tue, Nov 05, 2013 at 05:57:31PM -0800, Erik Moeller wrote:

So how should this role evolve going forward? Some possible paths (you
know I like to present options ;-):


The "architect" title, besides the job description that you described, 
is also a seniority level within the WMF's engineering department.  
Other organizations do e.g.  "sr./staff/sr. staff" and/or numeric 
levels, we do "associate / (blank) / sr. / (lead) architect". At least 
that's my understanding of what was presented during the last all-staff 
and documented on officewiki.


What would happen to this seniority level, if any of the options you 
presented were to be adopted? You seem to hint that there would be a 
mapping with option D ("salary increases") but it's not clear to me how 
direct of a mapping or a prerequisite would that be.


I don't think it'd reasonable to say that we have, as an organization 
with ~180 FT staff, a peer review process, an HR department, managers, 
directors & VPs *but* you can't be promoted inside the organization 
until an open community process says so (or, in case of option A, *at 
all*). It'd be even more illogical considering that currently no other 
positions exist where there is such a connection: this hasn't been the 
case for promotions to Sr. -- and, even in the leadership track, there 
have been promotions to managers, directors & VPs, with no such open 
community process.


If that's not the intention, on the other hand, I think it's useful to 
either hear WMF management's views on that or, if it is up for 
discussion, have this discussion in parallel with this one.


Whether we like it or not, the existing title has *two* meanings as it 
is —and my understanding is that the salary aspect came first, too— and 
I don't think we can have a meaningful discussion for the one without 
knowing the implications for the other.


Regards,
Faidon

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Erik Moeller]

On Wed, Nov 6, 2013 at 7:13 AM, Brion Vibber  wrote:

> * It makes sense to have a handful of folks as a core review & planning
> group.
>
> * 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.

Yeah, that makes sense to me. How do you propose that core review &
planning group be comprised? You say "a handful of folks", do you mean
that literally, or are you talking about a comprehensive maintainers
list like the one at
https://www.mediawiki.org/wiki/Developers/Maintainers ? If it's a
significantly smaller subset, perhaps the current architects should
appoint some folks as lieutenants, either Linux-style or on an
as-needed basis?

> As such, I'd recommend a slightly more formal role for additional "lead
> reviewers" or "module owners" in the code review & RFC processes

Would that be the same as the "core review & planning group" you refer to above?

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Quim Gil]

On 11/06/2013 12:30 PM, Brion Vibber wrote:

>>> Do they consider their roles to be part of a MediaWiki centric
>>> meritocracy or a Wikimedia centric meritocracy?

(...)

> I also caution against use of the "meritocracy" term, as I think it's
> pretty loaded and has a history of enabling stagnation and ingraining of
> cabals and antisocial behavior in free software communities. While I
> certainly like to think I've earned my fancy title with years of hard work,
> there are strong social/popularity and random-event components in any kind
> of ranking like this.

Agreed. I meant "meritocracy" in its unloaded form and I'm happy to use
whatever alternative term. A typical open source project has committers
and maintainers, roles that we have as well. They also have a release
team, which we have as well. Some have a formal project leader
(temporary or for life, individual or plural), some have none, as it is
our case now.

Is this what this thread is all about? Having a project lead role to
make decisions when maintainers alone are not enough?

Wikimedia vs MediaWiki centric... yes, it's complicated--and then again
perhaps it's not. In any case, the structure and roles of this project
should come from within and be independent from the structure and roles
of the WMF.

-- 
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Brion Vibber]

On 11/06/2013 02:33 AM, Quim Gil wrote:

> > Do the three architects consider themselves assuming this role as WMF
> > employees or as community members?
>

For myself -- I've been a Wikipedia & MediaWiki community contributor since
long before there was a Wikimedia Foundation. I still think of WMF as the
new kid on the block... ;)

That said, my employment at WMF is what pays my bills and ensures I keep
the majority of my attention poking at the Wikipedia and MediaWiki
ecosystem (currently concentrating on the mobile world with a slice of
general maintenance, code review, and architecture planning). When I spent
a year and a half working at another company, I did find I had much less
time to spend on MediaWiki.


> > Do they consider their roles to be part of a MediaWiki centric
> > meritocracy or a Wikimedia centric meritocracy?
>

MediaWiki's development is traditionally Wikipedia- and Wikimedia-centric
(not necessarily Wikimedia Foundation-centric); it was created for
Wikipedia and I personally got involved in it to support Wikipedia's
various multilingual editions. Generalized usage of MW has always been a
secondary, though important, goal, and I expect Wikipedia/Wikimedia will
continue to be central in MW's development for the forseeable future, even
assuming we put a lot more effort into third-party support (which I think
we should!)

I also caution against use of the "meritocracy" term, as I think it's
pretty loaded and has a history of enabling stagnation and ingraining of
cabals and antisocial behavior in free software communities. While I
certainly like to think I've earned my fancy title with years of hard work,
there are strong social/popularity and random-event components in any kind
of ranking like this.


> > What is their opinion about moving forward their current team of three?
>

I'm not sure the "architects" really exist as a team of three; I feel like
that's a fairly arbitrary selection of longtime contributors who,
currently, have "architect" in their job title.

There's similarity in subsets of what we do, and some direct overlap -- Tim
and I both comment on code and code designs and do the occasional big RFC
review session; Tim and Mark both comment on and help debug ops and
performance issues -- but we're not the 3 Musketeers... :)


> > Because these three long-term contributors have earned their community
> > reputation and are clearly smart, the chances are that many of us would
> > agree with any common answer they would agree with themselves.
>

:D

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Mark A. Hershberger]

Thank you, Quim, for trying to focus this discussion on the MediaWiki
community instead of just the WMF.  This is a very valuable thing.

That, with Brion's "do-it-ocracy" (which assumes, I think, that we're
encouraging and enabling more people to "do it") are excellent
approaches to this "who are the architects?" problem.

Finally, Jeroen is right that MW isn't a pristine example of excellent
architecture.  Still, this is what we have.  While we shouldn't enshrine
bad practices for perpetuity, it isn't helpful to pull the rug out from
under the existing infrastructure.  That is like rewriting MW in Java
(http://meatballwiki.org/wiki/RewriteMediawikiInJava), Python, or Perl.

All that said, I'm not too concerned with the titles the WMF gives
people.  I am interested in the answers to the questions Quim had, though:

On 11/06/2013 02:33 AM, Quim Gil wrote:
> Do the three architects consider themselves assuming this role as WMF
> employees or as community members?
> 
> Do they consider their roles to be part of a MediaWiki centric
> meritocracy or a Wikimedia centric meritocracy?
> 
> What is their opinion about moving forward their current team of three?
> 
> Because these three long-term contributors have earned their community
> reputation and are clearly smart, the chances are that many of us would
> agree with any common answer they would agree with themselves.

Thanks,

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Chad]

On Wed, Nov 6, 2013 at 7:13 AM, Brion Vibber  wrote:

> My brief thoughts:
>
> * It makes sense to have a handful of folks as a core review & planning
> group.
>
>
Agreed.


> * 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.
>
>
This.


> * I've got no particular patience for over-formal community processes like
> Wikipedia adminship voting, nor interest in replicating those processes.
>
>
A million times this.


> While there are plenty of problems with the traditional FOSS concept of
> "meritocracy", I still have great affection for the "do-it-ocracy" notion
> that folks who actually get stuff done should be recognized as fulfilling
> the roles they are performing.
>
>
People who do things are more valuable than people who only
voice armchair opinions :)


> 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.
>
> (For comparison, I occasionally write patches for Firefox and Firefox OS;
> they have a *really full* bug tracker and your only hope of getting a patch
> reviewed is to actually request review from a particular person. A list of
> module owners like  is a
> lifesaver for a casual contributor who doesn't know everybody on the
> Mozilla teams.)
>

So yeah, I think that's the idea behind the "Maintainers" page
. It could be more
complete. And finding a way to involve these stakeholders in the RFC process
could certainly be beneficial.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Jeroen De Dauw]

Hey,

> * MediaWiki is not a shining beacon of good architecture. I'd argue it
> > should mostly be considered as a big blob of generally badly designed
> > legacy code
>
> This has nothing to do with the subject at hand.
>

It does, as it implies serious mistakes where made in the past, and that
one should not be religious about existing practices being the true one
way. And it is relevant for some of the other thoughts I listed when
thinking through their implications.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Brion Vibber]

My brief thoughts:

* It makes sense to have a handful of folks as a core review & planning
group.

* 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.

* I've got no particular patience for over-formal community processes like
Wikipedia adminship voting, nor interest in replicating those processes.

While there are plenty of problems with the traditional FOSS concept of
"meritocracy", I still have great affection for the "do-it-ocracy" notion
that folks who actually get stuff done should be recognized as fulfilling
the roles they are performing.

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.

(For comparison, I occasionally write patches for Firefox and Firefox OS;
they have a *really full* bug tracker and your only hope of getting a patch
reviewed is to actually request review from a particular person. A list of
module owners like  is a
lifesaver for a casual contributor who doesn't know everybody on the
Mozilla teams.)

-- brion



On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller  wrote:

> tl;dr: I’d appreciate thoughts from the Wikimedia technical community
> at large whether the designation of individual technical contributors
> as "architects" should be meaningful, and if so, how to expand it
> beyond the original triumvirate (Brion, Tim & Mark), e.g. by
> transitioning to a community-driven process for recognizing
> architects.
>
> Hi all,
>
> in March 2011 and June 2011, Brion Vibber, Mark Bergsma and Tim
> Starling were announced as Lead Software Architect, Lead Operations
> Architect and Lead Platform Architect of the Wikimedia Foundation,
> respectively. Together, these three individuals laid much of the
> foundation of Wikimedia’s technical infrastructure, from MediaWiki
> itself to our caching and load balancing setup. So it was a logical
> step to recognize their immense contributions, and to entrust them
> with continued high-level stewardship in Wikimedia’s technical
> ecosystem.
>
> Since then, WMF's engineering organization has grown pretty
> dramatically. We've also seen increased engagement in the Wikimedia
> technical community from other organizations. Wikimedia Germany is
> probably most notable among them with the Wikidata project, and Wikia
> has partnered directly on VisualEditor development and is generally
> striving to increase visibility of its open source modifications to
> MediaWiki.
>
> At WMF, this has increasingly raised the question how the architecture
> of Wikimedia’s technical infrastructure can be evolved at this new,
> larger scale, and how we can bring more voices into that conversation.
> I've shared this note with the architects ahead of time and taken some
> initial feedback into account.
>
> Rob Lanphier has taken a lead role in giving the RFC process a kick in
> the pants as a solid, asynchronous, transparent process for organizing
> and resolving technical proposals. Brion, Tim and Mark are explicitly
> listed as the three individuals who can close an RFC (interpreting or
> helping reach consensus, or making an informed decision where there’s
> a lack of community participation), and have helped clear the RFC
> backlog and evolve the architecture guidelines. In addition, Rob is
> organizing the MediaWiki architecture summit in January, where we can
> talk about some of the most pressing or contentious architectural
> questions in person.
>
> However, Brion, Tim and Mark are not infinitely scalable, nor are they
> immortal (except in our hearts). They can’t be in every conversation,
> know every part of Wikimedia’s technical ecosystem, review every RFC,
> etc. We also have many other deeply talented technical contributors,
> including some who have many years of experience in our technical
> context specifically -- not just at WMF. Beyond just making technical
> decisions, architectural leadership creates opportunities for
> mentorship, modeling and nurturing the kind of behavior we want to
> foster in our technical community.
>
> So how should this role evolve going forward? Some possible paths (you
> know I like to present options ;-):
>
> Option A: We change nothing and don't promote any new people into
> architect roles for a while. I truly don’t think this is an option for
> much longer -- we need to find better ways to encourage some of our
> other capable technical contributors to feel ownership over
> Wikimedia’s technical direc

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Chad]

On Wed, Nov 6, 2013 at 4:07 AM, Jeroen De Dauw wrote:

> * MediaWiki is not a shining beacon of good architecture. I'd argue it
> should mostly be considered as a big blob of generally badly designed
> legacy code
>

This has nothing to do with the subject at hand.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Jeroen De Dauw]

Hey,

Some thoughts, in no particular order:

* Titles do not reflect ability, they reflect how titles are assigned in an
organization
* Some people see titles such as "software architect" as a stamp of
superiority
* Some people abuse their titles
* We would indeed be advised to keep the distinction between WMF and
MediaWiki in mind
* MediaWiki is not a shining beacon of good architecture. I'd argue it
should mostly be considered as a big blob of generally badly designed
legacy code
* Length of participation in a community, or the number of contributions,
does not linearly relate to ability
* Having a community process to decide who gets $fancyTitle, seems more
likely to result in the most popular people of the strongest subgroups to
get it then the most qualified ones. Same as what happens in politics.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Antoine Musso]

Le 06/11/13 02:57, Erik Moeller a écrit :
> tl;dr: I’d appreciate thoughts from the Wikimedia technical community
> at large whether the designation of individual technical contributors
> as "architects" should be meaningful, and if so, how to expand it
> beyond the original triumvirate (Brion, Tim & Mark), e.g. by
> transitioning to a community-driven process for recognizing
> architects.


Hello,

I would have a look at the way IETF is handling its RFC process. I wrote
about it back in July in the thread "proposed RFC process":

 http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070241.html

The workflow is as bureaucratic as you can imagine given the number of
parties involved and all the political / commercial context that goes
behind creating internet standards. You can still achieve a RFC pretty
"quickly".


To scale out the architects roles, I would formalize the concept of self
organized working groups.  Their responsibility would be to produce a
draft to be presented to a technical board.  Once the standard is
approved / implemented / released, the working group is disbanded.


How would it work?

Any individual having an idea would expose it on wikitech-l to gain
people to its cause.  They would form a self organized working group
using whatever tools and practices they agree upon.  The aim of the
group would be to produce a draft.

The technical board would be made of the smartest people we have,
ideally including non wikimedia people.  To name a few, at the *very
minimum* I would include Brion, Tim, Mark and Ori and definitely Daniel
Kinzler from WMDE, probably adding Rob as the facilitator.


The board responsibilities would be:
- provide support to the working group leaders
- ensure working groups are progressing
- handle conflicts between members of a group
- ensure the working groups work are not overlapping
- accept the produced drafts as RFC.


Whenever a working group publishes a draft, it would be reviewed by
whoever is interested and amended until it has consensus.  The draft is
then proposed to the technical board which has the final word and
publish the draft as a RFC.


As to who is going to implement the RFC, I guess it depends on who needs
it in the first place.  Most of the time it would be for Wikimedia, so
the Wikimedia engineering managers would be responsible to get the
standard implemented, released and deployed.  The draft could well
propose a working implementation as well.


If a working group is working on an ambitious feature, it could probably
use some real life meeting from time to time.

The technical board could use some monthly meetings much like the RFC
review IRC meeting we are already having.


Finally, the MediaWiki architecture summit would gather all the working
groups members and technical board members with an agenda of drafts to
approve or vision of the next working groups to form.


Example:

https://www.mediawiki.org/wiki/Requests_for_comment/LESS

Working group was Ori Livneh, Jon Robson, Steven Walling. They came with
a draft and implementation after a few review cycles.

Along the process Brion stepped in to offer technical reviews/guidance.

Brion eventually accepted it by marking the RfC complete and merging the
implementation.

End result: MediaWiki now supports LESS.


My
ERROR: rounding error in '%s cents' % 0,02

-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Dan Garry]

Thinking about this, I am somewhat afraid that any public voting process
may become more similar to Requests for Bureaucratship (RfB).

For those not familiar with this process, it's an even more brutal thing
than RfA (Requests for Adminship). Bureaucrats are socially the people that
close the RfAs, and technically the only people with the ability to
actually make someone an administrator. The typical support required to
pass RfB is 90%, as opposed to the 70-75% [1] of RfA. For a while the RfB
process was considered impossible to pass, which led people to relax their
requirements of the candidates, and in turn led to the process being
passable again! An interesting feedback loop for regulation of the process.

The thing is, everyone on the English Wikipedia agrees that RfA sucks.
Everyone just thinks it sucks for different reasons, so nobody can agree on
a better process. I don't want to see this happen to any process that we
come with.

Dan

[1]: There are exceptions to this, and people have passed with lower
percentages. Chad on this list is one such exception.


On 6 November 2013 01:57, Erik Moeller  wrote:

> tl;dr: I’d appreciate thoughts from the Wikimedia technical community
> at large whether the designation of individual technical contributors
> as "architects" should be meaningful, and if so, how to expand it
> beyond the original triumvirate (Brion, Tim & Mark), e.g. by
> transitioning to a community-driven process for recognizing
> architects.
>
> Hi all,
>
> in March 2011 and June 2011, Brion Vibber, Mark Bergsma and Tim
> Starling were announced as Lead Software Architect, Lead Operations
> Architect and Lead Platform Architect of the Wikimedia Foundation,
> respectively. Together, these three individuals laid much of the
> foundation of Wikimedia’s technical infrastructure, from MediaWiki
> itself to our caching and load balancing setup. So it was a logical
> step to recognize their immense contributions, and to entrust them
> with continued high-level stewardship in Wikimedia’s technical
> ecosystem.
>
> Since then, WMF's engineering organization has grown pretty
> dramatically. We've also seen increased engagement in the Wikimedia
> technical community from other organizations. Wikimedia Germany is
> probably most notable among them with the Wikidata project, and Wikia
> has partnered directly on VisualEditor development and is generally
> striving to increase visibility of its open source modifications to
> MediaWiki.
>
> At WMF, this has increasingly raised the question how the architecture
> of Wikimedia’s technical infrastructure can be evolved at this new,
> larger scale, and how we can bring more voices into that conversation.
> I've shared this note with the architects ahead of time and taken some
> initial feedback into account.
>
> Rob Lanphier has taken a lead role in giving the RFC process a kick in
> the pants as a solid, asynchronous, transparent process for organizing
> and resolving technical proposals. Brion, Tim and Mark are explicitly
> listed as the three individuals who can close an RFC (interpreting or
> helping reach consensus, or making an informed decision where there’s
> a lack of community participation), and have helped clear the RFC
> backlog and evolve the architecture guidelines. In addition, Rob is
> organizing the MediaWiki architecture summit in January, where we can
> talk about some of the most pressing or contentious architectural
> questions in person.
>
> However, Brion, Tim and Mark are not infinitely scalable, nor are they
> immortal (except in our hearts). They can’t be in every conversation,
> know every part of Wikimedia’s technical ecosystem, review every RFC,
> etc. We also have many other deeply talented technical contributors,
> including some who have many years of experience in our technical
> context specifically -- not just at WMF. Beyond just making technical
> decisions, architectural leadership creates opportunities for
> mentorship, modeling and nurturing the kind of behavior we want to
> foster in our technical community.
>
> So how should this role evolve going forward? Some possible paths (you
> know I like to present options ;-):
>
> Option A: We change nothing and don't promote any new people into
> architect roles for a while. I truly don’t think this is an option for
> much longer -- we need to find better ways to encourage some of our
> other capable technical contributors to feel ownership over
> Wikimedia’s technical direction, and fill gaps in architectural
> leadership today. That said, it would be possible to make the RFC
> process more egalitarian and to reduce the emphasis on formalized
> technical leadership.
>
> Option B: WMF handles it as it sees fit. This basically means WMF gets
> to decide who to designate as "Architects" and at what point, which
> would mostly leave this decision in the hands of managers. This is a
> very WMF-centric view of the world, but it’s of course the way most
> organizations operate.
>
> 

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Ori Livneh]

On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller  wrote:
> tl;dr: I’d appreciate thoughts from the Wikimedia technical community
> at large whether the designation of individual technical contributors
> as "architects" should be meaningful, and if so, how to expand it
> beyond the original triumvirate (Brion, Tim & Mark), e.g. by
> transitioning to a community-driven process for recognizing
> architects.
>
> Hi all,
>
> in March 2011 and June 2011, Brion Vibber, Mark Bergsma and Tim
> Starling were announced as Lead Software Architect, Lead Operations
> Architect and Lead Platform Architect of the Wikimedia Foundation,
> respectively. Together, these three individuals laid much of the
> foundation of Wikimedia’s technical infrastructure, from MediaWiki
> itself to our caching and load balancing setup. So it was a logical
> step to recognize their immense contributions, and to entrust them
> with continued high-level stewardship in Wikimedia’s technical
> ecosystem.
>
> Since then, WMF's engineering organization has grown pretty
> dramatically. We've also seen increased engagement in the Wikimedia
> technical community from other organizations. Wikimedia Germany is
> probably most notable among them with the Wikidata project, and Wikia
> has partnered directly on VisualEditor development and is generally
> striving to increase visibility of its open source modifications to
> MediaWiki.
>
> At WMF, this has increasingly raised the question how the architecture
> of Wikimedia’s technical infrastructure can be evolved at this new,
> larger scale, and how we can bring more voices into that conversation.
> I've shared this note with the architects ahead of time and taken some
> initial feedback into account.
>
> Rob Lanphier has taken a lead role in giving the RFC process a kick in
> the pants as a solid, asynchronous, transparent process for organizing
> and resolving technical proposals. Brion, Tim and Mark are explicitly
> listed as the three individuals who can close an RFC (interpreting or
> helping reach consensus, or making an informed decision where there’s
> a lack of community participation), and have helped clear the RFC
> backlog and evolve the architecture guidelines. In addition, Rob is
> organizing the MediaWiki architecture summit in January, where we can
> talk about some of the most pressing or contentious architectural
> questions in person.
>
> However, Brion, Tim and Mark are not infinitely scalable, nor are they
> immortal (except in our hearts). They can’t be in every conversation,
> know every part of Wikimedia’s technical ecosystem, review every RFC,
> etc. We also have many other deeply talented technical contributors,
> including some who have many years of experience in our technical
> context specifically -- not just at WMF. Beyond just making technical
> decisions, architectural leadership creates opportunities for
> mentorship, modeling and nurturing the kind of behavior we want to
> foster in our technical community.
>
> So how should this role evolve going forward? Some possible paths (you
> know I like to present options ;-):
>
> Option A: We change nothing and don't promote any new people into
> architect roles for a while. I truly don’t think this is an option for
> much longer -- we need to find better ways to encourage some of our
> other capable technical contributors to feel ownership over
> Wikimedia’s technical direction, and fill gaps in architectural
> leadership today. That said, it would be possible to make the RFC
> process more egalitarian and to reduce the emphasis on formalized
> technical leadership.
>
> Option B: WMF handles it as it sees fit. This basically means WMF gets
> to decide who to designate as "Architects" and at what point, which
> would mostly leave this decision in the hands of managers. This is a
> very WMF-centric view of the world, but it’s of course the way most
> organizations operate.
>
> Option C: We get rid of the special role of architects. I personally
> don’t favor this option either, because I think recognizing the most
> sane and experienced voices in our technical community and according
> them some real leadership influence over Wikimedia’s technical
> direction is important (and a useful counterbalance to pointy-haired
> folks like yours truly ;-).
>
> Option D: We come up with some kind of open process for
> designating/confirming folks as architects, according to some
> well-defined criteria (including minimum participation in the RFC
> process, well-defined domain expertise in certain areas, a track
> record of constructive engagement, etc.). Organizations like WMF can
> choose to recognize this role as they see fit (likely according salary
> increases to individuals who demonstrate successful architectural
> leadership), but it’s a technical leadership role that’s awarded by
> Wikimedia’s larger technical community, similar to +2 status.
>
> Each of these would need to be unpacked and further developed. For
> option D in particular

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Steven Walling]

On Tue, Nov 5, 2013 at 9:06 PM, Nathan Larson wrote:

> > (snip)
> > I actually like the formalism a bit - since it at least makes sure
> > that they don't rot. BDFLs are good.
> >
> >
> Does it keep them from rotting? It looks like of the 60 RFCs in draft or in
> discussion, 24 were last updated before 2013.
>
> https://www.mediawiki.org/wiki/User:Leucosticte/RFCs_sorted_by_%22updated%22_date
>

Weren't most of the RFCs you're talking about started before the new
process was implemented? There's a lot of cleanup work to be done, and so
far it seems like decent progress has been made. I agree we could be more
aggressive about closing RFCs that are long stale, but it's hard to fault
an architectural process that replaces what amounted to a vacuum. It's not
like RFCs were all tidy and making progress before any new process was
announced.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Quim Gil]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/05/2013 05:57 PM, Erik Moeller wrote:
> tl;dr: I’d appreciate thoughts from the Wikimedia technical community
> at large whether the designation of individual technical contributors
> as "architects" should be meaningful, and if so, how to expand it
> beyond the original triumvirate (Brion, Tim & Mark), e.g. by
> transitioning to a community-driven process for recognizing
> architects.

Since this thread is about architecture and governance it makes sense to
step back and look at the architecture and governance of our technical
project(s).

In my humble opinion any step formalizing community roles should help
separating concepts that are still tangled:

1. Wikimedia Foundation professional titles and roles vs open source
community roles.

2. MediaWiki open source project meritocracy vs Wikimedia movement
meritocracy.

For instance, the nomination of a MediaWiki release team with Mark &
Markus was very helpful in these directions.


Open source community roles include admins, +2, release team members
and, it seems, architects. The handling and discussion about community
roles should be driven by the the open source project, not by the WMF.

The architecture of MediaWiki and the architecture of the Wikimedia
infrastructure are different things. The meritocracy of the MediaWiki
project and the meritocracy of Wikimedia tech should be different things.

Yes, there is a big overlap but the differences are relevant. If we talk
about software architecture and community roles in this open source
project, a thread like this could refer to "Architectural leadership in
the MediaWiki project" and could be driven by the current community
architects.

I hope this doesn sound too abstract or beyond the point of the thread
because I believe it is at the core of the question. I don't have an
opinion between the options suggested by Erik, because these questions
come first:

Do the three architects consider themselves assuming this role as WMF
employees or as community members?

Do they consider their roles to be part of a MediaWiki centric
meritocracy or a Wikimedia centric meritocracy?

What is their opinion about moving forward their current team of three?

Because these three long-term contributors have earned their community
reputation and are clearly smart, the chances are that many of us would
agree with any common answer they would agree with themselves.

- -- 
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSefDRAAoJEF0lRQxG2NZBvgwP/0xQB6E9djoBjeQidw3y9vl1
s3gWmaIUnJOIHYfoJFAhLVcIOmtANhAAz9vfiHKlrVEBSC2JpyFdOI0WgLT13P85
YPsu7Z7LOXgvxkYR5JNwotB0WcTwKIVteSK086oC8pEag9sLuDcVAZ5dUeZr7h5l
GfSSZBd1/HANw+o59SIts9iK8OSviSi9Uc5zY62xh5yo3BiXuTTDvOkQpDiLqa5m
8AMHM7zsJyna4lux46YOW4ABkJyknnhKoSwIv7iboxQzfVa6CHtiKgntE/KxMc57
/8ABsI3hLSOl+nbe6Mdm7MxDW3H5eA0p4gy//T58HDd59TVJsYYI8Q/Jc92+IbVd
agdWUwlpRbGiZJnZa7QRiN2XlcGY+7S+EfPgR5WMp6D5rG26P3vpvQPv1xJJki8q
2+iQAoxAzYdzJQ5vMniVj4vrMP9a6yB/s9z+6QWO78m8B59oJX55YXuf8PmLWq+W
lzvBTs3Ftl07uGo0s37LbqHWl79ZbPsBQGVCHruowtpxn9v82aTtkiWZoXoshVhf
lq7Cey6F5Nh0LOzf4CisJ9a9aEL/GQsSqJj1mf7k26E4tjfPm7nvdQKQXTnsB3tY
sMy27yUkWgeWR0W3EzNaLSVU8kAqIpsoMnRYKclQuiaipBdtrp7yK2I7lSLmToCB
/fRvR29ZVu3jrriykKWK
=bGbr
-END PGP SIGNATURE-

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Nathan Larson]

On Tue, Nov 5, 2013 at 9:10 PM, Yuvi Panda  wrote:

> (snip)
> I actually like the formalism a bit - since it at least makes sure
> that they don't rot. BDFLs are good.
>
>
Does it keep them from rotting? It looks like of the 60 RFCs in draft or in
discussion, 24 were last updated before 2013.
https://www.mediawiki.org/wiki/User:Leucosticte/RFCs_sorted_by_%22updated%22_date

-- 
Nathan Larson 
Distribution of my contributions to this email is hereby authorized
pursuant to the CC0 license
.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Brian Wolff]

On 11/5/13, Chad  wrote:
> On Tue, Nov 5, 2013 at 6:02 PM, Yuvi Panda  wrote:
>
>> On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller  wrote:
>> > Option D: We come up with some kind of open process for
>> > designating/confirming folks as architects, according to some
>> > well-defined criteria (including minimum participation in the RFC
>> > process, well-defined domain expertise in certain areas, a track
>> > record of constructive engagement, etc.). Organizations like WMF can
>> > choose to recognize this role as they see fit (likely according salary
>> > increases to individuals who demonstrate successful architectural
>> > leadership), but it’s a technical leadership role that’s awarded by
>> > Wikimedia’s larger technical community, similar to +2 status.
>>
>> I like this in theory, though I fear that this will somehow lead to a
>> state in some ways similar to the enwiki RfA process...
>>
>
> Yeah.
>
> I'm in favor of option (C), mainly because I think that titles are
> pointless and
> lead to hat collecting and hurt feelings. I respect Brion, Mark and Tim (and
> many others) as architects because they *are* architects, not because we
> call them such.

+1 (Although also ok with option (A) as I have an immense amount of
respect for the people currently in this role and am totally fine with
them having fancy titles to recognize all they've done)

To be honest I'm kind of unclear what precisely an "architect" does
that a non-architect can't. To date the only thing I've seen is be the
final judge on RFCs (and basically push the process forward). What
other activities are they doing that they need scaling on? I suppose
I'm considering these people's general role in guiding MediaWiki
development to not be so much part of their architect role since they
have been doing that long before they got the title, and in theory
(and probably in practise) other people can share in that
responsibility.



In particular I really don't like the idea of voting people into a
formal leadership position. RfA's, votes for +2's are votes because
they are associated with technical abilities. While sometimes these
positions are also associated with leadership or authority, that's not
their primary function (or shouldn't be imo). If no tools are
involved, I feel a vote would be a pure popularity contest, which
aren't healthy.

Leadership is something that someone does, its not something that
someone can be appointed into (Although opinions no doubt differ on
that).

Cheers,
--Bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Erik Moeller]

On Tue, Nov 5, 2013 at 6:21 PM, Chad  wrote:

> I think I can respond to pretty much the whole idea here. I
> think titles are pretty much a WMF-thing and shouldn't have
> any bearing on MediaWiki :\

Just to be clear on how they currently do, in the relatively recently
drafted (and still draft status) architecture guidelines:

"An RFC is a request for review of a proposal or idea. RFCs are
reviewed by the community of MediaWiki developers. Final decisions on
RFC status are made by the WMF architects (Mark Bergsma, Tim Starling,
Brion Vibber)."
https://www.mediawiki.org/wiki/Architecture_guidelines

This is of course a process we could change, and rely more on informal
recognition of technical leadership than formalized roles or titles.


-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Yuvi Panda]

On Tue, Nov 5, 2013 at 6:09 PM, Rob Lanphier  wrote:
> I think that's probably a good observation and comparison, but could you
> expand on which qualities the RfA process you'd like to avoid?

The primary things I had in mind were:

- 'Positioning', which I guess is people going 'I am going to be doing
this because it'll help me in my RfA' or worse, 'I want to do this but
I won't since it will look bad in RfA review'.
- 'Badgering', which is people digging back someone's editing history
to see if they can find specific things to discredit them. There are a
number of RfAs that were rejected because of something from the past
that does not actually have much to do with the actual ability of the
person to be an enwiki admin.

People who have more enwiki experience than me can probably provide
more points, but these were the ones that stood out to me.

Both of these don't seem to be things that will affect the developer
community as much, so it might not be as bad an issue. But if we *do*
go the route of Option D, I think enwiki's system is one to study so
we don't fall into the same traps.


-- 
Yuvi Panda T
http://yuvi.in/blog

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Chad]

On Tue, Nov 5, 2013 at 6:09 PM, Rob Lanphier  wrote:

> On Tue, Nov 5, 2013 at 6:02 PM, Yuvi Panda  wrote:
>
> > On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller  wrote:
> > > Option D: We come up with some kind of open process for
> > > designating/confirming folks as architects, according to some
> > > well-defined criteria (including minimum participation in the RFC
> > > process, well-defined domain expertise in certain areas, a track
> > > record of constructive engagement, etc.). Organizations like WMF can
> > > choose to recognize this role as they see fit (likely according salary
> > > increases to individuals who demonstrate successful architectural
> > > leadership), but it’s a technical leadership role that’s awarded by
> > > Wikimedia’s larger technical community, similar to +2 status.
> >
> > I like this in theory, though I fear that this will somehow lead to a
> > state in some ways similar to the enwiki RfA process...
> >
>
> Hi Yuvi,
>
> I think that's probably a good observation and comparison, but could you
> expand on which qualities the RfA process you'd like to avoid?
>
>
Everything. Here's a few:

1) Making the standards (even if unwritten) impossibly high
2) Dragging people through the mud
3) Making it a vote and pretending it's not. Either vote, or don't vote.
Don't
waste everyone's time pretending.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Chad]

On Tue, Nov 5, 2013 at 6:15 PM, Arthur Richards wrote:

> On Tue, Nov 5, 2013 at 7:07 PM, Chad  wrote:
> >
> > I'm in favor of option (C), mainly because I think that titles are
> > pointless and
> > lead to hat collecting and hurt feelings.
>
>
> Titles are useful for a few things:
> * Prospects of future employment
> * Clarity around who to talk to about what
>
> > I respect Brion, Mark and Tim (and
> > many others) as architects because they *are* architects, not because we
> > call them such.
> >
>
> We call them such, because they are such - it is a useful designation.
>
>
> > For RFCs, I've been of the opinion we've made them entirely too formal.
> I'm
> > glad we're trying to move them forward, but I've always thought they
> should
> > be based on community consensus, not convincing an architect.
> >
>
> Generally agreed, although I think this is more of a procedural point and
> perhaps orthogonal to roles/titles and what they mean.
>
>
I think I can respond to pretty much the whole idea here. I
think titles are pretty much a WMF-thing and shouldn't have
any bearing on MediaWiki :\

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Arthur Richards]

On Tue, Nov 5, 2013 at 7:07 PM, Chad  wrote:
>
> I'm in favor of option (C), mainly because I think that titles are
> pointless and
> lead to hat collecting and hurt feelings.


Titles are useful for a few things:
* Prospects of future employment
* Clarity around who to talk to about what


> I respect Brion, Mark and Tim (and
> many others) as architects because they *are* architects, not because we
> call them such.
>

We call them such, because they are such - it is a useful designation.


> For RFCs, I've been of the opinion we've made them entirely too formal. I'm
> glad we're trying to move them forward, but I've always thought they should
> be based on community consensus, not convincing an architect.
>

Generally agreed, although I think this is more of a procedural point and
perhaps orthogonal to roles/titles and what they mean.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Arthur Richards]

On Tue, Nov 5, 2013 at 6:57 PM, Erik Moeller  wrote:

>
> Option D: We come up with some kind of open process for
> designating/confirming folks as architects, according to some
> well-defined criteria (including minimum participation in the RFC
> process, well-defined domain expertise in certain areas, a track
> record of constructive engagement, etc.). Organizations like WMF can
> choose to recognize this role as they see fit (likely according salary
> increases to individuals who demonstrate successful architectural
> leadership), but it’s a technical leadership role that’s awarded by
> Wikimedia’s larger technical community, similar to +2 status.
>

I think there's room for this to be hybridized with the existing 'Lead %s
Architect' titles/roles, whereby the architects architect and the 'leads'
steward that process. This seems to me like a sensible way forward. Right
now, the architecting/RFC cabal is 'Senior Software Engineers' and others;
but not every Senior Software Engineer may want responsibilities of being
an 'architect' and the technical distinctions for what makes someone a
'Senior Software Engineer' rather than a 'Software Engineer' are not
totally clear.

One thing that we touched on during Tech Days was the notion that titles
are independent of roles - perhaps the 'architect' designation is more of a
role that can be occupied by Sr Software Engineers, people not on staff,
etc, with some clearly defined responsibilities as well as criteria for
occupying the role.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Yuvi Panda]

On Tue, Nov 5, 2013 at 6:07 PM, Chad  wrote:
> I'm in favor of option (C), mainly because I think that titles are pointless
> and
> lead to hat collecting and hurt feelings. I respect Brion, Mark and Tim (and
> many others) as architects because they *are* architects, not because we
> call them such.

+1. The respect they have is not because of them being labeled
Architects, but quite the inverse.

> For RFCs, I've been of the opinion we've made them entirely too formal. I'm
> glad we're trying to move them forward, but I've always thought they should
> be based on community consensus, not convincing an architect.

I actually like the formalism a bit - since it at least makes sure
that they don't rot. BDFLs are good.


-- 
Yuvi Panda T
http://yuvi.in/blog

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Rob Lanphier]

On Tue, Nov 5, 2013 at 6:02 PM, Yuvi Panda  wrote:

> On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller  wrote:
> > Option D: We come up with some kind of open process for
> > designating/confirming folks as architects, according to some
> > well-defined criteria (including minimum participation in the RFC
> > process, well-defined domain expertise in certain areas, a track
> > record of constructive engagement, etc.). Organizations like WMF can
> > choose to recognize this role as they see fit (likely according salary
> > increases to individuals who demonstrate successful architectural
> > leadership), but it’s a technical leadership role that’s awarded by
> > Wikimedia’s larger technical community, similar to +2 status.
>
> I like this in theory, though I fear that this will somehow lead to a
> state in some ways similar to the enwiki RfA process...
>

Hi Yuvi,

I think that's probably a good observation and comparison, but could you
expand on which qualities the RfA process you'd like to avoid?

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Chad]

On Tue, Nov 5, 2013 at 6:02 PM, Yuvi Panda  wrote:

> On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller  wrote:
> > Option D: We come up with some kind of open process for
> > designating/confirming folks as architects, according to some
> > well-defined criteria (including minimum participation in the RFC
> > process, well-defined domain expertise in certain areas, a track
> > record of constructive engagement, etc.). Organizations like WMF can
> > choose to recognize this role as they see fit (likely according salary
> > increases to individuals who demonstrate successful architectural
> > leadership), but it’s a technical leadership role that’s awarded by
> > Wikimedia’s larger technical community, similar to +2 status.
>
> I like this in theory, though I fear that this will somehow lead to a
> state in some ways similar to the enwiki RfA process...
>

Yeah.

I'm in favor of option (C), mainly because I think that titles are
pointless and
lead to hat collecting and hurt feelings. I respect Brion, Mark and Tim (and
many others) as architects because they *are* architects, not because we
call them such.

For RFCs, I've been of the opinion we've made them entirely too formal. I'm
glad we're trying to move them forward, but I've always thought they should
be based on community consensus, not convincing an architect.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Yuvi Panda]

On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller  wrote:
> Option D: We come up with some kind of open process for
> designating/confirming folks as architects, according to some
> well-defined criteria (including minimum participation in the RFC
> process, well-defined domain expertise in certain areas, a track
> record of constructive engagement, etc.). Organizations like WMF can
> choose to recognize this role as they see fit (likely according salary
> increases to individuals who demonstrate successful architectural
> leadership), but it’s a technical leadership role that’s awarded by
> Wikimedia’s larger technical community, similar to +2 status.

I like this in theory, though I fear that this will somehow lead to a
state in some ways similar to the enwiki RfA process...
-- 
Yuvi Panda T
http://yuvi.in/blog

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l