Collecting hundred ideas is indeed easy.  I am sure that when I look back
in my 3000+ blog posts[1]  I will find hundreds of ideas easily. It is not
the numbers that important, it is about the relevance of the ideas, some of
mine are more relevant and others less so.

Arguments that are relevant are:

   - technical difficulty
   - impact on our community
   - impact on the amount of work it generates
   - impact on the ability to write new articles
   - impact on the ability to involve new editors
   - ability to generate meaningful statistics

The idea I proposed in this thread is likely to score really high except on
the first argument.

Would you for argument's sake walk through this idea with me and see your
process in action. The purpose would be to shine some light in the black
box. A fringe benefit could be to get a ball rolling.

[1] http://ultimategerardm.blogspot.nl/

On 14 July 2015 at 21:44, Luis Villa <lvi...@wikimedia.org> wrote:

> On Sun, Jul 12, 2015 at 2:52 AM, Gerard Meijssen <
> gerard.meijs...@gmail.com>
> wrote:
> > 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.
> >
> 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/08/01/free-software-usability
> >
>    .?
>    - *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_activities
> >
> ).
> The journey of hovercards
> <
> http://blog.wikimedia.org/2014/03/26/hovercards-now-available-as-a-beta-feature-on-all-wikimedia-wikis/
> >
> 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@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
Wikimedia-l mailing list, guidelines at: 
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Reply via email to