As a former techie I find phabricator a difficult environment to bug
report in or lobby for a change. I sympathise with anyone as technical
than me or less who ventures there. Sometimes I'm left scratching my
head and wondering whether the closing of a bug or request and
redirecting to one that seems to me unrelated is an honest mistake, a
technically correct but buried in jargon move, or just vandalism.
Relations between techie and non techie are an important area for the
movement to work on. Whether the perceived improvements of the
Tretikova era were down to Lila, to others arriving, departing or
passing through; I hope that in future we try to do better there,
despite the loss of key people and the halving of the frequency of

On the broader issue of being tech led and narrowing focus; Arguably
one of our biggest problems is that Google, Firefox et al are finding
ways for people to access the content we create without the clutter of
edit buttons, and in some cases attribution and legalese. Think
Mediaviewer for everything, threatening the secret sauce that fuels
our movement. The Knowledge Engine may have been an attempted tech
response to that problem, but whether or not that could have succeeded
with a few extra tens of millions, it was a very expensive tech hammer
for a problem best approached by diplomacy backed up with lawyers. In
narrowing the WMFs focus we wound up using the wrong tool. I've
drafted an alternative approach here:


Jonathan / WereSpielChequers

> Message: 1
> Date: Thu, 25 Feb 2016 01:38:31 +0300
> From: Yuri Astrakhan <>
> To: Wikimedia Mailing List <>
> Subject: Re: [Wikimedia-l] Are we too rigid?
> Message-ID:

> Oliver, thanks!
>> In other words, the litmus test for me is: what happens when the socially
> and politically weakest person in the organisation has an idea?
> If we speak of a "product" idea, we have two groups of people - those who
> can implement the idea, and those who would need to convince others to do
> it.  They use fundamentally different, scarcely overlapping skill-sets. An
> engineer might go via the "hackathon + demo" route, implementing something
> simple and showing it to gain traction. A non-engineer would start with the
> social aspect first - talking to others if the idea is worth pursuing, how
> hard is it to do, and eventually - convincing others to allocate their
> time/resources to do it. Sometimes an engineer may go the social route
> instead, but it would be very hard for a non-engineer to engage in
> development. Lastly, the "designer" group has an amazing skill-set to
> visually present their full vision rather than the demo, thus often having
> easier time of conveying their thoughts.
> In a sense, the barrier of entry for the person in the "weakest position"
> would not be as high for the "doer" as for the "inspirer". So I think the
> real challenge is how do we capture and evaluate those ideas from the
> second group? Also, no matter how hard we try, it would be either very
> hard, or very expensive (and not just financially) to force the
> implementers to do an idea they do not believe in. So in a sense, doers
> need to be persuaded first and foremost.
> As with any explanation, a picture == 1000 words, so we could promote "idea
> visualizers" - designers who are easily approachable and could help to draw
> up a few sketches of the idea.

Wikimedia-l mailing list, guidelines at:
New messages to:

Reply via email to