Legal position:
I have seen it claimed by legal and repeated here by Erik that the
"reasonableness" criteria means that we do not have to worry about the
CCBYSA-3.0 clause that says all copyright holders need equal attribution.
This is simply not so:
"The credit required by this Section 4(c) may be implemented *in any
reasonable manner; provided, however, that *in the case of a Adaptation or
Collection,* at a minimum such credit will appear*, if a credit for all
contributing authors of the Adaptation or Collection appears, then as part
of these credits and* in a manner at least as prominent as the credits for
the other contributing authors*."
There is no wriggle room here. * provided however that* means the following
is compulsory, and not subject to the lenience of the previous phraseology.
On 31 August 2014 16:59, Yann Forget <yannfo(a)gmail.com> wrote:
Hi all,
Thank you Erik for your mail. It shows that the WMF is willing to
discuss rather than to impose its solution.
I am really shocked that the dispute reaches that level of
confrontation, and although some community members have a hard stance,
this is largely due to WMF actions, specially the creation of the
"superprotect" right. This is the worst possible step the WMF could
make to find a solution for this issue.
Initially I was quite neutral about the MediaWiever, but I became
increasingly skeptical. IMO it is hardly a priority, even for readers.
Even if I am a long term contributor of Wikimedia projects, I am also
a heavy reader of Wikipedia. I think that if a feature is refused in
masse for the most active contributors, there is something wrong
either in the feature itself, or in the way it is proposed to the
projects. The WMF can certainly bring useful new additions in term of
software development, but the implementation has to be done in a
partnership with volunteer contributors. I cannot understand that the
WMF in spite of its multi-million dollars budget is not able to
convince volunteer contributors that the new feature is beneficial to
the projects, either because it is technically very good, or that even
with some shortcomings, it would improve the reading experience.
I am quite willing to test beta software, and I think there is no
urgency to impose the MediaWiever now to everybody. I could be done
after some time, when all issues have been sorted out. In term of
media management, the most urgent and important thing is to fix the
UploadWizard. Viewing images with Mediawiki may not be optimal, but it
is not broken. The UploadWizard is broken.
Regards,
Yann
2014-08-20 0:42 GMT+05:30 Erik Moeller <erik(a)wikimedia.org>rg>:
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:Meinungsbil…
[2]
https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&a…
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Sha…
[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
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>