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 < magnusmanske(a)googlemail.com 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(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

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 < magnusmanske(a)googlemail.com 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(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>