On Thu, Jul 9, 2015 at 2:34 PM, Rogol Domedonfors <domedonfors(a)gmail.com> wrote: I'm going to respond more on-wiki, but tl;dr: I disagree strongly that "no one at WMF seems tasked with driving innovation".

Hoi, Luis I like what I read. What you can do to make it even more pleasing is establish better how this will benefit projects other than Wikipedia. For instance I blogged abut "red link" functionality that will easily enhance the quality of links and red links in most project including Wikipedia because it allows for providing information where there is none yet to bothnot readers and editors AND maintains the functionality as if nothing has changed. I have no idea if the WMF would consider such an idea. My impression is that the WMF and its agenda is very much a black box. When you explain how an idea like this might get attention, it is less theoretical and it explains me and others if innovation in the WMF has a place and what that place is. Thanks, GerardM http://ultimategerardm.blogspot.nl/2015/07/wikipedia-is-it-about-articles-o… On 12 July 2015 at 05:03, Luis Villa &lt;lvilla(a)wikimedia.org&gt; wrote: wrote: domedonfors(a)gmail.com https://meta.wikimedia.org/w/index.php?title=Innovation&type=revision&a… than share _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

On Sun, Jul 12, 2015 at 2:52 AM, Gerard Meijssen < gerard.meijssen(a)gmail.com&gt; wrote: how Hi, Gerard- Thanks for asking. I think calling us a "black box" on code/ideas from outside WMF is pretty fair, though we're working on it. *tl;dr:* this is and will always be hard; I'd love to hear thoughts or examples on how we can do it better. Note that I have not formally shared this thinking with product/engineering, so none of this is a promise to do any specific thing mentioned below. I share it to show, in good faith, that we're thinking hard about the problem and what to do about it, and to make clear why it isn't easy to solve. *Ideas* We can easily collect thousands of ideas. (For example, just one person already had a list of 200+ sorted/filed bugs ready when we announced community tech.) Sorting, prioritizing, and implementing them takes work (which non-programmers sometimes underestimate ;) <http://xkcd.com/1425/>. Some things we'd need in order to handle incoming ideas well: - *Overall process/timeline* for product development, so that people know who to talk to when and through what channels. CE is working with product/engineering on this, but it will always be ongoing - there won't be one "final" process, since we'll learn and adjust as we go. - *Clear priorities* - if you have 1,000 ideas, you have to have priorities so that you can sort through them, and decide "we'll do this one first because..." This is hard - there are still some people who respond to VE by disagreeing that we should be trying to get more new editors! - *A friendly space <https://meta.wikimedia.org/wiki/Grants:IdeaLab/Friendly_space> understanding* - people often get emotional/angry when you tell them their idea is not a high priority, or hard to understand, etc. Dealing with that once is easy; dealing with it repeatedly over months or years is literally threatening to mental health. - *Bodies:* Reading and processing incoming ideas can take a *ton* of time from the people involved. Andre helps with this somewhat in his role as bugmaster, but we're asking a lot from product and engineering already, so there is tension between "fix core platform issues" and "innovate within WMF" and "listen carefully to community innovation" - there are just a limited number of hours in the day. We've always done parts of this informally (ideas come in through phabricator; I read your blog post when it was first posted via planet; etc.) but we need to make it more formal if we want to seriously scale it. We're in the *extremely* initial brainstorming phases of some of this right now, which Lila referred to in her email. *Code* Innovative *code *should be easier to deal with than ideas, because writing code is hard so there is less code than ideas. But you still have to be able to deal with: - *Usability:* the innovative idea might be generally great, but has it had evaluative design research <https://www.mediawiki.org/wiki/Wikimedia_Research/Design_Research>? A/B testing of key concepts/language? Etc < https://web.archive.org/web/20080805012124/http://mpt.net.nz/archive/2008/0… .? - *Maintainability:* will the code still work in 2-3 years? Who will bugfix during that time? - *Scalability:* will it work for hundreds of millions of users? We address some of these currently simply by encouraging people to extend the platform and use Labs, rather than relying on us. So one possible option is to do more of that (like investing in APIs, as I mentioned in my innovation survey < https://meta.wikimedia.org/wiki/Innovation#Survey_of_WMF_innovation-related… ). The journey of hovercards < http://blog.wikimedia.org/2014/03/26/hovercards-now-available-as-a-beta-fea… is a pretty good example of the potential and difficulty of this process - we know we can turn non-WMF code into deployed code, but it is hard (and in that case still not done a year later). *Serious question* Those are my off-the-cuff, very long-term thinking about how we get community code into the projects at scale. Gerard, Magnus, others who write code - are there other routes I'm not seeing? Other things we could be doing? Luis [0] Hard enough that I don't think I've ever seen a mass-audience free/open project do it really well? _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>