Quim,

I like the tone of these proposals.

I particularly like the concepts (some of which you mentioned) of:

* Limited-scale A/B tests in the wild prior to 100% deployments

* Community involvement in the  ideation and early product design phases

* Well-designed, short surveys with appropriate sampling (with a nod to
Edward'a possible role here) at various points in product development

* The development and use of SMART goals throughout the product design
process

* "Design thinking" about contributor workflows

Pine
On Jan 20, 2016 1:17 AM, "Quim Gil" <q...@wikimedia.org> wrote:

> Thank you for this interesting thread (and thank you for the interesting
> blog post in the first place). I'll pick a quote and I will try to propose
> ways forward about other comments made.
>
> On Mon, Jan 18, 2016 at 11:35 PM, Magnus Manske <
> magnusman...@googlemail.com
> > wrote:
>
> > I would hope the Foundation by now understands better how to handle new
> > software releases.
>
>
> I think so, although I'm sure the Foundation still needs to understand
> better how to handle new software releases -- and the communities too.
>
> https://www.mediawiki.org/wiki/WMF_product_development_process is the
> common protocol where we want to apply all the learning. Clarifying
> how community engagement works in this WMF product development process is a
> main priority for us during this quarter (
> https://phabricator.wikimedia.org/T124022
> ), and everybody is invited to join.
>
> I do think that we have many problems as software partners, the first
> problem being that we all got used to this situation of
> confrontation-by-default as something natural, they way it is. We are
> software partners, we really are, and in order to make this partnership
> productive we need to be in a mood of collaboration-by-default.
>
> We need a climate where new ideas are welcomed and encouraged. Today
> someone comes with a new idea and the chances are that the first replies
> setting the tone will be more discouraging than encouraging. We need a safe
> and exciting place where everybody can share new concepts, collaborate on
> them, learn from each other.
>
> We need a prioritization process where great concepts receive initial
> support for planning and prototyping, and where good plans and prototypes
> receive support to start their way toward production. The WMF needs to open
> that process to the participation of our communities, and our communities
> need to understand that this is the best point of time to discuss new
> plans.
>
> We need design and build processes that volunteers find easy to follow and
> participate in. There are many and very diverse groups of people (at
> Wikimedia and beyond)  that would give their feedback about design concepts
> or alpha releases if they would only know about them.
>
> We need to make our deployment process more flexible and predictable,
> allowing development teams and communities to agree on beta releases, A/B
> tests, opt-in/opt-out approaches, first/last waves... Some ideas:
>
> * In order to enter the deployment phase, a project would need to have a
> deployment plan proposed, agreed, and documented -- which can be adapted
> based on data and feedback gathered.
>
> * For every new product or significant feature, each community could have
> the chance to determine whether they want to be early adopters (first
> waves) or, on the contrary, be placed in the last waves, after seeing how
> the new software is being used by others and is being matured.
>
> * Communities would focus not so much on {{Support}} / {{Oppose}} decisions
> about the totality of a feature, but on the identification of specific
> blockers, allowing development teams to negotiate and change their plans
> under clearer terms.
>
> This common protocol should allow us to move away from the current
> situation where both communities and development teams fear that a single
> strike might disrupt their work overnight, without even seeing it coming.
>
> A more predictable path with specialized checkpoints should allow
> communities and development teams understanding better what is going on and
> when to talk about what. It should also help recruiting more and more
> diverse participants, who could contribute their time and skills in more
> daring and productive ways.
>
> What makes me optimistic about this common product development process is
> that we don't need to finalize all the pieces to make it work. As long as
> we agree that we are software partners and we agree that iterations are
> good, we can start agreeing on improvements and implement them one by one.
>
> Get involved, please. You can either join the more theoretical work about
> the overall process or you can pick a specific improvement and help pushing
> it forward in very practical terms. See you at
> https://www.mediawiki.org/wiki/Talk:WMF_product_development_process (where
> we have been a bit slow lately but not anymore now that is a top goal).
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: 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: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to