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" <[email protected]> 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 < > [email protected] > > 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: [email protected] > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:[email protected]?subject=unsubscribe> _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[email protected]?subject=unsubscribe>
