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 Wikimania.
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: https://meta.wikimedia.org/wiki/Talk:2016_Strategy/Reach#WereSpielChequers
TTFN
Jonathan / WereSpielChequers
Message: 1 Date: Thu, 25 Feb 2016 01:38:31 +0300 From: Yuri Astrakhan yastrakhan@wikimedia.org To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org 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.