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 <domedonfors(a)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.pine(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org