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 <yan...@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 <e...@wikimedia.org>: > > 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 > > Wikimedia-l@lists.wikimedia.org > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe> > > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > Wikimedia-l@lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe> > -- Landline (UK) 01780 757 250 Mobile (UK) 0798 1995 792 _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
