On Wed, Mar 15, 2017 at 2:48 AM, Pine W wiki.pine@gmail.com wrote:
Quim,
Thanks for the comments.
A brief note about the goal of "there are no clashes between product development teams and communities". That is an ambitious goal around here, partly because there are changes planned and happening concurrently in so many places that I think it would be a challenge to surface all potential conflicts early and make them visible to relevant community members. (As an example, a change that might be received favorably on Wiki A might generate a commotion on Wiki B because it broke an existing tool, made an existing workflow take longer, or conflicts with their community's priorities.
"No clashes" is a complex target indeed, but it is feasible.
It is important to have a definition of clash. Wiktionary offers "a hostile encounter" and "an angry argument", among others. Discrepancies and ongoing discussions don't constitute automatically a clash, as long as collaboration keeps happening.
For instance, your example of a new feature breaking a popular tool would be certainly a problem, but it would not constitute a clash if the new feature or the the tool are fixed quickly after the problem is reported, or the new feature is pulled until a solution is found.
A current example of this kind of situation is with Flow, which the last I heard is viewed favorably on Catalan Wikipedia and unfavorably on English Wikipedia).
A discussion in English Wikipedia ended up with the removal of Flow from that project with the agreement and the patches of the Flow developers. That would still count as collaboration, not a clash. Sometimes collaboration is not easy, but the parties still agree on finding the best next step together.
I'm not sure that clashes can be 100% prevented, but I'm thinking that once the Newsletter extension is working, that might be a useful way of informing more interested people in a more timely fashion about planned changes, and encouraging people to enroll as beta testers and translators, so that there are fewer surprises.
I fully agree with you. I personally have big hopes in the Newsletter extension enabling several specialized points of notifications, allowing more volunteers with more different interests and backgrounds to be informed about news and call for feedback interesting to them. Nowadays we rely too much on generic channels only (Village Pumps, mailing lists...), and this limits a lot the participation of qualified volunteers not having the time, patience or desire to join them.
Reaching out to more volunteers sooner and through specialized channels might prevent the risk of clashes better, not only because more problems can be detected before, also because discussions can become richer with more perspectives and experiences.
I think that what might be a more readily solvable problem would be a standardized way of resolving clashes between product teams and communities so that, when such clashes almost inevitably happen at some point, resolution comes sooner rather than later and hopefully in a way that is mutually acceptable. Perhaps that could be discussed in the Technical Collaboration Guidance document.
This is the intend of https://www.mediawiki.org/wiki/Technical_Collaboration_Guidance/Community_de... and suggestions are welcomed in the Talk page.