Status of Technical Collaboration Guidance discussion

List overview All Threads
Download

newer

older

[Breaking Change]...

Please join the movement strategy...

Rogol Domedonfors

11 Mar 2017 11 Mar '17

9:13 p.m.

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"

Show replies by date

Andre Klapper

11 Mar 11 Mar

10:17 p.m.

On Sat, 2017-03-11 at 21:13 +0000, Rogol Domedonfors wrote:

...

It is being worked on; see https://phabricator.wikimedia.org/T138339 Cheers, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

Keegan Peterzell

10:35 p.m.

New subject: Status of Technical Collaboration Guidance discussion

On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <domedonfors(a)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

Rogol Domedonfors

12 Mar 12 Mar

9:24 a.m.

New subject: Status of Technical Collaboration Guidance discussion

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(a)wikimedia.org

...

wrote:

> On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <domedonfors(a)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(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

Pine W

7:55 p.m.

New subject: Status of Technical Collaboration Guidance discussion

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(a)gmail.com> wrote:

...

wrote:

On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <

domedonfors(a)gmail.com>

wrote:

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(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

Pine W

7:57 p.m.

New subject: Status of Technical Collaboration Guidance discussion

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(a)gmail.com> wrote:

...

wrote:

On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <

domedonfors(a)gmail.com>

wrote:

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

properly captured on-wiki. -- Keegan Peterzell Technical Collaboration Specialist Wikimedia Foundation _______________________________________________ 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

Rogol Domedonfors

8:15 p.m.

New subject: Status of Technical Collaboration Guidance discussion

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(a)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(a)gmail.com> wrote:

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

that last point.) Pine Pine On Sun, Mar 12, 2017 at 1:24 AM, Rogol Domedonfors <

domedonfors(a)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(a)wikimedia.org > > wrote: > > > On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors < > domedonfors(a)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

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Quim Gil

14 Mar 14 Mar

8:33 a.m.

New subject: Status of Technical Collaboration Guidance discussion

Hi, On Sun, Mar 12, 2017 at 10:24 AM, Rogol Domedonfors <domedonfors(a)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 Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Pine W

15 Mar 15 Mar

1:48 a.m.

New subject: Status of Technical Collaboration Guidance discussion

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

Rogol Domedonfors

7:19 a.m.

New subject: Status of Technical Collaboration Guidance discussion

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:

...

Derk-Jan Hartman

12:29 p.m.

New subject: Status of Technical Collaboration Guidance discussion

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(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

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

Rogol Domedonfors

6:20 p.m.

New subject: Status of Technical Collaboration Guidance discussion

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"

Rogol Domedonfors

6:30 p.m.

New subject: Status of Technical Collaboration Guidance discussion

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(a)gmail.com> wrote:

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

> 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

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

> 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

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

Pine W

5:46 p.m.

New subject: Status of Technical Collaboration Guidance discussion

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:

...

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,

example, a change that might be received favorably on Wiki A might

generate

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

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Fæ

6:24 p.m.

New subject: Status of Technical Collaboration Guidance discussion

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(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,

example, a change that might be received favorably on Wiki A might

generate

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

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae Personal and confidential, please do not circulate or re-quote.

Quim Gil

16 Mar 16 Mar

10:44 a.m.

New subject: Status of Technical Collaboration Guidance discussion

On Wed, Mar 15, 2017 at 2:48 AM, Pine W <wiki.pine(a)gmail.com> wrote:

...

"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_d… and suggestions are welcomed in the Talk page. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2599

days inactive

2604

days old

wikitech-l@lists.wikimedia.org

Manage subscription

15 comments

7 participants

tags (0)

participants (7)

Andre Klapper
Derk-Jan Hartman
Fæ
Keegan Peterzell
Pine W
Quim Gil
Rogol Domedonfors