[Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

classic Classic list List threaded Threaded
146 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

[Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Erik Moeller-4
Hi folks,

This is a response to Martin's note here:
https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html

.. and also a more general update on the next steps regarding disputes
about deployments. As you may have seen, Lila has also posted an
update to her talk page, here:
https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together

I want to use this opportunity to respond to Martin's and other
people's criticisms, and to talk about next steps from WMF’s
perspective following discussions with Lila and the team. I’m also
sending a copy of this note to all the stewards, to better involve
them in the process going forward.

I am -- genuinely -- sorry that this escalation occurred. We would
have preferred to avoid it.

I would like to recap how we find ourselves in this situation: As
early as July, we stated that the Wikimedia Foundation reserves the
right to determine the final configuration of the MediaViewer feature,
and we explicitly included MediaWiki: namespace hacks in that
statement. [1] When an admin implemented a hack to disable
MediaViewer, another local admin reverted the edit. The original admin
reinstated it. We then reverted it with a clear warning that we may
limit editability of the page. [2] The original admin reinstated the
hack. This is when we protected the page.

Because all admins have equal access to the MediaWiki: namespace,
short of desysopping, there are few mechanisms to actually prevent
edit wars about the user experience for millions of readers.
Desysopping actions could have gotten just as messy -- and we felt
that waiting for a "better hack" to come along (the likeliest eventual
outcome of doing nothing) or disabling the feature ourselves would not
be any better, either from a process or outcome standpoint.

Our processes clearly need to be improved to avoid these situations in
the future. We recognize that simply rejecting a community request
rather than resolving a conflict together is not the right answer.
We’ve been listening to feedback, and we’ve come to the following
conclusions:

- We intend to undertake a review of our present processes immediately
and propose a new approach that allows for feedback at more critical
and relevant junctures in the next 90 days. This will be a transparent
process that includes your voices.

- As the WMF, we need to improve the process for managing changes that
impact all users. That includes the MediaWiki: namespace. For WMF to
fulfill its role of leading consistent improvements to the user
experience across Wikimedia projects, we need to be able to review
code and manage deployments. This can be done in partnership with
trusted volunteers, but WMF needs to be able to make an ultimate
determination after receiving community feedback regarding production
changes that impact all users.

- We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
and enter constructive, open-ended conversations about the way
forward, provided we can mutually agree to do so on the basis of the
current consistent configuration -- for now. We would like to request
a moratorium on any attempts to disable the feature during this
conflict resolution process. The goal would be to make a final,
cross-wiki determination regarding this specific feature, in
partnership with the community, within at most 90 days.

With regard to the German Wikipedia situation, we’d like to know if
stewards want to at all be involved in this process: In a situation
like this, it can be helpful to have a third party support the
conversation. Stewards are accountable to "valid community consensus
within the bounds of the Foundation's goals" [3], which seems to be
precisely the intersection of concerns at issue here. We would like to
suggest an IRC meeting with stewards ASAP to talk about the specific
question of stewards’ involvement, if any. If stewards prefer not to
be involved, we understand, but it's probably a good idea to have a
sync-up conversation regardless.

I hope we can move forward in good faith from here, and find better
ways to work together. As Lila has expressed, we believe there is a
need for a clear understanding of our role. It is as follows:

Managing software development, site configuration and deployment is a
core WMF responsibility. The community leads in the development of
content; the Wikimedia Foundation leads in the development of
technology.

Because these processes are deeply interdependent, we need to develop
better protocols for timely feedback and resolution of disagreements.
At the same time Lila’s and the Board’s statements make it very clear
that the WMF will not accept RfCs or votes as the sole determining
factor in global software deployments.

This means that technology and UX changes should not be decided by
vote or poll and then disabled at-will: where we disagree, we need to
talk to each other (and yes, that means a more judicious application
of RESOLVED WONTFIX on our end, as well!).  We need to ensure a
process where the community voice is heard earlier at critical
junctions in the product development. All of this is consistent with
the principle of "shared power" articulated in the Guiding Principles
[4] approved by the Board of Trustees.

At the same time, as noted above and earlier, the superprotection
feature should be replaced with a better mechanism for code review and
deployment in the MediaWiki: namespace. This is discussed in [5] and
ideas and suggestions are welcome. Let’s be upfront about control
structures for production changes to avoid misunderstandings and
ambiguity in the future.

We are exploring options on how to improve dispute resolution
mechanisms -- whether it’s e.g. a standing working group or a better
protocol for responding to RfCs and engaging in discussions. We've
started a brainstorming page, here, which we hope will usefully inform
the process of conflict resolution regarding German Wikipedia, as
well, so we can arrive at a more concrete conflict resolution process
soon. Your thoughts/suggestions are welcome, so we can (in NPOV style)
look at different possibilities (e.g. workgroups, committees, votes,
surveys) that have been discussed in the past:
https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas

We’re absolutely not saying that WMF simply wants to be able to
enforce its decisions: we completely understand there need to be
mechanisms for the community to influence decisions and outcomes at
all stages of the development and release of software. We need to
arrive at this process together.

Again, we are sorry that this escalation occurred - and we hope we can
move forward constructively from here.

Sincerely,

Erik


[1] https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbilder/Medienbetrachter&diff=prev&oldid=132469014

[2] https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&diff=132938244&oldid=132935469

[3] https://meta.wikimedia.org/wiki/Stewards_policy

[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shared_power

[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445


--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Martin Rulsch
Thank you, Erik, for your clarifications and understanding. Personally, I
hope that most anger will calm down now although not everyone will agree
with everything that was said or done (e.g. ignoring RfCs under some
conditions, using superprotect instead of counting on local procedures to
stop wheel warring) and we all can concentrate again on “working together
to make Wikimedia projects are more welcome place for readers, authors, and
anyone”. As this can only be done with mutual discussions, I'm looking
forward to the intensified inclusion of the communities for future software
developents as announced. Whether stewards can help here, I cannot tell,
but I would abstain myself from getting involved for obvious reasons.

Cheers,
Martin


2014-08-19 21:12 GMT+02:00 Erik Moeller <[hidden email]>:

> Hi folks,
>
> This is a response to Martin's note here:
> https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
>
> .. and also a more general update on the next steps regarding disputes
> about deployments. As you may have seen, Lila has also posted an
> update to her talk page, here:
> https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
>
> I want to use this opportunity to respond to Martin's and other
> people's criticisms, and to talk about next steps from WMF’s
> perspective following discussions with Lila and the team. I’m also
> sending a copy of this note to all the stewards, to better involve
> them in the process going forward.
>
> I am -- genuinely -- sorry that this escalation occurred. We would
> have preferred to avoid it.
>
> I would like to recap how we find ourselves in this situation: As
> early as July, we stated that the Wikimedia Foundation reserves the
> right to determine the final configuration of the MediaViewer feature,
> and we explicitly included MediaWiki: namespace hacks in that
> statement. [1] When an admin implemented a hack to disable
> MediaViewer, another local admin reverted the edit. The original admin
> reinstated it. We then reverted it with a clear warning that we may
> limit editability of the page. [2] The original admin reinstated the
> hack. This is when we protected the page.
>
> Because all admins have equal access to the MediaWiki: namespace,
> short of desysopping, there are few mechanisms to actually prevent
> edit wars about the user experience for millions of readers.
> Desysopping actions could have gotten just as messy -- and we felt
> that waiting for a "better hack" to come along (the likeliest eventual
> outcome of doing nothing) or disabling the feature ourselves would not
> be any better, either from a process or outcome standpoint.
>
> Our processes clearly need to be improved to avoid these situations in
> the future. We recognize that simply rejecting a community request
> rather than resolving a conflict together is not the right answer.
> We’ve been listening to feedback, and we’ve come to the following
> conclusions:
>
> - We intend to undertake a review of our present processes immediately
> and propose a new approach that allows for feedback at more critical
> and relevant junctures in the next 90 days. This will be a transparent
> process that includes your voices.
>
> - As the WMF, we need to improve the process for managing changes that
> impact all users. That includes the MediaWiki: namespace. For WMF to
> fulfill its role of leading consistent improvements to the user
> experience across Wikimedia projects, we need to be able to review
> code and manage deployments. This can be done in partnership with
> trusted volunteers, but WMF needs to be able to make an ultimate
> determination after receiving community feedback regarding production
> changes that impact all users.
>
> - We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
> and enter constructive, open-ended conversations about the way
> forward, provided we can mutually agree to do so on the basis of the
> current consistent configuration -- for now. We would like to request
> a moratorium on any attempts to disable the feature during this
> conflict resolution process. The goal would be to make a final,
> cross-wiki determination regarding this specific feature, in
> partnership with the community, within at most 90 days.
>
> With regard to the German Wikipedia situation, we’d like to know if
> stewards want to at all be involved in this process: In a situation
> like this, it can be helpful to have a third party support the
> conversation. Stewards are accountable to "valid community consensus
> within the bounds of the Foundation's goals" [3], which seems to be
> precisely the intersection of concerns at issue here. We would like to
> suggest an IRC meeting with stewards ASAP to talk about the specific
> question of stewards’ involvement, if any. If stewards prefer not to
> be involved, we understand, but it's probably a good idea to have a
> sync-up conversation regardless.
>
> I hope we can move forward in good faith from here, and find better
> ways to work together. As Lila has expressed, we believe there is a
> need for a clear understanding of our role. It is as follows:
>
> Managing software development, site configuration and deployment is a
> core WMF responsibility. The community leads in the development of
> content; the Wikimedia Foundation leads in the development of
> technology.
>
> Because these processes are deeply interdependent, we need to develop
> better protocols for timely feedback and resolution of disagreements.
> At the same time Lila’s and the Board’s statements make it very clear
> that the WMF will not accept RfCs or votes as the sole determining
> factor in global software deployments.
>
> This means that technology and UX changes should not be decided by
> vote or poll and then disabled at-will: where we disagree, we need to
> talk to each other (and yes, that means a more judicious application
> of RESOLVED WONTFIX on our end, as well!).  We need to ensure a
> process where the community voice is heard earlier at critical
> junctions in the product development. All of this is consistent with
> the principle of "shared power" articulated in the Guiding Principles
> [4] approved by the Board of Trustees.
>
> At the same time, as noted above and earlier, the superprotection
> feature should be replaced with a better mechanism for code review and
> deployment in the MediaWiki: namespace. This is discussed in [5] and
> ideas and suggestions are welcome. Let’s be upfront about control
> structures for production changes to avoid misunderstandings and
> ambiguity in the future.
>
> We are exploring options on how to improve dispute resolution
> mechanisms -- whether it’s e.g. a standing working group or a better
> protocol for responding to RfCs and engaging in discussions. We've
> started a brainstorming page, here, which we hope will usefully inform
> the process of conflict resolution regarding German Wikipedia, as
> well, so we can arrive at a more concrete conflict resolution process
> soon. Your thoughts/suggestions are welcome, so we can (in NPOV style)
> look at different possibilities (e.g. workgroups, committees, votes,
> surveys) that have been discussed in the past:
>
> https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
>
> We’re absolutely not saying that WMF simply wants to be able to
> enforce its decisions: we completely understand there need to be
> mechanisms for the community to influence decisions and outcomes at
> all stages of the development and release of software. We need to
> arrive at this process together.
>
> Again, we are sorry that this escalation occurred - and we hope we can
> move forward constructively from here.
>
> Sincerely,
>
> Erik
>
>
> [1]
> https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbilder/Medienbetrachter&diff=prev&oldid=132469014
>
> [2]
> https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&diff=132938244&oldid=132935469
>
> [3] https://meta.wikimedia.org/wiki/Stewards_policy
>
> [4]
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shared_power
>
> [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
>
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

David Cuenca Tudela
I think those are wonderful steps and I really hope that the German
wikipedians are ready for dialogue.
Given the big number of people that might want to answer Lila's questions,
shouldn't they be asked in a more public page, or organized in a more
international/multilingual way, for a delimited time, and open to everyone?
I think it is a perfect chance to ask broadly, but it needs to be organized
and framed appropriately, or the answers won't be useful (or usable).

For the sake of simplicity, I would ask only two questions:
What is the community that (each one of) you want to be in?
How much effort do you want to put to make it happen?

It is short, but its answer involves expected rights, and expected
obligations. If members expect to participate in decisions, then they have
to make an effort to follow tech issues. If members expect a nice
atmosphere, then they are also expected to contribute to that atmosphere by
acting civil at all times. I didn't like to see so much of aggresivity and
entitlement out of people that before didn't give a damn about notices.

At the moment it is not very clear what kind of community(ies) and
participation is wanted, or if each of its supposed members is ready to
make the necessary effort. In some places there are chapters, but that
might not be the answer for everyone.

Cheers,
Micru


On Tue, Aug 19, 2014 at 9:37 PM, Martin Rulsch <[hidden email]>
wrote:

> Thank you, Erik, for your clarifications and understanding. Personally, I
> hope that most anger will calm down now although not everyone will agree
> with everything that was said or done (e.g. ignoring RfCs under some
> conditions, using superprotect instead of counting on local procedures to
> stop wheel warring) and we all can concentrate again on “working together
> to make Wikimedia projects are more welcome place for readers, authors, and
> anyone”. As this can only be done with mutual discussions, I'm looking
> forward to the intensified inclusion of the communities for future software
> developents as announced. Whether stewards can help here, I cannot tell,
> but I would abstain myself from getting involved for obvious reasons.
>
> Cheers,
> Martin
>
>
> 2014-08-19 21:12 GMT+02:00 Erik Moeller <[hidden email]>:
>
> > Hi folks,
> >
> > This is a response to Martin's note here:
> >
> https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
> >
> > .. and also a more general update on the next steps regarding disputes
> > about deployments. As you may have seen, Lila has also posted an
> > update to her talk page, here:
> > https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
> >
> > I want to use this opportunity to respond to Martin's and other
> > people's criticisms, and to talk about next steps from WMF’s
> > perspective following discussions with Lila and the team. I’m also
> > sending a copy of this note to all the stewards, to better involve
> > them in the process going forward.
> >
> > I am -- genuinely -- sorry that this escalation occurred. We would
> > have preferred to avoid it.
> >
> > I would like to recap how we find ourselves in this situation: As
> > early as July, we stated that the Wikimedia Foundation reserves the
> > right to determine the final configuration of the MediaViewer feature,
> > and we explicitly included MediaWiki: namespace hacks in that
> > statement. [1] When an admin implemented a hack to disable
> > MediaViewer, another local admin reverted the edit. The original admin
> > reinstated it. We then reverted it with a clear warning that we may
> > limit editability of the page. [2] The original admin reinstated the
> > hack. This is when we protected the page.
> >
> > Because all admins have equal access to the MediaWiki: namespace,
> > short of desysopping, there are few mechanisms to actually prevent
> > edit wars about the user experience for millions of readers.
> > Desysopping actions could have gotten just as messy -- and we felt
> > that waiting for a "better hack" to come along (the likeliest eventual
> > outcome of doing nothing) or disabling the feature ourselves would not
> > be any better, either from a process or outcome standpoint.
> >
> > Our processes clearly need to be improved to avoid these situations in
> > the future. We recognize that simply rejecting a community request
> > rather than resolving a conflict together is not the right answer.
> > We’ve been listening to feedback, and we’ve come to the following
> > conclusions:
> >
> > - We intend to undertake a review of our present processes immediately
> > and propose a new approach that allows for feedback at more critical
> > and relevant junctures in the next 90 days. This will be a transparent
> > process that includes your voices.
> >
> > - As the WMF, we need to improve the process for managing changes that
> > impact all users. That includes the MediaWiki: namespace. For WMF to
> > fulfill its role of leading consistent improvements to the user
> > experience across Wikimedia projects, we need to be able to review
> > code and manage deployments. This can be done in partnership with
> > trusted volunteers, but WMF needs to be able to make an ultimate
> > determination after receiving community feedback regarding production
> > changes that impact all users.
> >
> > - We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
> > and enter constructive, open-ended conversations about the way
> > forward, provided we can mutually agree to do so on the basis of the
> > current consistent configuration -- for now. We would like to request
> > a moratorium on any attempts to disable the feature during this
> > conflict resolution process. The goal would be to make a final,
> > cross-wiki determination regarding this specific feature, in
> > partnership with the community, within at most 90 days.
> >
> > With regard to the German Wikipedia situation, we’d like to know if
> > stewards want to at all be involved in this process: In a situation
> > like this, it can be helpful to have a third party support the
> > conversation. Stewards are accountable to "valid community consensus
> > within the bounds of the Foundation's goals" [3], which seems to be
> > precisely the intersection of concerns at issue here. We would like to
> > suggest an IRC meeting with stewards ASAP to talk about the specific
> > question of stewards’ involvement, if any. If stewards prefer not to
> > be involved, we understand, but it's probably a good idea to have a
> > sync-up conversation regardless.
> >
> > I hope we can move forward in good faith from here, and find better
> > ways to work together. As Lila has expressed, we believe there is a
> > need for a clear understanding of our role. It is as follows:
> >
> > Managing software development, site configuration and deployment is a
> > core WMF responsibility. The community leads in the development of
> > content; the Wikimedia Foundation leads in the development of
> > technology.
> >
> > Because these processes are deeply interdependent, we need to develop
> > better protocols for timely feedback and resolution of disagreements.
> > At the same time Lila’s and the Board’s statements make it very clear
> > that the WMF will not accept RfCs or votes as the sole determining
> > factor in global software deployments.
> >
> > This means that technology and UX changes should not be decided by
> > vote or poll and then disabled at-will: where we disagree, we need to
> > talk to each other (and yes, that means a more judicious application
> > of RESOLVED WONTFIX on our end, as well!).  We need to ensure a
> > process where the community voice is heard earlier at critical
> > junctions in the product development. All of this is consistent with
> > the principle of "shared power" articulated in the Guiding Principles
> > [4] approved by the Board of Trustees.
> >
> > At the same time, as noted above and earlier, the superprotection
> > feature should be replaced with a better mechanism for code review and
> > deployment in the MediaWiki: namespace. This is discussed in [5] and
> > ideas and suggestions are welcome. Let’s be upfront about control
> > structures for production changes to avoid misunderstandings and
> > ambiguity in the future.
> >
> > We are exploring options on how to improve dispute resolution
> > mechanisms -- whether it’s e.g. a standing working group or a better
> > protocol for responding to RfCs and engaging in discussions. We've
> > started a brainstorming page, here, which we hope will usefully inform
> > the process of conflict resolution regarding German Wikipedia, as
> > well, so we can arrive at a more concrete conflict resolution process
> > soon. Your thoughts/suggestions are welcome, so we can (in NPOV style)
> > look at different possibilities (e.g. workgroups, committees, votes,
> > surveys) that have been discussed in the past:
> >
> >
> https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
> >
> > We’re absolutely not saying that WMF simply wants to be able to
> > enforce its decisions: we completely understand there need to be
> > mechanisms for the community to influence decisions and outcomes at
> > all stages of the development and release of software. We need to
> > arrive at this process together.
> >
> > Again, we are sorry that this escalation occurred - and we hope we can
> > move forward constructively from here.
> >
> > Sincerely,
> >
> > Erik
> >
> >
> > [1]
> >
> https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbilder/Medienbetrachter&diff=prev&oldid=132469014
> >
> > [2]
> >
> https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&diff=132938244&oldid=132935469
> >
> > [3] https://meta.wikimedia.org/wiki/Stewards_policy
> >
> > [4]
> >
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shared_power
> >
> > [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
> >
> >
> > --
> > Erik Möller
> > VP of Engineering and Product Development, Wikimedia Foundation
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>



--
Etiamsi omnes, ego non
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Andy Mabbett-2
In reply to this post by Erik Moeller-4
On 19 August 2014 20:12, Erik Moeller <[hidden email]> wrote:

Thank your for your lengthy and considered post. It's clear that you
and the WMF are seeking an amicable resolution, which is to be
applauded.

Nonetheless, I'm having difficulty understanding how these two statements:

> the Wikimedia Foundation reserves the right to determine the final
> configuration of the MediaViewer feature,

> We’re absolutely not saying that WMF simply wants to be able to
> enforce its decisions

can be reconciled.

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

MZMcBride-2
In reply to this post by Erik Moeller-4
Erik Moeller wrote:
>I am -- genuinely -- sorry that this escalation occurred. We would
>have preferred to avoid it.

I think making amends requires cleaning up the mess you've made on the
German Wikipedia and throughout the Wikimedia ecosystem. I don't think
many German Wikipedians or other Wikimedians will be willing to accept
your apology until super-protection is disabled. I hope you've been
following <https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Superschutz>.

>Our processes clearly need to be improved to avoid these situations in
>the future. We recognize that simply rejecting a community request
>rather than resolving a conflict together is not the right answer.

For sure. Thank you for this write-up.

But I continue to get the sense that the Wikimedia Foundation is looking
for ways to ask (and re-ask) "how much would you like to pay for this
horse?" and the editing community is responding with "no thank you, but
we would perhaps consider a car."

In the specific case, I think there's a common interest in improving file
description pages. Wikimedia readers and editors would certainly benefit,
as would MediaWiki users. File description pages could certainly use
design love, but rather than properly integrating with and improving
MediaWiki, we ended up with some JavaScript slapped on top via an
extension. There's a fundamental design flaw here, isn't there?

* The situation without MediaViewer: user clicks on an image, all the
  other content goes away, user is presented with a larger version of the
  image, its history, editing capability, and user can click the browser
  back button to return to the other content.

* The situation with MediaViewer: user clicks on an image, all the other
  content goes away, user is presented with a larger version of the image,
  no history or editing capability, and user can click the browser back
  button to return to the other content.

This is not really an improvement. Finite design and development resources
are being invested in new tools and what's the end result? And of course
MediaViewer came with an even higher cost given subsequent events.

In the general case, I think there are plenty of multimedia-related areas
in which Commoners and others would love design and development resources:
improved search (by file type, file size, color, content, etc.), an
in-browser SVG editor, an in-browser rasterized photo editor (even basic
support for cropping or rotating an image), the ability to easily rename a
category, and so on. I'm not sure why MediaViewer was worth the steep cost.

But more to the point, I think it would be helpful if the Wikimedia
Foundation could articulate a clear message about why these types of
"reader-focused" features are a worthwhile investment. I talk to a lot of
people about Wikipedia and the one complaint I _never_ hear is that
Wikipedia has a readership problem. It's a fact that the Wikimedia
Foundation typically embraces at every opportunity ("top-five Web site").
When I see reader-focused features such as ArticleFeedback and MoodBar and
MediaViewer being given substantial priority, urgency, and visibility, I
wonder what the rationale is. These types of features almost certainly
aren't attracting more readers and anecdotally they seem to be damaging
editors' relationships with the projects. Not exactly a great investment.

Despite the events of the past few weeks, I continue to trust you and I'm
hopeful about the path forward you and Lila have laid out regarding
community involvement in product development. Though it leads me to wonder
what the status is for hiring a VP of Engineering so that you can focus
exclusively on being the VP of Product Development.

MZMcBride



_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

rupert THURNER-2
In reply to this post by Martin Rulsch
thank you erik, and martin for this! currently more than 600 persons
express that this story should be resolved by reverting to the state
before it started:
https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Superschutz . while i
thought originally "who cares", i do think now beeing sorry is
expressed best by gesture not words.

rupert

On Tue, Aug 19, 2014 at 9:37 PM, Martin Rulsch
<[hidden email]> wrote:

> Thank you, Erik, for your clarifications and understanding. Personally, I
> hope that most anger will calm down now although not everyone will agree
> with everything that was said or done (e.g. ignoring RfCs under some
> conditions, using superprotect instead of counting on local procedures to
> stop wheel warring) and we all can concentrate again on “working together
> to make Wikimedia projects are more welcome place for readers, authors, and
> anyone”. As this can only be done with mutual discussions, I'm looking
> forward to the intensified inclusion of the communities for future software
> developents as announced. Whether stewards can help here, I cannot tell,
> but I would abstain myself from getting involved for obvious reasons.
>
> Cheers,
> Martin
>
>
> 2014-08-19 21:12 GMT+02:00 Erik Moeller <[hidden email]>:
>
>> Hi folks,
>>
>> This is a response to Martin's note here:
>> https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
>>
>> .. and also a more general update on the next steps regarding disputes
>> about deployments. As you may have seen, Lila has also posted an
>> update to her talk page, here:
>> https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
>>
>> I want to use this opportunity to respond to Martin's and other
>> people's criticisms, and to talk about next steps from WMF’s
>> perspective following discussions with Lila and the team. I’m also
>> sending a copy of this note to all the stewards, to better involve
>> them in the process going forward.
>>
>> I am -- genuinely -- sorry that this escalation occurred. We would
>> have preferred to avoid it.
>>
>> I would like to recap how we find ourselves in this situation: As
>> early as July, we stated that the Wikimedia Foundation reserves the
>> right to determine the final configuration of the MediaViewer feature,
>> and we explicitly included MediaWiki: namespace hacks in that
>> statement. [1] When an admin implemented a hack to disable
>> MediaViewer, another local admin reverted the edit. The original admin
>> reinstated it. We then reverted it with a clear warning that we may
>> limit editability of the page. [2] The original admin reinstated the
>> hack. This is when we protected the page.
>>
>> Because all admins have equal access to the MediaWiki: namespace,
>> short of desysopping, there are few mechanisms to actually prevent
>> edit wars about the user experience for millions of readers.
>> Desysopping actions could have gotten just as messy -- and we felt
>> that waiting for a "better hack" to come along (the likeliest eventual
>> outcome of doing nothing) or disabling the feature ourselves would not
>> be any better, either from a process or outcome standpoint.
>>
>> Our processes clearly need to be improved to avoid these situations in
>> the future. We recognize that simply rejecting a community request
>> rather than resolving a conflict together is not the right answer.
>> We’ve been listening to feedback, and we’ve come to the following
>> conclusions:
>>
>> - We intend to undertake a review of our present processes immediately
>> and propose a new approach that allows for feedback at more critical
>> and relevant junctures in the next 90 days. This will be a transparent
>> process that includes your voices.
>>
>> - As the WMF, we need to improve the process for managing changes that
>> impact all users. That includes the MediaWiki: namespace. For WMF to
>> fulfill its role of leading consistent improvements to the user
>> experience across Wikimedia projects, we need to be able to review
>> code and manage deployments. This can be done in partnership with
>> trusted volunteers, but WMF needs to be able to make an ultimate
>> determination after receiving community feedback regarding production
>> changes that impact all users.
>>
>> - We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
>> and enter constructive, open-ended conversations about the way
>> forward, provided we can mutually agree to do so on the basis of the
>> current consistent configuration -- for now. We would like to request
>> a moratorium on any attempts to disable the feature during this
>> conflict resolution process. The goal would be to make a final,
>> cross-wiki determination regarding this specific feature, in
>> partnership with the community, within at most 90 days.
>>
>> With regard to the German Wikipedia situation, we’d like to know if
>> stewards want to at all be involved in this process: In a situation
>> like this, it can be helpful to have a third party support the
>> conversation. Stewards are accountable to "valid community consensus
>> within the bounds of the Foundation's goals" [3], which seems to be
>> precisely the intersection of concerns at issue here. We would like to
>> suggest an IRC meeting with stewards ASAP to talk about the specific
>> question of stewards’ involvement, if any. If stewards prefer not to
>> be involved, we understand, but it's probably a good idea to have a
>> sync-up conversation regardless.
>>
>> I hope we can move forward in good faith from here, and find better
>> ways to work together. As Lila has expressed, we believe there is a
>> need for a clear understanding of our role. It is as follows:
>>
>> Managing software development, site configuration and deployment is a
>> core WMF responsibility. The community leads in the development of
>> content; the Wikimedia Foundation leads in the development of
>> technology.
>>
>> Because these processes are deeply interdependent, we need to develop
>> better protocols for timely feedback and resolution of disagreements.
>> At the same time Lila’s and the Board’s statements make it very clear
>> that the WMF will not accept RfCs or votes as the sole determining
>> factor in global software deployments.
>>
>> This means that technology and UX changes should not be decided by
>> vote or poll and then disabled at-will: where we disagree, we need to
>> talk to each other (and yes, that means a more judicious application
>> of RESOLVED WONTFIX on our end, as well!).  We need to ensure a
>> process where the community voice is heard earlier at critical
>> junctions in the product development. All of this is consistent with
>> the principle of "shared power" articulated in the Guiding Principles
>> [4] approved by the Board of Trustees.
>>
>> At the same time, as noted above and earlier, the superprotection
>> feature should be replaced with a better mechanism for code review and
>> deployment in the MediaWiki: namespace. This is discussed in [5] and
>> ideas and suggestions are welcome. Let’s be upfront about control
>> structures for production changes to avoid misunderstandings and
>> ambiguity in the future.
>>
>> We are exploring options on how to improve dispute resolution
>> mechanisms -- whether it’s e.g. a standing working group or a better
>> protocol for responding to RfCs and engaging in discussions. We've
>> started a brainstorming page, here, which we hope will usefully inform
>> the process of conflict resolution regarding German Wikipedia, as
>> well, so we can arrive at a more concrete conflict resolution process
>> soon. Your thoughts/suggestions are welcome, so we can (in NPOV style)
>> look at different possibilities (e.g. workgroups, committees, votes,
>> surveys) that have been discussed in the past:
>>
>> https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
>>
>> We’re absolutely not saying that WMF simply wants to be able to
>> enforce its decisions: we completely understand there need to be
>> mechanisms for the community to influence decisions and outcomes at
>> all stages of the development and release of software. We need to
>> arrive at this process together.
>>
>> Again, we are sorry that this escalation occurred - and we hope we can
>> move forward constructively from here.
>>
>> Sincerely,
>>
>> Erik
>>
>>
>> [1]
>> https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbilder/Medienbetrachter&diff=prev&oldid=132469014
>>
>> [2]
>> https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&diff=132938244&oldid=132935469
>>
>> [3] https://meta.wikimedia.org/wiki/Stewards_policy
>>
>> [4]
>> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shared_power
>>
>> [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
>>
>>
>> --
>> Erik Möller
>> VP of Engineering and Product Development, Wikimedia Foundation
>>
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> [hidden email]
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Erik Moeller-4
In reply to this post by Andy Mabbett-2
On Tue, Aug 19, 2014 at 2:18 PM, Andy Mabbett <[hidden email]> wrote:

> Nonetheless, I'm having difficulty understanding how these two statements:
>
>> the Wikimedia Foundation reserves the right to determine the final
>> configuration of the MediaViewer feature,
>
>> We’re absolutely not saying that WMF simply wants to be able to
>> enforce its decisions
>
> can be reconciled.

Hi Andy,

I think it's clear that we need to develop a social contract that
works for both parties. It doesn't work for communities if WMF simply
declares an independent decision after a vote or RFC takes place (and
yes, we have done so in this instance, and in others in the past). And
from WMF's point of view (for reasons we have already articulated
several times), it doesn't work to expect that WMF will implement
every vote or RFC as-is without negotiation or discussion, and without
room to take other factors into account.

When we talk about WMF's role, we need to distinguish between
technical processes and outcomes.

In order to ensure consistency (including on issues like release
planning, communications, bug reporting, etc.),  WMF needs to manage
the configuration and deployment _process_ (e.g. we flip the
switches). In order to be able to exercise its leadership role in
technology, it needs to have a say in the _outcome_, even if/when
there are RFCs/votes asking us to disable a feature.

That to me is what the "shared power" guiding principle means -- we
have clear roles and responsibilities, and we share in the
decision-making.

When we disagree, we need to figure things out together, hear each
other, and reason constructively. We don't have good conventions to do
that right now. The "community vote -> WMF responds yes/no" or
"community vote -> WMF responds with compromise" process is deeply
insufficient and one-sided. It's a win/lose process rather than a
process for working together.

We need to avoid getting to this place to begin with, but we also need
to have better answers when we do, as I'm sure we inevitably will
again from time to time.

This is what we're kicking around on the process ideas page:
https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas

Specifically, for something like Media Viewer, a lot of the issues
we've had to work through relate to community-created technology (!)
like custom templates used for certain purposes.

In these situations, sometimes the answer may be "Actually, what you
did here with a template is a horrible idea and you probably shouldn't
be doing it that way" -- and it's very hard for us to have these
conversations honestly if it's in an oppositional context with a group
of 200 people. And sometimes we need to support use cases that the
community cares very much about, even if our initial reaction is "Do
we _really_ have to do this?".

I think it needs to be much more tightly coupled, co-dependent working
relationship through the product's lifecycle so we can work together
honestly and with shared expertise.

That's true for VE, Flow, etc. as well -- we've tried the "light
touch" community liaison model but I think we need something that
brings us even closer together in day to day working practice. And my
experience with Wikimedia volunteers is that there are almost always
people willing to give their time if they feel it's actually valued in
the process. Not tens of hours a week of course (that's why we have
paid staff), but enough to stay informed and participate.

I could imagine having a process where, for any given project, there's
a nomination and lightweight election process that lets people
participate in associated communtiy task forces, which have weekly
check-ins with the product team and actually meaningfully influence
the roadmap. Is this something that people think could work? Has it
worked well in other contexts?

I think the inter-dependent relationship on technology is really
important to appreciate here -- it's something that's very unique to
us (because of the countless templates, tools, customizations, etc.
created by community members that interact with software we build).
You can't have it both ways -- a crazy amount of customizability by
the users themselves _and_ a very traditional relationship with
software development ("ship a finished product to us and then we'll
talk -- meanwhile let me add some parameters to this custom template
that I expect your product will support from day 1").

Erik

[1] http://strategy.wikimedia.org/wiki/Task_force


--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Erik Moeller-4
On Tue, Aug 19, 2014 at 11:48 PM, Erik Moeller <[hidden email]> wrote:

> [1] http://strategy.wikimedia.org/wiki/Task_force

I meant to say - the one example where we've tried targeted task
forces that I can think of was this one, as part of the strategy
process years ago. IIRC some of the task forces were pretty
productive, though the integration of their work in the final end
product was inconsistent. If product-related task forces actually were
part of the process of influencing the backlog, examining
data/findings, adding potential requirements, etc., that might be a
compelling way to work together.


--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Pine W
Erik,

I am curious to hear your thoughts about the proposed Technology Committee.
That idea has some community support and had been discussed at some length
on the WMF Board Noticeboard.

Pine
On Aug 19, 2014 11:55 PM, "Erik Moeller" <[hidden email]> wrote:

> On Tue, Aug 19, 2014 at 11:48 PM, Erik Moeller <[hidden email]> wrote:
>
> > [1] http://strategy.wikimedia.org/wiki/Task_force
>
> I meant to say - the one example where we've tried targeted task
> forces that I can think of was this one, as part of the strategy
> process years ago. IIRC some of the task forces were pretty
> productive, though the integration of their work in the final end
> product was inconsistent. If product-related task forces actually were
> part of the process of influencing the backlog, examining
> data/findings, adding potential requirements, etc., that might be a
> compelling way to work together.
>
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Anders Wennersten-2

Pine W skrev 2014-08-20 09:32:
> Erik,
>
> I am curious to hear your thoughts about the proposed Technology Committee.
> That idea has some community support and had been discussed at some length
> on the WMF Board Noticeboard.
I second that question

The mediaviewer has never been an issue on the Swedish community. After
our layout expert stated it was a good feature for the readers, we
editors quickly learned to opt out and continue our editing

I also have no problem accepting that the communities do not decide over
the UI to our readers. I also see very promising statement from Lila.

But i am missing the insight from both Erik and Lila that behind what is
being discussed is a key concern. Who decides over the development. And
here I believe, as I stated before, that a properly set up Technology
Committe is needed in order to ease the tensions in the movement
independent of iany mproved processes

Anders






_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Erik Moeller-4
In reply to this post by Pine W
On Wed, Aug 20, 2014 at 12:32 AM, Pine W <[hidden email]> wrote:
> I am curious to hear your thoughts about the proposed Technology Committee.
> That idea has some community support and had been discussed at some length
> on the WMF Board Noticeboard.

I think it has merits if it's mostly used as a dispute resolution
body. I think we need to have conflict resolution and escalation
protocols for technology issues. Ideally WMF and a group of community
members (whether in all cases truly representative or not) who are in
conflict about a certain issue or outcome should be able to come to a
consensus _between each other_. But when that's not possible, a group
that is designed to be accountable to both WMF's mission and the
community's consensus may need to be called upon to make a final call
that is binding. In the current governance structure, that could be a
group like the stewards. But it could be something new created for
that purpose, if the community supports it.

This all presupposes that we collectively sign up for this whole
"shared power" idea. It's a Board creation, a guiding principle, and
all that. But that doesn't mean the community of people who've spent
much of their lives building Wikimedia's projects as volunteers do
believe in it. Maybe we should ask them, as a group, offering the pros
and cons of that approach. It's very different futures -- a WMF that
exists purely to do what communities ask it to, or a WMF that exists -
in part - to look forward, close gaps, and help anticipate where we
want to be 3, 5, 10 years from now. Irrespective of what my own take
might be, both approaches do truly have their merits.

If we sign up collectively for "shared power", then today, we lack the
mechanisms to implement that principle effectively, which is why we
have conflicts over power which is not shared.  And a community
elected committee (perhaps with some additional representation of
external expertise) might be one such mechanism, but if we don't have
agreement on the basic idea, no mechanism will work. If we do agree on
the principle, we can try and play with different implementations.

Erik

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Erik Moeller-4
In reply to this post by MZMcBride-2
On Tue, Aug 19, 2014 at 6:09 PM, MZMcBride <[hidden email]> wrote:
> I don't think many German Wikipedians or other Wikimedians
> will be willing to accept your apology until super-protection is disabled.

Our suggestion, which we posted on German Wikipedia, is that we spend
some time talking to each other (up to 30 days, so not some indefinite
procrastination) without efforts to disable features via JavaScript
hacks, and without the page lock, to see if we can come to an
agreement on how to resolve the conflict. This is currently under
discussion there.

It would be disingenuous for WMF to declare "We will absolutely
refrain from using such a restriction ever again". In a conflict, my
recommendation is not to ask for a concession that would be only made
disingenuously, because it will not last. WMF, organizationally (as
has been made abundantly clear by Lila and the Board), is not
committed to the idea that some community members want us to be - that
we must always follow the outcome of a local vote or poll asking us to
do something, to its letter, without any room for discussion.

The underlying reasoning is simple - WMF wants to help ensure that
decisions are rational and well-informed consistent with its
understanding of a given situation, that we have a level of baseline
consistency of user experience, and that we challenge ourselves to
think through changes that may take some getting used to, but may
represent a long term improvement (with some allowance for iteration).

I know there are some who want to use this opportunity to cement a
different relationship - "WMF as servant", without a say. ("You are
the servant, not the master, and your opinion doesn't matter very
much." [1])  I understand that - I think it's rational, and
justifiable, and may even be the better direction in the long run. I
personally happen to disagree strongly with that belief, and the
organization's leadership certainly does, as well. I hope we can find
a middle ground, and I know that some of this is also just a reaction.

We understand that the only path forward that may be acceptable to
both parties is to act in a manner consistent with the  principle of
"shared power", which is why we suggest that we take some time to talk
things through with both parties refraining from using technical or
other means to force an outcome, and ideally aiming to completely
obviate any kind of escalation like this in future.

What's happening here is painful and difficult, and I'm sorry for our
role in that. I do believe it's necessary that we work through this,
and on a personal level, I honestly care more about doing that and
achieving some clarity on our working relationship with each other,
than about any specific outcome.

> But more to the point, I think it would be helpful if the Wikimedia
> Foundation could articulate a clear message about why these types of
> "reader-focused" features are a worthwhile investment. I talk to a lot of
> people about Wikipedia and the one complaint I _never_ hear is that
> Wikipedia has a readership problem. It's a fact that the Wikimedia
> Foundation typically embraces at every opportunity ("top-five Web site").

We are seeing pageviews flatten out, with most readership growth
coming from mobile at this point. It's not alarming yet - it's
consistent with the overall changes in user behavior - but of course
it does mean that especially the experience across devices is becoming
increasingly important.

The bulk of WMF's product development effort currently goes towards
contribution, not presentation, but we try to ensure that we have an
appropriate share of effort to modernize and improve the presentation
of information as a whole, to make it easier for people to navigate,
discover, re-use, etc. If you take a look at the mobile experience in
a desktop browser, you'll find it not so different from many redesigns
- large, readable text, narrower measure, deliberately chosen
typography, minimal clutter, easier access to footnotes, etc.

http://en.m.wikipedia.org/wiki/Liber_Eliensis

Needless to say, it's a lot easier to try new design ideas here, since
the level of investment of the community in the mobile experience is
not as great yet (it is growing, which will again increase the need
for us to have clear rules of engagement) and therefore the tolerance
for smaller imperfections is higher. This has enabled a healthy
pipeline of moving design changes from mobile to desktop - e.g. the
typography changes, and the soon to come frameless thumbs.

What does "modernize" really mean? Well, it means adapting to a
changing environment. Connections get faster, browsers become more
powerful, screen resolutions increase, web typography improves, new
interaction patterns become established in people's brains. In design
practice, this has had a number of effects for modern sites, including
larger images, greater focus on readable text, less clutter, etc.

It's appropriate for WMF to take into account the full breadth and
depth of devices that do exist and are in wide usage, more so than
sites developed for users in rich countries. Hence a greater focus on
things like image compression, overall page footprint, the
no-JavaScript experience, etc. But that's still consistent with
carefully updating the presentation. (Introducing a lightbox viewer in
2014 is not exactly a radically new vision for user experience.)

People have cited WikiWand as an example of a third party improved
reader experience. It's quite nicely done; I like a lot of the design
choices they've made. It's far from a threat (though a more prominent
"Edit" link would be nice, especially since the browser extension
hijacks wikipedia.org views), but it's the kind of cool third party
effort that keeps us honest. They recently raised about $600K in
funding, which means that at least some people believe there's a real
demand for a nicer, more modern default reader experience.

As a footnote, it shouldn't come as much of a surprise that WikiWand
includes a lightbox image viewer. I think it's better in some ways
than ours (e.g. I like the intelligent resizing of the image as you
expand the info panel, allowing you to browse at different sizes with
or without the full panel visible; also some nice subtle touches with
the animations). It gives less prominent attribution than MV does (you
have to expand it first), struggles with the same files that have
insanely complex descriptions, and fails on the same files with a
simple "License: Unkown" when no machine-readable data is available.
No full-size zoom or re-use features, as far as I can tell, but a nice
carousel navigation. (Just the kinds of things some people name as
reasons MV should never have seen the light of day, incidentally.)

Why is that interaction pattern so commonly used? Because it's a
smaller initial mental break when you read a text and want to simply
examine something like a photo, a map, or an illustration. Progressive
disclosure patterns are used to show additional information as
appropriate, with the initial focus being on the image and its caption
(using the same text that's used in the article, again both because
that text is likely the most immediately relevant, and it reduces the
cognitive break). Fast access to other media in the same article can
be a nice bonus for articles that are visually rich and readers who
are oriented to learning or discovering information in this manner.

Erik

[1] https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov&diff=prev&oldid=9568089
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

rupert THURNER-2
In reply to this post by Erik Moeller-4
Am 22.08.2014 04:18 schrieb "Erik Moeller" <[hidden email]>:
>
> On Wed, Aug 20, 2014 at 12:32 AM, Pine W <[hidden email]> wrote:
> > I am curious to hear your thoughts about the proposed Technology
Committee.
> > That idea has some community support and had been discussed at some
length

> > on the WMF Board Noticeboard.
>
> I think it has merits if it's mostly used as a dispute resolution
> body. I think we need to have conflict resolution and escalation
> protocols for technology issues. Ideally WMF and a group of community
> members (whether in all cases truly representative or not) who are in
> conflict about a certain issue or outcome should be able to come to a
> consensus _between each other_. But when that's not possible, a group
> that is designed to be accountable to both WMF's mission and the
> community's consensus may need to be called upon to make a final call
> that is binding. In the current governance structure, that could be a
> group like the stewards. But it could be something new created for
> that purpose, if the community supports it.
>
> This all presupposes that we collectively sign up for this whole
> "shared power" idea. It's a Board creation, a guiding principle, and
> all that. But that doesn't mean the community of people who've spent
> much of their lives building Wikimedia's projects as volunteers do
> believe in it. Maybe we should ask them, as a group, offering the pros
> and cons of that approach. It's very different futures -- a WMF that
> exists purely to do what communities ask it to, or a WMF that exists -
> in part - to look forward, close gaps, and help anticipate where we
> want to be 3, 5, 10 years from now. Irrespective of what my own take
> might be, both approaches do truly have their merits.
>
> If we sign up collectively for "shared power", then today, we lack the
> mechanisms to implement that principle effectively, which is why we
> have conflicts over power which is not shared.  And a community
> elected committee (perhaps with some additional representation of
> external expertise) might be one such mechanism, but if we don't have
> agreement on the basic idea, no mechanism will work. If we do agree on
> the principle, we can try and play with different implementations.
>

erik, let me ask a little in a devils advocate style:

is the conflict not only triggered by a deliverable which was not good
enough? it did not include the authors in its use cases. the deliverable
e.g. did include one click more for the authors workflow. which make
hundreds of million clicks more if you sum it up.

in a standard business world we would see two scenarios: one, the
ecyclopaedia britannica model. the authors would own the web domain, and
sue the one who delivers bad software. the design needs to be properly
specified beforehand to do this.

two, the facebook model. a company providing software to author as primary
goal, and some mechanism built in to count reads. it does everything to
increase it and would right from the start not deliver a complicated author
experience.

the wmf tries to play both models. and it then suffers schizophrenia. the
one delivering insufficient software does not get punished.

the reason is very simple: wikipedias content is of such high quality that
one might leave it with little updates for the next 20 years. also, the
readers experience is of such high quality that one might leave it for 20
years.

as somebody delivering software i understand your feelings quite well. you
get dug into a hole and do not know a good way to get out.

introducing additional levels of complexity is a well known strategy. but
we all know from our daily lives that we do tend to not like these levels
and bureaucracy.

erik, please can you tell me one good reason what hinders you to tackle the
source of all this, and rework the mediaviewer use case(s)?

devils adcocate mode out.

rupert
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Gerard Meijssen-3
Hoi,
I am happy for you that you think the reader experience is so great in the
"devils advocate mode". In reality when I read a Wikipedia article because
I want information all too often I hate what I get. The fact that it is the
best around does not make me like the lack of clarity, the inconsistency of
where information is found. All too often articles are written to overcome
the power struggle around NPOV and suffer as a result.

Erik indicated that WMF has written software predominantly for editors and
not for readers. All our projects suffer as a result from not getting to
our intended audience and not achieving what we aim to achieve; share in
the sum of all knowledge. Remember, our projects are first and foremost
about providing information / knowledge to people. We are stuck in the
process of producing the data that may once become information.

More focus on our end-users, even to the extend of "marketing" our data is
what will get us significantly more readers and consequently achieve our
goals more successfully.
Thanks,
     GerardM


On 22 August 2014 07:54, rupert THURNER <[hidden email]> wrote:

> Am 22.08.2014 04:18 schrieb "Erik Moeller" <[hidden email]>:
> >
> > On Wed, Aug 20, 2014 at 12:32 AM, Pine W <[hidden email]> wrote:
> > > I am curious to hear your thoughts about the proposed Technology
> Committee.
> > > That idea has some community support and had been discussed at some
> length
> > > on the WMF Board Noticeboard.
> >
> > I think it has merits if it's mostly used as a dispute resolution
> > body. I think we need to have conflict resolution and escalation
> > protocols for technology issues. Ideally WMF and a group of community
> > members (whether in all cases truly representative or not) who are in
> > conflict about a certain issue or outcome should be able to come to a
> > consensus _between each other_. But when that's not possible, a group
> > that is designed to be accountable to both WMF's mission and the
> > community's consensus may need to be called upon to make a final call
> > that is binding. In the current governance structure, that could be a
> > group like the stewards. But it could be something new created for
> > that purpose, if the community supports it.
> >
> > This all presupposes that we collectively sign up for this whole
> > "shared power" idea. It's a Board creation, a guiding principle, and
> > all that. But that doesn't mean the community of people who've spent
> > much of their lives building Wikimedia's projects as volunteers do
> > believe in it. Maybe we should ask them, as a group, offering the pros
> > and cons of that approach. It's very different futures -- a WMF that
> > exists purely to do what communities ask it to, or a WMF that exists -
> > in part - to look forward, close gaps, and help anticipate where we
> > want to be 3, 5, 10 years from now. Irrespective of what my own take
> > might be, both approaches do truly have their merits.
> >
> > If we sign up collectively for "shared power", then today, we lack the
> > mechanisms to implement that principle effectively, which is why we
> > have conflicts over power which is not shared.  And a community
> > elected committee (perhaps with some additional representation of
> > external expertise) might be one such mechanism, but if we don't have
> > agreement on the basic idea, no mechanism will work. If we do agree on
> > the principle, we can try and play with different implementations.
> >
>
> erik, let me ask a little in a devils advocate style:
>
> is the conflict not only triggered by a deliverable which was not good
> enough? it did not include the authors in its use cases. the deliverable
> e.g. did include one click more for the authors workflow. which make
> hundreds of million clicks more if you sum it up.
>
> in a standard business world we would see two scenarios: one, the
> ecyclopaedia britannica model. the authors would own the web domain, and
> sue the one who delivers bad software. the design needs to be properly
> specified beforehand to do this.
>
> two, the facebook model. a company providing software to author as primary
> goal, and some mechanism built in to count reads. it does everything to
> increase it and would right from the start not deliver a complicated author
> experience.
>
> the wmf tries to play both models. and it then suffers schizophrenia. the
> one delivering insufficient software does not get punished.
>
> the reason is very simple: wikipedias content is of such high quality that
> one might leave it with little updates for the next 20 years. also, the
> readers experience is of such high quality that one might leave it for 20
> years.
>
> as somebody delivering software i understand your feelings quite well. you
> get dug into a hole and do not know a good way to get out.
>
> introducing additional levels of complexity is a well known strategy. but
> we all know from our daily lives that we do tend to not like these levels
> and bureaucracy.
>
> erik, please can you tell me one good reason what hinders you to tackle the
> source of all this, and rework the mediaviewer use case(s)?
>
> devils adcocate mode out.
>
> rupert
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Dariusz Jemielniak-3
In reply to this post by rupert THURNER-2
one more general level solution would be having more steps: proposing a
solution to the community (checking for support), inviting willing testers,
after positive feedback introducing to all logged in users, and after
positive feedback propagating on the site as a whole.

Once the initial support for an idea is established, we can take for
granted that the change should happen - but it should be up to feedback to
see if the solution is ready, and not up to the developers' calendar (we've
all seen what happens when the schedule is the in the case of visual editor
premature launch).

I think that WMF perhaps takes way too little use of our community as
testers, commentators, supporters. If the community was more involved in
development plans, it would also not be surprised by solutions which
perhaps are important and wise in the log term, but still should not jump
out of the box and be perceived as forced.

I don't think it makes any sense to perceive WMF as just a servant. But how
should we perceive the community? Is it a disorganized mass with no uniform
voice, that should be shepherded into accepting solutions? Is it a valuable
resource? Is it a full partner in planning, testing and implementing the
solutions? I think that a lot of the latter is missing, and the fault is on
both sides. But it is mainly up to WMF to change it, as WMF has the
structures, staff, and resources to propose procedures there.

just my two cents, anyway.

dj "pundit"


On Fri, Aug 22, 2014 at 7:54 AM, rupert THURNER <[hidden email]>
wrote:

> Am 22.08.2014 04:18 schrieb "Erik Moeller" <[hidden email]>:
> >
> > On Wed, Aug 20, 2014 at 12:32 AM, Pine W <[hidden email]> wrote:
> > > I am curious to hear your thoughts about the proposed Technology
> Committee.
> > > That idea has some community support and had been discussed at some
> length
> > > on the WMF Board Noticeboard.
> >
> > I think it has merits if it's mostly used as a dispute resolution
> > body. I think we need to have conflict resolution and escalation
> > protocols for technology issues. Ideally WMF and a group of community
> > members (whether in all cases truly representative or not) who are in
> > conflict about a certain issue or outcome should be able to come to a
> > consensus _between each other_. But when that's not possible, a group
> > that is designed to be accountable to both WMF's mission and the
> > community's consensus may need to be called upon to make a final call
> > that is binding. In the current governance structure, that could be a
> > group like the stewards. But it could be something new created for
> > that purpose, if the community supports it.
> >
> > This all presupposes that we collectively sign up for this whole
> > "shared power" idea. It's a Board creation, a guiding principle, and
> > all that. But that doesn't mean the community of people who've spent
> > much of their lives building Wikimedia's projects as volunteers do
> > believe in it. Maybe we should ask them, as a group, offering the pros
> > and cons of that approach. It's very different futures -- a WMF that
> > exists purely to do what communities ask it to, or a WMF that exists -
> > in part - to look forward, close gaps, and help anticipate where we
> > want to be 3, 5, 10 years from now. Irrespective of what my own take
> > might be, both approaches do truly have their merits.
> >
> > If we sign up collectively for "shared power", then today, we lack the
> > mechanisms to implement that principle effectively, which is why we
> > have conflicts over power which is not shared.  And a community
> > elected committee (perhaps with some additional representation of
> > external expertise) might be one such mechanism, but if we don't have
> > agreement on the basic idea, no mechanism will work. If we do agree on
> > the principle, we can try and play with different implementations.
> >
>
> erik, let me ask a little in a devils advocate style:
>
> is the conflict not only triggered by a deliverable which was not good
> enough? it did not include the authors in its use cases. the deliverable
> e.g. did include one click more for the authors workflow. which make
> hundreds of million clicks more if you sum it up.
>
> in a standard business world we would see two scenarios: one, the
> ecyclopaedia britannica model. the authors would own the web domain, and
> sue the one who delivers bad software. the design needs to be properly
> specified beforehand to do this.
>
> two, the facebook model. a company providing software to author as primary
> goal, and some mechanism built in to count reads. it does everything to
> increase it and would right from the start not deliver a complicated author
> experience.
>
> the wmf tries to play both models. and it then suffers schizophrenia. the
> one delivering insufficient software does not get punished.
>
> the reason is very simple: wikipedias content is of such high quality that
> one might leave it with little updates for the next 20 years. also, the
> readers experience is of such high quality that one might leave it for 20
> years.
>
> as somebody delivering software i understand your feelings quite well. you
> get dug into a hole and do not know a good way to get out.
>
> introducing additional levels of complexity is a well known strategy. but
> we all know from our daily lives that we do tend to not like these levels
> and bureaucracy.
>
> erik, please can you tell me one good reason what hinders you to tackle the
> source of all this, and rework the mediaviewer use case(s)?
>
> devils adcocate mode out.
>
> rupert
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>



--

__________________________
prof. dr hab. Dariusz Jemielniak
kierownik katedry Zarządzania Międzynarodowego
i centrum badawczego CROW
Akademia Leona Koźmińskiego
http://www.crow.alk.edu.pl

członek Akademii Młodych Uczonych Polskiej Akademii Nauk
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Erik Moeller-4
In reply to this post by rupert THURNER-2
On Thu, Aug 21, 2014 at 10:54 PM, rupert THURNER
<[hidden email]> wrote:

> is the conflict not only triggered by a deliverable which was not good
> enough? it did not include the authors in its use cases. the deliverable
> e.g. did include one click more for the authors workflow. which make
> hundreds of million clicks more if you sum it up.

(...)

> erik, please can you tell me one good reason what hinders you to tackle the
> source of all this, and rework the mediaviewer use case(s)?

Rupert, I always like a good devil's advocate, especially when it
doesn't sound devil-ish at all. ;-)

Let's start with some facts:

- The MediaViewer rollout was very smooth until the deployments to
German Wikipedia, English Wikipedia and Wikimedia Commons. There could
be many reasons for that -- but it's a fact nonetheless. I do see
little evidence that users in other communities are especially unhappy
about the feature (leaving aside the politics of it now). I would be
very curious what reason people do attribute that difference to,
however (understanding that Commons is very different from the
Wikipedia use case).

- As a user, it's trivial to disable Media Viewer. Not quite as easy
as we want it to be, but literally a scroll-down and click away, which
is more than you can say about most MediaWiki preferences. It's also
trivial to skip on a case-by-case basis -- just open an image in a new
tab.

- Even on de.wp, if you read the comments from people supporting the
feature, in the poll leading up to Wikimania (a minority, but not a
tiny one - 72 voters in the poll [1]), you'll notice that the
reader/editor distinction isn't such a clear one. While many users
voted "on behalf of" readers, others pointed out that they themselves
like the fast access to the picture and switch back and forth as
needed (opening images in the background when they want to skip the
viewer). That was also what we heard from folks at Wikimania, for
example, and the generally low opt-out rates support it.

- The criticism isn't just about that -- it's about a large number of
mostly individually small issues. Generally, the idea that we
effectively "munge" some of the metadata by displaying a
machine-readable subset below the fold is viewed very negatively,
because 1) it doesn't reflect all the available information, 2) it
makes it harder for users to discover the File: page, and potentially
edit it.

Users who oppose the feature do not always do so strictly for personal
reasons, or many of them would probably be fine to disable it for
themselves; they often have criticisms that go beyond their own needs
and extend into areas like re-use, licensing information, and creating
an environment that draws people into contributing. Editors are not
blind to the needs of readers, they just have a low tolerance for
imperfections and would prefer to see a product that already addresses
all these concerns at the time of release.

We understand all that. We've read virtually every comment (surveys,
feedback page, votes/RFCs, etc.). I'm not normally as familiar with
every product WMF works on but by now I know many of the internals of
the damn thing (though Mark probably thanks the GNU deities daily that
I've not submitted any patches yet).

Change aversion is often [[loss aversion]] - people prefer avoiding
losses to making gains, which is why the positive benefits of a new
feature tend to be overshadowed quickly by any shortcomings, even if
they are (objectively speaking) comparatively small and easily
addressed.

It's true that we (WMF) should have done more early on to specifically
help with template cleanup -- we made some efforts to add
machine-readable data to key templates and rally community help, but
they were insufficient. This is not strictly an engineering problem -
the CommonsMetadata extension works just fine, the documentation is
clear, etc. It's an outreach effort that should have accompanied the
rollout more systematically. With that said, the needed fixes to
templates are fairly trivial (we just worked with de.wp to implement
one), while immediately resolving issues with license display for
large numbers of files, and help many other applications beyond the
viewer.

In addition, as previously noted [2], we're testing some pretty
significant changes of the UI, including a much more prominent
integration of the File: page link, identifying it clearly as the
canonical source of metadata.

We're not saying "You're wrong, we're right" - just that we understand
the issues pretty well, and we think the main concerns can likely be
addressed fairly quickly (and some already have been). In general, we
believe that there needs to be at least some allowance for iterating
on a release, rather than forcing an immediate revert. If we reason
things through together, try things out, look at the results, and
we're wrong, well, let's just turn the thing off completely rather
than making half-assed config changes in one wiki.

Mind you, in responding to the poll on de.wp, we didn't say "Thanks,
but no thanks" - we gave a detailed rationale, and we felt
(internally) that we were being reasonable in doing so, not that we
were being jerks, which explains at least partially why we then felt
maintaing that decision was appropriate. But I understand that even
the simple dynamic of "valid community process" -> "decision by WMF
that's not entirely consistent with it" leads to escalation, which is
why we're arguing for better process when we disagree.

Cheers,
Erik

[1] As a side note, in these conflicts, one of the things I'm most
frustrated by is that those voices of proponents tend to get lost.
Once it becomes about the power dynamic, the rational, supportive
arguments _by community members_ appear to carry no weight whatsoever,
and if anything, they risk being portrayed as stooges supporting the
Evil Bureaucracy. That doesn't strike me as consistent with the idea
of "consensus" either.

[2] https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073861.html
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Mike Linksvayer
In reply to this post by Erik Moeller-4
On 08/21/2014 07:17 PM, Erik Moeller wrote:
> It's very different futures -- a WMF that
> exists purely to do what communities ask it to, or a WMF that exists -
> in part - to look forward, close gaps, and help anticipate where we
> want to be 3, 5, 10 years from now. Irrespective of what my own take
> might be, both approaches do truly have their merits.

Along the same lines (by my reading) a week ago...

On 08/14/2014 02:57 AM, Erik Moeller wrote:
> If you want a WMF that slavishly implements RFCs or votes to disable
> features upon request, you'll need to petition to replace more than
> just one person. In fact, you should petition to reduce the staff
> dramatically, find an administrative ED who has no opinion on what to
> do, and exclusively focus on platform-level improvements and requests
> that clearly have community backing.

I'd enjoy reading about these very different futures. As a mostly casual
observer/fan of the various organizations and individuals of Wikimedia,
the futures don't seem necessarily different.

On looking forward -- big developments such as Wikidata (some kind of
semantic wiki database; yay!), Visual Editor (WYSIWYG editing),
Multimedia Viewer (more usable Commons; of these MV addresses the
smallest slice of the corresponding ur-wish), and Flow (more usable talk
pages) each reflect wishes expressed by many Wikip/medians for almost as
long as Wikipedia and Commons have existed, probably your expressions
and experiments being among the very earliest.

On resources, making reasonably fast progress only on features with
strong community backing would require a large paid staff, preferably
larger than what exists now.

In my limited view, WMF isn't especially visionary nor is it especially
authoritarian. What it has uniquely is the ability to do relatively
massive fundraising, and thus bring concentrated resources to bear.

I don't care about deployment disputes, and probably would never be
aware of them if I didn't follow this list and know some more active
Wikimedians socially. Hopefully some process is worked out that all in
some years see as a great innovation, or minimally, that all can forget
there was any dispute about.

But I am kind of concerned about what I perceive as an underlying theme,
with deployment disputes as a side effect: WMF as a product development
organization, some of the most passionate users of its products as
obstacles to innovation and optimization. That may be how other top n
websites are operated, but that's also how more numerous former top n
websites operated (of course I have no data). In the case of
commons-based peer production sites like Wikimedia ones, that dynamic
seems especially risky on one hand, and on the other, not leveraging the
their strengths. If communities aren't looking forward and anticipating
where we want to be 3, 5, 10 years from now (presumably facilitated by
WMF; I admired the strategy process some years ago but admittedly didn't
follow it closely enough to have an informed opinion) that's a serious
gap to close.

I expect all to muddle through, but seriously I would love to read about
(and see fully realized perhaps in new commons-based peer production
projects without organizational history) what exciting things WMF would
do if users weren't of concern (except as revealed by aggregate data and
experiments), and what a somehow user-direct-democracy version would do.
For my reading/observing satisfaction, I'd like them to have very
different results. Maybe former would quickly implement lessons from
gaming, some described by
http://www.raphkoster.com/2014/08/12/wikipedia-is-a-game/ (I'd enjoy
seeing them all tried in some commons-based peer production system)?
Maybe latter would use all that power to reform itself into being
predominantly friendly and welcoming (harder to imagine, but I'd love to
be surprised)? Or maybe the reverse!?

Mike

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Henning Schlottmann
In reply to this post by Erik Moeller-4
On 22.08.2014 09:22, Erik Moeller wrote:
>
> - The MediaViewer rollout was very smooth until the deployments to
> German Wikipedia, English Wikipedia and Wikimedia Commons. There could
> be many reasons for that -- but it's a fact nonetheless. I do see
> little evidence that users in other communities are especially unhappy
> about the feature (leaving aside the politics of it now). I would be
> very curious what reason people do attribute that difference to,
> however (understanding that Commons is very different from the
> Wikipedia use case).

This may or may not correlate with a deep commitment to a) the licenses,
b) quality.

> - The criticism isn't just about that -- it's about a large number of
> mostly individually small issues. Generally, the idea that we
> effectively "munge" some of the metadata by displaying a
> machine-readable subset below the fold is viewed very negatively,
> because 1) it doesn't reflect all the available information, 2) it
> makes it harder for users to discover the File: page, and potentially
> edit it.

If it does not reflect the license information it is broken.

The license is paramount. We can not accept any kind of software that
hands out "reuse information" that does not display the photographer's
name and the license (with link to the license text).

We do not want a default setting, that does not show extensive
descriptions, map legends, image annotations and the like. All that is
content we created for the readers. You must not block our readers from
this content.

MV is broken. It is not ready to be deployed. Not by far. Take it back
and fix it.

In theory I can see a working MV. I can even imagine a working Visual
Editor, but am very skeptical about it. I can not imagine Flow to work,
ever. This one needs to be abandoned now.

Eric, your department has an abysmal record. You have wasted millions on
software that started with the wrong framework and is not working after
years and years of development. Please think about yourself, not about
the communities if you want to understand about the conflicts at hand.

Henning


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Marc-Andre
In reply to this post by rupert THURNER-2
On 08/22/2014 01:54 AM, rupert THURNER wrote:
> is the conflict not only triggered by a deliverable which was not good
> enough?

Part of the difficulty of that statement is that the very /definition/
of "good enough" will necessarily vary from individual to individual,
with a non-zero segment of editors defining it as "absolutely perfect
and matching /my/ requirements exactly" (and another, just as large
segment, calling for "any improvement to X is a gain").

