Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you
On Aug 17, 2014 6:49 AM, Richard Farmbrough rich...@farmbrough.co.uk wrote: There are 105 bugs open for Media Viewer. To my mind that is not a product that is ready to be delivered to 500,000,000 users, delivering 52.5 billion bugs! (And that's just the ones we know about!) MediaWiki itself has 4893 open bugs. Guess we need to start over so we can write bug-free software. Except that's not how it works, absolute bug counts are a pretty useless metric. -Chad ___ 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
Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you
yes but mediawiki is a software, not an add-on or as the kids say these days, an App which is what Media Viewer is. Enforcing something with more than a 100 bugs (and counting) is indeed not a very super idea..Fix the bugs or atleast half of them and maybe then try enforcing them (as WMF ignores community decisions).. On 8/17/14, Chad Horohoe choro...@wikimedia.org wrote: On Aug 17, 2014 6:49 AM, Richard Farmbrough rich...@farmbrough.co.uk wrote: There are 105 bugs open for Media Viewer. To my mind that is not a product that is ready to be delivered to 500,000,000 users, delivering 52.5 billion bugs! (And that's just the ones we know about!) MediaWiki itself has 4893 open bugs. Guess we need to start over so we can write bug-free software. Except that's not how it works, absolute bug counts are a pretty useless metric. -Chad ___ 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 -- Cometstyles ___ 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
Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you
And that is a common community complaint, games communities, social communities, and content communities. They all say fix the bugs before working on new stuff. Developers prefer working on new stuff, managers prefer working on new stuff. Where's the kudos from making things bug-free? But that is what is needed. On 17 August 2014 13:48, Comet styles cometsty...@gmail.com wrote: yes but mediawiki is a software, not an add-on or as the kids say these days, an App which is what Media Viewer is. Enforcing something with more than a 100 bugs (and counting) is indeed not a very super idea..Fix the bugs or atleast half of them and maybe then try enforcing them (as WMF ignores community decisions).. On 8/17/14, Chad Horohoe choro...@wikimedia.org wrote: On Aug 17, 2014 6:49 AM, Richard Farmbrough rich...@farmbrough.co.uk wrote: There are 105 bugs open for Media Viewer. To my mind that is not a product that is ready to be delivered to 500,000,000 users, delivering 52.5 billion bugs! (And that's just the ones we know about!) MediaWiki itself has 4893 open bugs. Guess we need to start over so we can write bug-free software. Except that's not how it works, absolute bug counts are a pretty useless metric. -Chad ___ 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 -- Cometstyles ___ 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
Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you
I think it is also a problem to look at this in terms of bugs. I don't think you can retrofit good design into something that has a variety of substantial problems, by merely squashing bugs. You might say that is the wiki way, but it is widely known that some tasks are better suited than others to ad hoc collaborative processes. In this case, we have a broad range of issues: * does it let the reader know they can help improve the page or upload another photo * does it reflect copyright holders' licenses accurately and effectively * does it adequately respect the privacy of the subjects of photos * does it reflect a look and feel that we feel OK about and is consistent with the rest of the software etc. etc. Fixing one bug may well lead to other bugs, or negatively impact those already reported. What is needed, I believe, is a well-facilitated process to identify the problems and the best solutions. This is not easy to do and takes time. But I think the WMF has (not for lack of trying) managed to do a very bad job of that with this software product, and with many software products in the last few years. That does not mean it is impossible to do it that way, only that those specific efforts were insufficient. An example of a design process that DID work well, I believe, is the 2012 rewrite of the Terms of Use. The goals were clearly stated upfront, a deadline was stated *and then moved* when it was determined that it was too soon and good work was being done, the discussion was facilitated in a highly useful way (noting things that are off topic, closing issues as they are resolved, actively drawing in staff as needed, etc.) -Pete [[User:Peteforsyth]] On Sun, Aug 17, 2014 at 4:46 PM, Richard Farmbrough rich...@farmbrough.co.uk wrote: And that is a common community complaint, games communities, social communities, and content communities. They all say fix the bugs before working on new stuff. Developers prefer working on new stuff, managers prefer working on new stuff. Where's the kudos from making things bug-free? But that is what is needed. On 17 August 2014 13:48, Comet styles cometsty...@gmail.com wrote: yes but mediawiki is a software, not an add-on or as the kids say these days, an App which is what Media Viewer is. Enforcing something with more than a 100 bugs (and counting) is indeed not a very super idea..Fix the bugs or atleast half of them and maybe then try enforcing them (as WMF ignores community decisions).. On 8/17/14, Chad Horohoe choro...@wikimedia.org wrote: On Aug 17, 2014 6:49 AM, Richard Farmbrough rich...@farmbrough.co.uk wrote: There are 105 bugs open for Media Viewer. To my mind that is not a product that is ready to be delivered to 500,000,000 users, delivering 52.5 billion bugs! (And that's just the ones we know about!) MediaWiki itself has 4893 open bugs. Guess we need to start over so we can write bug-free software. Except that's not how it works, absolute bug counts are a pretty useless metric. -Chad ___ 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 -- Cometstyles ___ 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 ___ 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
Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you
Well, hold on here. On 17 August 2014 19:55, Pete Forsyth petefors...@gmail.com wrote: I think it is also a problem to look at this in terms of bugs. I don't think you can retrofit good design into something that has a variety of substantial problems, by merely squashing bugs. You might say that is the wiki way, but it is widely known that some tasks are better suited than others to ad hoc collaborative processes. Given the current use of bugzilla, which doesn't limit itself to bugs but also feature requests and enhancements over the base functionality, calling everything reported using bugzilla a bug is incorrect and inappropriate. In this case, we have a broad range of issues: * does it let the reader know they can help improve the page or upload another photo The Commons/File pages don't do that, why would you expect this software to do it? * does it reflect copyright holders' licenses accurately and effectively Agree this is important. Do you have any evidence that it is any less accurate than the Commons/File pages? * does it adequately respect the privacy of the subjects of photos The mere fact of the image being used on an article anywhere on a Wikimedia project suggests that this problem is in the actual usage, not in the software being used to display more information and detail in the image. If you believe that this is a serious issue, then it should be addressed where 100% of readers can see it, not in a subpage viewed only by the limited number of readers who click on the image. It's not a Media Viewer problem, it's an image usage problem. * does it reflect a look and feel that we feel OK about and is consistent with the rest of the software etc. etc. What problems are you seeing here? Spell it out, rather than making vague suggestions that there is an issue. Fixing one bug may well lead to other bugs, or negatively impact those already reported. What is needed, I believe, is a well-facilitated process to identify the problems and the best solutions. This is not easy to do and takes time. But I think the WMF has (not for lack of trying) managed to do a very bad job of that with this software product, and with many software products in the last few years. That does not mean it is impossible to do it that way, only that those specific efforts were insufficient. Why is this a Media Viewer issue? This is a problem for all types of software on all types of platforms, and is a challenge even for IT departments hundreds of times the size of the WMF. I cannot think of any software I have used in the last 20 years that has not had bugs or unsatisfactory UI elements or seems to miss a functionality I'd like to have. It is unreasonable to hold a comparatively very small organization to a standard that can't even be met by IT giants. Risker/Anne ___ 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
Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you
On Sun, Aug 17, 2014 at 5:12 PM, Risker risker...@gmail.com wrote:
Well, hold on here.
On 17 August 2014 19:55, Pete Forsyth petefors...@gmail.com wrote:
I think it is also a problem to look at this in terms of bugs. I don't
think you can retrofit good design into something that has a variety of
substantial problems, by merely squashing bugs. You might say that is
the
wiki way, but it is widely known that some tasks are better suited than
others to ad hoc collaborative processes.
Given the current use of bugzilla, which doesn't limit itself to bugs but
also feature requests and enhancements over the base functionality, calling
everything reported using bugzilla a bug is incorrect and inappropriate.
While this is true, I have yet to see bugzilla used as a platform for a
design process for Media Viewer, and I don't think I would recommend it.
It's *possible* to use it as a platform for more than mere bugs, and it has
been done before; but I don't think tha'ts what's going on here, or should
go on here.
In this case, we have a broad range of issues:
* does it let the reader know they can help improve the page or upload
another photo
The Commons/File pages don't do that, why would you expect this software to
do it?
The Commons/File page DOES do that, to the extent that readers have some
familiarity with MediaWiki software and how to find the Edit button. You
may not believe that is significant, but I encounter people on an almost
daily basis who are mystified by Wikipedia, but at least have a basic
understanding what the edit button does, or could allow them to do. It
may not be all readers or even a majority, but it is my very strong belief
-- rooted, perhaps not in rigorous scientific analysis, but in my very
active engagement with non-Wikipedias since 2006 -- that it's the pool of
people who tend to replenish our declining editor pool. A great many of the
100+ students who signed up for the 4 rounds of my online course on editing
Wikipedia, for instance, had accounts that were several years old, but only
had a dozen or so edits.
* does it reflect copyright holders' licenses accurately and effectively
Agree this is important. Do you have any evidence that it is any less
accurate than the Commons/File pages?
That evidence is all over the various RFCs and wiki pages related to this,
and also in Bugzilla I believe, I'll leave it to you to track it down.
* does it adequately respect the privacy of the subjects of photos
The mere fact of the image being used on an article anywhere on a Wikimedia
project suggests that this problem is in the actual usage, not in the
software being used to display more information and detail in the image.
If you believe that this is a serious issue, then it should be addressed
where 100% of readers can see it, not in a subpage viewed only by the
limited number of readers who click on the image. It's not a Media Viewer
problem, it's an image usage problem.
This point has a lot of nuance in it, and I'm happy to discuss it, but not
here and now. If you want to dig into it, I suggest this as a venue:
https://commons.wikimedia.org/wiki/Template_talk:Consent -- if you leave a
note there, please {{ping|Peteforsyth}} so I can find it.
* does it reflect a look and feel that we feel OK about and is
consistent
with the rest of the software
etc. etc.
What problems are you seeing here? Spell it out, rather than making vague
suggestions that there is an issue.
I don't personally have a big issue with this one; but it's something
others have brought up. I'm trying to capture the breadth of concerns about
the software here, rather than (as WMF staff keep inaccurately accusing me
and many of my colleagues of doing) saying merely I DON'T LIKE IT.
Fixing one bug may well lead to other bugs, or negatively impact those
already reported. What is needed, I believe, is a well-facilitated
process
to identify the problems and the best solutions. This is not easy to do
and
takes time. But I think the WMF has (not for lack of trying) managed to
do
a very bad job of that with this software product, and with many software
products in the last few years. That does not mean it is impossible to do
it that way, only that those specific efforts were insufficient.
Why is this a Media Viewer issue? This is a problem for all types of
software on all types of platforms, and is a challenge even for IT
departments hundreds of times the size of the WMF. I cannot think of any
software I have used in the last 20 years that has not had bugs or
unsatisfactory UI elements or seems to miss a functionality I'd like to
have. It is unreasonable to hold a comparatively very small organization
to a standard that can't even be met by IT giants.
It is absolutely a problem for all types of software on all types of
platforms. It is a Media Viewer issue because the design and deployment was
executed so badly that it
Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you
On 17 August 2014 20:25, Pete Forsyth petefors...@gmail.com wrote:
On Sun, Aug 17, 2014 at 5:12 PM, Risker risker...@gmail.com wrote:
Well, hold on here.
On 17 August 2014 19:55, Pete Forsyth petefors...@gmail.com wrote:
I think it is also a problem to look at this in terms of bugs. I
don't
think you can retrofit good design into something that has a variety of
substantial problems, by merely squashing bugs. You might say that is
the
wiki way, but it is widely known that some tasks are better suited than
others to ad hoc collaborative processes.
Given the current use of bugzilla, which doesn't limit itself to bugs but
also feature requests and enhancements over the base functionality,
calling
everything reported using bugzilla a bug is incorrect and
inappropriate.
While this is true, I have yet to see bugzilla used as a platform for a
design process for Media Viewer, and I don't think I would recommend it.
It's *possible* to use it as a platform for more than mere bugs, and it has
been done before; but I don't think tha'ts what's going on here, or should
go on here.
Perhaps you should get to know a bit more about bugzilla and its current
usage; of the 104 current reports on Multimedia Viewer, 16 are enhancements
and several others that are currently listed as bugs of varying
importance/urgency are features that don't appear to exist in the
standard format for viewing images or are so badly designed in the File
pages that they're almost impossible to call acceptable in that format,
either.
Someone who is better able to describe the developer functions could better
describe the planned changes from the use of Bugzilla to Phabricator, which
is a more flexible platform that (I understand) is intended to consolidate
several different design/development/improvement/bug reporting platforms
currently in use. But right now, bugzilla is at least in some cases used
as a platform for the design process of just about everything to do with
MediaWiki, its extensions, and all the other platforms that are in
use/developed by WMF.
Every single type of software used on Wikimedia project sites, as well as
software for other features provided by the WMF, has bugzilla reports.
There are thousands for MediaWiki, the core software of the project. We
haven't thrown in the towel on it just because it's got lots of bugzilla
reports.
In this case, we have a broad range of issues:
* does it let the reader know they can help improve the page or upload
another photo
The Commons/File pages don't do that, why would you expect this software
to
do it?
The Commons/File page DOES do that, to the extent that readers have some
familiarity with MediaWiki software and how to find the Edit button. You
may not believe that is significant, but I encounter people on an almost
daily basis who are mystified by Wikipedia, but at least have a basic
understanding what the edit button does, or could allow them to do. It
may not be all readers or even a majority, but it is my very strong belief
-- rooted, perhaps not in rigorous scientific analysis, but in my very
active engagement with non-Wikipedias since 2006 -- that it's the pool of
people who tend to replenish our declining editor pool. A great many of the
100+ students who signed up for the 4 rounds of my online course on editing
Wikipedia, for instance, had accounts that were several years old, but only
had a dozen or so edits.
I'm sorry. How, exactly, do you envision a new editor or reader improving
file pages? There's not very much that can be edited there that isn't going
to cause more problems than it solves. Should they modify the author?
Change the license? Add (potentially non-existent) categories? When the
chances of reversion are nearly 100%, it's not necessarily a net positive
to make a big deal about the existence of an edit button. Media pages
are not really comparable to (written) content pages. I'd rank file pages
as possibly the worst place to suggest that new editors just jump in, with
the possible exception of templates.
snip
* does it adequately respect the privacy of the subjects of photos
The mere fact of the image being used on an article anywhere on a
Wikimedia
project suggests that this problem is in the actual usage, not in the
software being used to display more information and detail in the image.
If you believe that this is a serious issue, then it should be addressed
where 100% of readers can see it, not in a subpage viewed only by the
limited number of readers who click on the image. It's not a Media Viewer
problem, it's an image usage problem.
This point has a lot of nuance in it, and I'm happy to discuss it, but not
here and now. If you want to dig into it, I suggest this as a venue:
https://commons.wikimedia.org/wiki/Template_talk:Consent -- if you leave a
note there, please {{ping|Peteforsyth}} so I can find it.
I am at a loss as to why a
[Wikimedia-l] [Wikimedia Announcements] The Signpost -- Volume 10, Issue 31 -- 13 August 2014
Wikimania: Promised the moon, settled for the stars http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-13/Wikimania Op-ed: Red links, blue links, and erythrophobia http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-13/Op-ed Special report: Twitter bots catalogue government edits to Wikipedia http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-13/Special_report News and notes: Media Viewer controversy spreads to German Wikipedia http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-13/News_and_notes Wikimedia in education: Wikimedia ''Global'' Education: WMF's Perspective http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-13/Wikimedia_in_education In the media: Monkey selfie, net neutrality, and hoaxes http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-13/In_the_media Featured content: Cambridge got a lot of attention this week http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-13/Featured_content Traffic report: Disease, decimation and distraction http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-08-13/Traffic_report Single page view http://en.wikipedia.org/wiki/Wikipedia:Signpost/Single PDF version http://en.wikipedia.org/wiki/Book:Wikipedia_Signpost/2014-08-13 https://www.facebook.com/wikisignpost / https://twitter.com/wikisignpost -- Wikipedia Signpost Staff http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost ___ Please note: all replies sent to this mailing list will be immediately directed to Wikimedia-l, the public mailing list of the Wikimedia community. For more information about Wikimedia-l: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l ___ WikimediaAnnounce-l mailing list wikimediaannounc...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l ___ 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] Flogging dead horses (was Re: Superprotect user right, Coming to a wiki near you)
Are we there yet? This subject has been so done to death, that the corpse of the dead horse that has been flogged is going to rise as a zombie and eat out your brains. There is next to no original thought coming through just verbiage, and it is time that people subjecting the whole list to the continued indigence. There is an RFC, there is a process being followed, I invite those who wish to now comment to use those vehicles and be considerate to those who have had enough of the subject matter. ___ 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
Re: [Wikimedia-l] Flogging dead horses (was Re: Superprotect user right, Coming to a wiki near you)
On 18 August 2014 04:13, Wiki Billinghurst billinghurstw...@gmail.com wrote: Are we there yet? This subject has been so done to death, that the corpse of the dead horse that has been flogged is going to rise as a zombie and eat out your brains. There is next to no original thought coming through just verbiage, and it is time that people subjecting the whole list to the continued indigence. There is an RFC, there is a process being followed, Not really. We left process ago some time ago. For obvious reasons there isn't a process for a clash between the people with root access and 500+ German wikipedians: https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Superschutz -- geni ___ 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
Re: [Wikimedia-l] Flogging dead horses (was Re: Superprotect user right, Coming to a wiki near you)
What is the benefit of creating yet another thread on this? Fae On 18 August 2014 04:13, Wiki Billinghurst billinghurstw...@gmail.com wrote: Are we there yet? This subject has been so done to death, that the corpse of the dead horse that has been flogged is going to rise as a zombie and eat out your brains. There is next to no original thought coming through just verbiage, and it is time that people subjecting the whole list to the continued indigence. There is an RFC, there is a process being followed, I invite those who wish to now comment to use those vehicles and be considerate to those who have had enough of the subject matter. ___ 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
