Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Quim Gil]

On Wed, Mar 15, 2017 at 2:48 AM, Pine W  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_decisions
and suggestions are welcomed in the Talk page.

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Rogol Domedonfors]

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 
> 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  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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Fæ]

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



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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Rogol Domedonfors]

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"
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Pine W]

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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Derk-Jan Hartman]

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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Rogol Domedonfors]

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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Pine W]

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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Quim Gil]

Hi,

On Sun, Mar 12, 2017 at 10:24 AM, Rogol Domedonfors 
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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Rogol Domedonfors]

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  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  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 <
> domedonf...@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 <
> >> kpeterz...@wikimedia.org
> >> > wrote:
> >>
> >> > On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <
> >> domedonf...@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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Pine W]

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  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 
> 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 <
>> kpeterz...@wikimedia.org
>> > wrote:
>>
>> > On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <
>> domedonf...@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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Pine W]

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 
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 <
> kpeterz...@wikimedia.org
> > wrote:
>
> > On Sat, Mar 11, 2017 at 3:13 PM, Rogol Domedonfors <
> domedonf...@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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Rogol Domedonfors]

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  wrote:

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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Keegan Peterzell]

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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Andre Klapper]

On Sat, 2017-03-11 at 21:13 +, 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
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Status of Technical Collaboration Guidance discussion

[Rogol Domedonfors]

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"
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l