You mean like here: https://www.mediawiki.org/wiki/Roadmap ?
Where it is already posting it's annual and quarterly plans to as much detail as anyone is able to predict a roadmap ? No one from community is discussing it (at least other than those already discussing it before). This 'community participation' is nice and all, but time and again has shown, that most of the community simply doesn't have time to participate in mundane stuff like this. Which is logical, it's like asking all volunteers in the hospital to participate in hospital governance. Most of them are there to help patients, not to discuss politics. Of course, those who want to participate in governance should have the chance to involve themselves, and usually they do, but that's not most people. Also the community is heavily detached from practicalities that influence the planning and implementation, often causing them to go off into tangents that are super time intensive and inefficient for both parties, and not creating any additional value. It would be much better if we acknowledged such problems, rather than insist that there is a solution that we haven't spotted yet in 15 years... And that's exactly where I hope this guidance is going to land. A reference where we can mutually formalise our expectations, limitations and aspirations. DJ On Wed, Mar 15, 2017 at 8:19 AM, Rogol Domedonfors <domedonf...@gmail.com> 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 <wiki.p...@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. 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 > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
