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@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
Hoi, One issue is that with phabricator the discussion has been largely moved to .. phabricator. That is normal however, following what happens there and finding where a discussion should/could rage takes a substantial effort.
For me phabricator is a painful experience, it often does not work for me. It is why I do not write about my red link/wiki link suggestion even though I am certain it will improve quality.
So yes, we need to talk but the talk does not happen in one place. When you insist on one place, the confrontation is already in place. Thanks, GerardM
On 20 January 2016 at 10:17, Quim Gil qgil@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 < magnusmanske@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-request@lists.wikimedia.org?subject=unsubscribe
Hi,
On Wed, Jan 20, 2016 at 10:27 AM, Gerard Meijssen <gerard.meijssen@gmail.com
wrote:
So yes, we need to talk but the talk does not happen in one place. When you insist on one place, the confrontation is already in place.
The solution is not to move all the communication to Phabricator, that is for sure. The solution cannot be to have WMF employees watching every channel for feedback either.
There are two important aspects to consider:
1. "The talk" is useful when the relevant information reaches the development team and influences their work.
Talks may happen in many places as long as there is a bridge connecting them to the development team. Teams can listen a bit, with the help of Community Liaisons (WMF) they can hear a bit more, but that support is also limited. Volunteer Tech Ambassadors can provide more bridges to more conversation, but we (all of us) still need to consolidate and promote this key role.
2. The medium is the message
"The talk" is useful as long as it helps getting things done. Mailing lists and wiki discussion pages are designed to discuss. Project management tools are designed to get things done. No matter how smart and constructive the talk is (like in this thread), all those moments will be lost in time, like tears...in...rain. However, when the relevant bits are converted into Phabricator tasks populating workboards and blocking goals... forgetting is still possible but more complicated.
This is why thanks to you Gerard, I finally found the motivation to create this task:
Communication channels between communities and teams involved in the product development process https://phabricator.wikimedia.org/T124288
:)
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" qgil@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 < magnusmanske@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-request@lists.wikimedia.org?subject=unsubscribe
+1 I also like this tone and agree both with everything Magnus has claimed and with Quim's ideas of opening specific Phabricator tasks to move forward. I think a big problem is how to inform people during product launch. I think the media viewer would have been launched more smoothly if the viewer had the "turn this new feature off" button placed more prominently in the first few weeks of introduction, for logged in users of all kinds, both readers as well as editors. The main problem there was that the media viewer had a negative impact on the workflow for many Wiki(p/m)edians, and because there was no formal study of editor workflows beforehand, this was entirely overlooked. Readers of maps and other files that use the annotator were also locked out from that content for a fairly long period of time.
Moving forward, more attention must be paid to documenting existing reader and editor workflows, gnarly as this may sound to achieve. Once done however, optimization of such workflows should be much, much easier. After viewing that video from Mexico Wikimania of a mobile-user's editing workflow with the Visual Editor I was shocked to think that there are people out there trying so hard and moving so slowly to achieve their wiki goals. We really need to spend time on this, because mobile will only become more and more important. I for one don't see myself making the switch to Visual Editor any time soon, though I do use several other websites regularly on mobile.
As far as asking the WMF only to "build what the community wants", I strongly disagree. I have become a regular user of Facebook to augment my onwiki work, and a few years ago if you had asked me whether I would find Wiki(p/m)edians on Facebook I would have said "No Way!"
On Wed, Jan 20, 2016 at 10:36 AM, Pine W wiki.pine@gmail.com wrote:
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" qgil@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 < magnusmanske@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-request@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-request@lists.wikimedia.org?subject=unsubscribe
This:
On 20/01/16 10:41, Jane Darnell wrote:
Moving forward, more attention must be paid to documenting existing reader and editor workflows, gnarly as this may sound to achieve. Once done however, optimization of such workflows should be much, much easier. After viewing that video from Mexico Wikimania of a mobile-user's editing workflow with the Visual Editor I was shocked to think that there are people out there trying so hard and moving so slowly to achieve their wiki goals. We really need to spend time on this, because mobile will only become more and more important. I for one don't see myself making the switch to Visual Editor any time soon, though I do use several other websites regularly on mobile.
As far as asking the WMF only to "build what the community wants", I strongly disagree. I have become a regular user of Facebook to augment my onwiki work, and a few years ago if you had asked me whether I would find Wiki(p/m)edians on Facebook I would have said "No Way!"
I would entirely agree. Deployment practices have definitely been an issue, with a notable example in particular being VE's initial premature release, but where things also tend to particularly fall short is research into what people are actually doing with the projects, and why. We talk about community consultations and notifying all the users ahead of time, but the fact of the matter is that most of the community doesn't give a shit, nor should they. They don't want to leave what they're currently working on to go comment on things, they aren't watching for stuff to jump on; they have limited time and they want to spend that just working on what they want to work on. This is what the WMF should be supporting, and when it succeeds, when things just get better without requiring extra effort on the part of the users, users tend to be pretty happy about it. And we don't hear about it because they usually express that happiness by continuing to putter around writing stuff or fixing categories or whatever it is they were doing in the first place. And that's good. We need them to do that.
The problem is when changes make it harder for these users, and that's when they get mad and quit working on their stuffs and start yelling. This is what happened with MV - despite being a concept a lot of us really did want (because the primary use case clicking on pictures is indeed just to see it bigger), in particular its implementation simply did not account for the reality of how files are documented or how the use cases of different projects, well, differ.
And looking at these things should be the first step. You look at what's on the wiki, at what the users are doing, actually doing now, and you work with that, talk to some of them, address the problems they've noticed they have, as well as the problems they haven't noticed they have but that still slow them down, that's useful. That's how you fix broken things and build valuable tools, but that's just not what a lot of Wikimedia's development and design has been (that VE has been doing this I think is a good chunk of why it's so powerful now). No, the ideas don't need to come from the community, it certainly doesn't all have to be 'what the community wants' (like with facebook, helpful things are often not what occurs to anyone off the bat), but it should be helpful. And the WMF should have the resources to determine what would be helpful.
Does it?
-I
wikimedia-l@lists.wikimedia.org