For what it's worth, my understanding is that WMF is considering transitioning portions of its annual planning to biannual planning.
Also, I think that it will be easier to develop a long term technical roadmap after WMF completes its strategy update. Pine On Wed, Mar 15, 2017 at 12:19 AM, Rogol Domedonfors <[email protected]> wrote: > A good way of avoiding clashes would be to publish the technical roadmap > showing where WMF expects to be taking its technical development over the > next five years or so, for the community to discuss and comment on I have > yet to hear any reason why this can not or should not be done. > > "Rogol" > > On Wed, Mar 15, 2017 at 1:48 AM, Pine W <[email protected]> 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. 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). 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 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. > > > > Pine > > _______________________________________________ > > Wikitech-l mailing list > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
