Is the *Technical Collaboration Guidance* https://www.mediawiki.org/wiki/Technical_Collaboration_Guidance still actively under development? There seems to have been no discussion of any substance since January. Is there an intention to bring the discussion to a close and to implement the guidance? Or is it going to fade quietly away like its predecessor, the stalled *WMF product development process* https://www.mediawiki.org/wiki/WMF_product_development_process ?
"Rogol"
On Sat, 2017-03-11 at 21:13 +0000, Rogol Domedonfors wrote:
Is the *Technical Collaboration Guidance* https://www.mediawiki.org/wiki/Technical_Collaboration_Guidance still actively under development? There seems to have been no discussion of any substance since January. Is there an intention to bring the discussion to a close and to implement the guidance? Or is it going to fade quietly away like its predecessor, the stalled *WMF product development process* https://www.mediawiki.org/wiki/WMF_product_development_process ?
It is being worked on; see https://phabricator.wikimedia.org/T138339
Cheers, andre
On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors domedonfors@gmail.com wrote:
Is the *Technical Collaboration Guidance* https://www.mediawiki.org/wiki/Technical_Collaboration_Guidance still actively under development?
Yes, there are internal stakeholder discussions still underway.
There seems to have been no discussion of any substance since January. Is there an intention to bring the discussion to a close
Eventually the plan is to remove the draft tag, yes.
and to implement the guidance?
As guidance, there is nothing to "implement" as you say. As has been discussed on the talk page, these are not rules to be placed into effect. This is a guidance manual from the TC team. The guidance is available for teams to check if they'd like a written resource for the type of work that Community Liaisons generally do.
Further questions are welcome on the talk page, where discussions can be properly captured on-wiki.
If there's not going to be anything to implement, how do you see this as having an effect on anything? What will be done differently or better? Why should anyone be doing any work on it? How will we know whether or not it has been a success, and whther or not the time effort and effort was well-spent?
"Rogol"
On Sat, Mar 11, 2017 at 10:35 PM, Keegan Peterzell <kpeterzell@wikimedia.org
wrote:
On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors domedonfors@gmail.com wrote:
Is the *Technical Collaboration Guidance* https://www.mediawiki.org/wiki/Technical_Collaboration_Guidance still actively under development?
Yes, there are internal stakeholder discussions still underway.
There seems to have been no discussion of any substance since January. Is there an intention to bring the discussion
to
a close
Eventually the plan is to remove the draft tag, yes.
and to implement the guidance?
As guidance, there is nothing to "implement" as you say. As has been discussed on the talk page, these are not rules to be placed into effect. This is a guidance manual from the TC team. The guidance is available for teams to check if they'd like a written resource for the type of work that Community Liaisons generally do.
Further questions are welcome on the talk page, where discussions can be properly captured on-wiki.
-- Keegan Peterzell Technical Collaboration Specialist Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Speaking generally, guidance can be helpful even if it's not a policy. English Wikipedia has similar ways of organizing information and how-to guides. Some guidance documents are categorized as essays, some as guidelines, and some as policies. It's worth noting that enforcement is, somewhat counter-intuitively, not tied directly to the "authority level" of a document. For example, the venerability policy is frequently violated but generally people are rarely blocked for violating it, while the exceptions to norms that are tolerated under "Ignore All Rules" have become thin as Wikipedia's complexity has grown and practices have become more detailed and standardized. (I believe that Aaron Halfaker has done some research on that last point.)
Pine
Pine
On Sun, Mar 12, 2017 at 1:24 AM, Rogol Domedonfors domedonfors@gmail.com wrote:
If there's not going to be anything to implement, how do you see this as having an effect on anything? What will be done differently or better? Why should anyone be doing any work on it? How will we know whether or not it has been a success, and whther or not the time effort and effort was well-spent?
"Rogol"
On Sat, Mar 11, 2017 at 10:35 PM, Keegan Peterzell < kpeterzell@wikimedia.org
wrote:
On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <
domedonfors@gmail.com>
wrote:
Is the *Technical Collaboration Guidance* https://www.mediawiki.org/wiki/Technical_Collaboration_Guidance still actively under development?
Yes, there are internal stakeholder discussions still underway.
There seems to have been no discussion of any substance since January. Is there an intention to bring the discussion
to
a close
Eventually the plan is to remove the draft tag, yes.
and to implement the guidance?
As guidance, there is nothing to "implement" as you say. As has been discussed on the talk page, these are not rules to be placed into effect. This is a guidance manual from the TC team. The guidance is available for teams to check if they'd like a written resource for the type of work
that
Community Liaisons generally do.
Further questions are welcome on the talk page, where discussions can be properly captured on-wiki.
-- Keegan Peterzell Technical Collaboration Specialist Wikimedia Foundation _______________________________________________ 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
Venerability policy? That's a new one. Verifiability policy. (Spellcheck is not always a wiki-lawyer's best friend.)
Pine
On Sun, Mar 12, 2017 at 12:55 PM, Pine W wiki.pine@gmail.com wrote:
Speaking generally, guidance can be helpful even if it's not a policy. English Wikipedia has similar ways of organizing information and how-to guides. Some guidance documents are categorized as essays, some as guidelines, and some as policies. It's worth noting that enforcement is, somewhat counter-intuitively, not tied directly to the "authority level" of a document. For example, the venerability policy is frequently violated but generally people are rarely blocked for violating it, while the exceptions to norms that are tolerated under "Ignore All Rules" have become thin as Wikipedia's complexity has grown and practices have become more detailed and standardized. (I believe that Aaron Halfaker has done some research on that last point.)
Pine
Pine
On Sun, Mar 12, 2017 at 1:24 AM, Rogol Domedonfors domedonfors@gmail.com wrote:
If there's not going to be anything to implement, how do you see this as having an effect on anything? What will be done differently or better? Why should anyone be doing any work on it? How will we know whether or not it has been a success, and whther or not the time effort and effort was well-spent?
"Rogol"
On Sat, Mar 11, 2017 at 10:35 PM, Keegan Peterzell < kpeterzell@wikimedia.org
wrote:
On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <
domedonfors@gmail.com>
wrote:
Is the *Technical Collaboration Guidance* https://www.mediawiki.org/wiki/Technical_Collaboration_Guidance still actively under development?
Yes, there are internal stakeholder discussions still underway.
There seems to have been no discussion of any substance since January. Is there an intention to bring the
discussion
to
a close
Eventually the plan is to remove the draft tag, yes.
and to implement the guidance?
As guidance, there is nothing to "implement" as you say. As has been discussed on the talk page, these are not rules to be placed into
effect.
This is a guidance manual from the TC team. The guidance is available
for
teams to check if they'd like a written resource for the type of work
that
Community Liaisons generally do.
Further questions are welcome on the talk page, where discussions can
be
properly captured on-wiki.
-- Keegan Peterzell Technical Collaboration Specialist Wikimedia Foundation _______________________________________________ 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
So to whom is this going to be helpful and how? That sounds like being implemented to me, but apparently that isnt going to happen.
On Sun, Mar 12, 2017 at 7:57 PM, Pine W wiki.pine@gmail.com wrote:
Venerability policy? That's a new one. Verifiability policy. (Spellcheck is not always a wiki-lawyer's best friend.)
Pine
On Sun, Mar 12, 2017 at 12:55 PM, Pine W wiki.pine@gmail.com wrote:
Speaking generally, guidance can be helpful even if it's not a policy. English Wikipedia has similar ways of organizing information and how-to guides. Some guidance documents are categorized as essays, some as guidelines, and some as policies. It's worth noting that enforcement is, somewhat counter-intuitively, not tied directly to the "authority level"
of
a document. For example, the venerability policy is frequently violated
but
generally people are rarely blocked for violating it, while the
exceptions
to norms that are tolerated under "Ignore All Rules" have become thin as Wikipedia's complexity has grown and practices have become more detailed and standardized. (I believe that Aaron Halfaker has done some research
on
that last point.)
Pine
Pine
On Sun, Mar 12, 2017 at 1:24 AM, Rogol Domedonfors <
domedonfors@gmail.com>
wrote:
If there's not going to be anything to implement, how do you see this as having an effect on anything? What will be done differently or better? Why should anyone be doing any work on it? How will we know whether or not it has been a success, and whther or not the time effort and effort was well-spent?
"Rogol"
On Sat, Mar 11, 2017 at 10:35 PM, Keegan Peterzell < kpeterzell@wikimedia.org
wrote:
On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <
domedonfors@gmail.com>
wrote:
Is the *Technical Collaboration Guidance* https://www.mediawiki.org/wiki/Technical_Collaboration_Guidance
still
actively under development?
Yes, there are internal stakeholder discussions still underway.
There seems to have been no discussion of any substance since January. Is there an intention to bring the
discussion
to
a close
Eventually the plan is to remove the draft tag, yes.
and to implement the guidance?
As guidance, there is nothing to "implement" as you say. As has been discussed on the talk page, these are not rules to be placed into
effect.
This is a guidance manual from the TC team. The guidance is available
for
teams to check if they'd like a written resource for the type of work
that
Community Liaisons generally do.
Further questions are welcome on the talk page, where discussions can
be
properly captured on-wiki.
-- Keegan Peterzell Technical Collaboration Specialist Wikimedia Foundation _______________________________________________ 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
Hi,
On Sun, Mar 12, 2017 at 10:24 AM, Rogol Domedonfors domedonfors@gmail.com wrote:
If there's not going to be anything to implement, how do you see this as having an effect on anything?
Documenting and promoting best practices tends to be useful for the awareness, adoption and refinement of those best practices.
Pine's answer about guidance/policies in Wikimedia is useful, thank you.
What will be done differently or better?
The goal is to have more consistent and predictable communication and decision processes across software projects and communities, allowing for an increase in awareness and involvement by a wider variety of volunteers, and the detection of requests and problems in the early stages of development.
Why should anyone be doing any work on it?
Because the current communication, discussion, and decision processes are not as systematic as we wish, this reduces the quantity and diversity of volunteers engaged, and therefore the quality and efficacy of the collaboration between product development teams and communities.
How will we know whether or not it has been a success, and whther or not the time effort and effort was well-spent?
Good question. I think we can consider the TCG as a useful tool when
* a healthy number of wiki projects want to be early adopters of new features * a healthy number of wiki projects have volunteers facilitating communication as tech ambassadors or translators * product development teams without a community liaison can successfully organize their community engagement activities following best practices * satisfaction levels about community engagement in product development are high * there are no clashes between product development teams and communities
There are other ideas about targets and metrics being discussed at https://phabricator.wikimedia.org/T132499
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
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@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
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 domedonfors@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@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
Derk-Jan
On Wed, Mar 15, 2017 at 12:29 PM, you wrote:
You mean like here: https://www.mediawiki.org/wiki/Roadmap ?
No, because that page is not a roadmap but a list of pages none of which is a roadmap in the sense I stated, and I rather think you knew that when you referrd to it.
Where it is already posting it's annual and quarterly plans to as much detail as anyone is able to predict a roadmap ?
A roadmap in the sense I asked for does not need to be detailed. It does need to be clear and comprehensible. It looks out further than the end of the current work year. We know that there are longer terms technical plans and projects (around parsers, editors and Flow) than these plans which all seem to send within the next few months.
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.
I wish that were ture, but it has not been my experience.
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.
This is exactly what I'm arguing for. But this guidance seems unlikely to achieve it.
"Rogol"
Derk-Jan
On Wed, Mar 15, 2017 at 12:29 PM, you wrote:
You mean like here: https://www.mediawiki.org/wiki/Roadmap ?
No, because that page is not a roadmap but a list of pages none of which is a roadmap in the sense I stated.
Where it is already posting it's annual and quarterly plans to as much detail as anyone is able to predict a roadmap ?
A roadmap in the sense I asked for does not need to be detailed. It does need to be clear and comprehensible. We know that there are longer terms technical plans and projects (around parsers, editors and Flow) than these plans which all seem to send within the next few months.
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 domedonfors@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@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
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@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@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
A biennial planning process makes a lot of sense, so long as transparency and accountability is not lost.
In the planning year, the most resource efficient way of doing this stuff is to make strategy and operations 6 months out of phase, ensuring that the management and executive don't exhaust themselves with an impossible burden. Going a step further and designing a biennial cycle, makes it possible to be more ambitious with a 24 month horizon rather than just the financial 12 months, so the organization can consider significant organizational changes to complete in that time, and be more transparent about being measured. For example, if something new is performing very badly in the first 3 months, the fact that you have up to 21 more months to turn it around, or completely reset, be creative, and still deliver against the measurable strategic targets, is much more realistic.
So, good, I hope the WMF jumps over to this way of working, they should be mature enough by now.
Fae
On 15 March 2017 at 17:46, Pine W wiki.pine@gmail.com wrote:
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@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@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
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.
wikitech-l@lists.wikimedia.org