Regardless of one's opinions on the "power dynamics" of the situation,
or on how to best serve the short- and long-term needs of the community,
it seems to me evident that you cannot allow any one segment of the
community what amounts to veto power to any attempts at improvement.

So the difficulty becomes simply one of finding a way to adjucate.  It
seems to me that *any* movement in that direction is an improvement, so
long as it does not devolve in a simple game of numbers.  It needs
informed opinion, not popularity polls.

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

David Gerard-2
On 22 August 2014 14:42, Marc A. Pelletier <[hidden email]> wrote:

> Part of the difficulty of that statement is that the very /definition/
> of "good enough" will necessarily vary from individual to individual,
> with a non-zero segment of editors defining it as "absolutely perfect
> and matching /my/ requirements exactly" (and another, just as large
> segment, calling for "any improvement to X is a gain").


Just recently I had someone seriously claim "bah, if Flow doesn't
include [obscure feature I like] it won't be fit for purpose" in all
seriousness.


> Regardless of one's opinions on the "power dynamics" of the situation,
> or on how to best serve the short- and long-term needs of the community,
> it seems to me evident that you cannot allow any one segment of the
> community what amounts to veto power to any attempts at improvement.


I think it's indisputably clear that, no matter the level of and
efforts toward consultation, people will loudly claim it wasn't
enough.


- d.

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
1234 ... 8