Re: [Wikimedia-l] The reader, who doesn't exist
MZMcBride, 24/08/2014 23:57: Federico Leva (Nemo) wrote: First, let's make one thing clear: the reader doesn't exist; it's just a rhetorical trick, and a very dangerous one. For more: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader This essay looks fascinating. I hope to read it soon. Heh. Why does it matter how popular we are? Does it affect donation rates? Does it affect editorship rates? I'm not sure how much of this we know. I think evidence points to an important role that (desktop) visits trends had in the editing activity trends. There are some research papers proving this locally, which I still have to reference in the page above; but I agree we need much more research to understand this globally. It's increasingly clear that much of the rest of the Internet _is_ different: it doesn't require much thought of participants, it's user-focused, and it's built on the idea of selling (to) people. This difference in how we want to treat users, as collaborators and colleagues, rather than as clients or customers, will permeate the site design and user experience and that's okay. This is closer to the point I was trying to make. The internet is different, the environment is not favourable and is probably getting worse (pageview trends may be the tip of the iceberg: a useful warning). No matter how well we try and how many good things get done which were worth doing, it's entirely possible for some things bigger than us (like worldwide shifts in consumer electronics and telecommunication) to undefeatably beat us and make the Wikimedia projects fail (e.g. 27 or 28 in http://meatballwiki.org/wiki/WikiLifeCycle ). Sure, that would not be the end of the story, because we try to get something done which will be relevant for centuries to come. But denial doesn't help anything. If the number of pageviews suddenly drops, for whatever reason, what happens next? The most likely worst case scenario seems to be a reduction in annual donations, which results in a smaller staff size (sometimes referred to as trimming the fat or optimizing). There's a lot of talk lately about the imperiled future, but we could end up with a smaller, more decentralized Wikimedia Foundation staff in what some would consider one of the least desirable outcomes. Eh. The number of WMF staff has had practically zero consequences on the success of Wikimedia projects, so I don't consider it a particularly interesting topic for this decade. I'm more interested in discussing the stuff you can't easily read on a balance sheet. Nemo ___ 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] The reader, who doesn't exist
Federico Leva (Nemo) wrote: First, let's make one thing clear: the reader doesn't exist; it's just a rhetorical trick, and a very dangerous one. For more: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader = While I think we may have broadly similar views of the WikiWorld, I sharply disagree with Mr. Leva's analysis of various Wikipedia participant categories. The notion that today's Wikipedia writing process in any way resembles the idealized massively expanding 2 sentence [[Alan Alda]] article cited by the late Aaron Swartz in his 2006 essay Who Writes Wikipedia has very little to do with reality. Articles today do NOT start with two unsourced lines before being crowdsourced into finished pieces by a cast of hundreds. Instead, Wikipedia articles today start the same way that the Stupidity of the Reader essay itself started: through the mass contribution of a single person (Federico Leva), tweaked and polished by several others leads to the dangerous idea that everyone who touches Wikipedia in any capacity is an equal User, with those participating frequently a Power User. This is the conception of the paid bureaucracy, who would like nothing better than to declare the universal set to be hundreds of millions of equal Users who can thus be deferred as a silent majority. In this way any and all decisions made by the 10,000 or so person volunteer community can be cast aside as statistically insignificant — thereby assuring that what the 200-or-so person professional bureaucracy says, goes. In reality there are various levels of contributors, ranging from the IP who casually corrects one random spelling error, to the dedicated and devoted people who guard the gates at Recent Changes or who systemically put the work of others to style or who write new esoteric content. Certainly, turning casual contributors of a short article about something local or personal to them into regular contributors of editing work of various kinds is vitally important. Mr. Leva's argument that The user can (and should) turn from a reader to an editor, and vice versa, at any time. might sound good on paper, put it is actually provides the ideological basis for unfettered site rule by a professional caste. We are not power users. We are the volunteer community. Tim Davenport Carrite on En-WP /// Randy from Boise at WPO Corvallis, OR (USA) See: Aaron Swartz article: http://www.aaronsw.com/weblog/whowriteswikipedia Frederico Leva essay: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader - A Dissident View of Crowdsourcing It must be said that Wikipedia does not make it easy to play nicely. Its basic set-up is a bit like having people try to draw a copy of the Mona Lisa in the sand, while herds of children and strangers walk through the emerging picture, leave their footprints, or try to blank or improve bits. And you're required to assume they are all doing so in good faith. It would drive anyone mad. Received wisdom is, too many cooks spoil the broth. Crowdsourcing wisdom is, the more cooks, the better. But in practice, every featured article in Wikipedia is the work of one writer...or a small team. Crowdsourcing does not result in excellent articles. —JN466, on Wikipediocracy, July 2012. ___ 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] The reader, who doesn't exist
On 8/25/14, 3:06 AM, MZMcBride wrote: As a metric, pageviews are probably not very meaningful. One way we can observe whether we're fulfilling our mission is to see how ubiquitous our content has become. An even better metric might be the quality of the articles we have. Anecdotal evidence suggests that higher article quality is not really tied to the readership rate, though perhaps article size is. Yes, I'd ideally like some better measure of how much people get out of articles. Some types of analytics do track page view duration, although that can be considered intrusive. I've done a little spot-checking within specific areas (e.g. archaeological sites) of our view counts, and they are largely dominated by spikes around transient news events: something is in the news and 5,000 or 50,000 people load an article that normally gets 50 or 100 hits a day. Providing that kind of quick background knowledge to people googling for an item they saw on the news is a valuable service, to be sure. But I'm not sure it's *as* big a proportion of the value Wikipedia provides as the raw pageload numbers would say. -Mark ___ 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] The reader, who doesn't exist
Federico Leva (Nemo) wrote: First, let's make one thing clear: the reader doesn't exist; it's just a rhetorical trick, and a very dangerous one. For more: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader This essay looks fascinating. I hope to read it soon. Page views, however brute a concept, exist; and I think they're telling us we do have a readership problem. For it.wiki, in the last year I see a suspiciously similar decrease in desktop pageviews and editing activity (possibly around –20 %). It would *seem* that every user converted to the mobile site is a step towards extinction of the wiki. Long story: https://meta.wikimedia.org/wiki/Special:Permalink/9380388 The page above is just a collection of pointers that I probably won't be able to pursue in the coming months, to study an unprecedented collapse of editing activity and active editors on it.wiki. However, there /are/ several things worth looking into and we do have a huge problem (or several). I don't know enough about the Italian Wikipedia to comment on it specifically. But generally I think it's important to re-emphasize that correlation and causation are distinct, as are readership and editorship rates. The two items of each set can be interrelated or connected sometimes, of course, but we need to make sure we're drawing accurate and appropriate conclusions. At https://bugzilla.wikimedia.org/show_bug.cgi?id=62811#c10 Jared Zimmerman writes, We have a reader decline, its backed by hard numbers, any creative solution for bringing more readers and contributors into the project should be seriously discussed without being dismissed out of hand. There's substantial discussion in the subsequent comments. Let's temporarily accept the premise that pageviews suddenly drop from 20 billion per month to 1 billion per month. The easy argument is that we'd save a lot of money on hosting. But unlike most of the Internet, Wikipedia doesn't rely on advertising. Why does it matter how popular we are? Does it affect donation rates? Does it affect editorship rates? I'm not sure how much of this we know. It's increasingly clear that much of the rest of the Internet _is_ different: it doesn't require much thought of participants, it's user-focused, and it's built on the idea of selling (to) people. This difference in how we want to treat users, as collaborators and colleagues, rather than as clients or customers, will permeate the site design and user experience and that's okay. If the number of pageviews suddenly drops, for whatever reason, what happens next? The most likely worst case scenario seems to be a reduction in annual donations, which results in a smaller staff size (sometimes referred to as trimming the fat or optimizing). There's a lot of talk lately about the imperiled future, but we could end up with a smaller, more decentralized Wikimedia Foundation staff in what some would consider one of the least desirable outcomes. Eh. MZMcBride ___ 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] The reader, who doesn't exist
Given the mission is sharing information, I'd suggest that if we have a 95% drop in readership, we're failing the mission. Donations are only a means to an end. Risker/Anne On 24 August 2014 22:57, MZMcBride z...@mzmcbride.com wrote: Federico Leva (Nemo) wrote: First, let's make one thing clear: the reader doesn't exist; it's just a rhetorical trick, and a very dangerous one. For more: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader This essay looks fascinating. I hope to read it soon. Page views, however brute a concept, exist; and I think they're telling us we do have a readership problem. For it.wiki, in the last year I see a suspiciously similar decrease in desktop pageviews and editing activity (possibly around –20 %). It would *seem* that every user converted to the mobile site is a step towards extinction of the wiki. Long story: https://meta.wikimedia.org/wiki/Special:Permalink/9380388 The page above is just a collection of pointers that I probably won't be able to pursue in the coming months, to study an unprecedented collapse of editing activity and active editors on it.wiki. However, there /are/ several things worth looking into and we do have a huge problem (or several). I don't know enough about the Italian Wikipedia to comment on it specifically. But generally I think it's important to re-emphasize that correlation and causation are distinct, as are readership and editorship rates. The two items of each set can be interrelated or connected sometimes, of course, but we need to make sure we're drawing accurate and appropriate conclusions. At https://bugzilla.wikimedia.org/show_bug.cgi?id=62811#c10 Jared Zimmerman writes, We have a reader decline, its backed by hard numbers, any creative solution for bringing more readers and contributors into the project should be seriously discussed without being dismissed out of hand. There's substantial discussion in the subsequent comments. Let's temporarily accept the premise that pageviews suddenly drop from 20 billion per month to 1 billion per month. The easy argument is that we'd save a lot of money on hosting. But unlike most of the Internet, Wikipedia doesn't rely on advertising. Why does it matter how popular we are? Does it affect donation rates? Does it affect editorship rates? I'm not sure how much of this we know. It's increasingly clear that much of the rest of the Internet _is_ different: it doesn't require much thought of participants, it's user-focused, and it's built on the idea of selling (to) people. This difference in how we want to treat users, as collaborators and colleagues, rather than as clients or customers, will permeate the site design and user experience and that's okay. If the number of pageviews suddenly drops, for whatever reason, what happens next? The most likely worst case scenario seems to be a reduction in annual donations, which results in a smaller staff size (sometimes referred to as trimming the fat or optimizing). There's a lot of talk lately about the imperiled future, but we could end up with a smaller, more decentralized Wikimedia Foundation staff in what some would consider one of the least desirable outcomes. Eh. MZMcBride ___ 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] The reader, who doesn't exist
Risker wrote: Given the mission is sharing information, I'd suggest that if we have a 95% drop in readership, we're failing the mission. Donations are only a means to an end. I think this assumes a direct correlation between pageviews and sharing information and I'm not sure such a direct correlation exists. When you do a Google search for abraham lincoln, there's now an infobox on the search results page with content from Wikipedia. This could easily result in a drop in the number of Wikipedia pageviews, but does that mean that Wikipedia is failing its mission? The goal is a world in which we freely share in the sum of all human knowledge. If third parties are picking up and re-using our free content (and they are), I think we're certainly not losing. We may even be winning(!). We offer bulk-download options for our content, as well as the ability to directly query for article content on-demand via the MediaWIki API. Both of these access methods very likely result in 0 pageviews being registered (XML dump downloads and api.php hits aren't considered pageviews, as far as I'm aware), but we're directly sharing content. As a metric, pageviews are probably not very meaningful. One way we can observe whether we're fulfilling our mission is to see how ubiquitous our content has become. An even better metric might be the quality of the articles we have. Anecdotal evidence suggests that higher article quality is not really tied to the readership rate, though perhaps article size is. MZMcBride ___ 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] The reader, who doesn't exist
Yes, we could look at Google's infoboxes as doing us a favor because they decrease the load on our servers. We would need to account for those views in some way if we are interested in quantifying success in the sense of total views of our content regardless of where it is reproduced. However, I think Analytics said in a WMF Metrics Meeting presentation that the number of Google search referrals was not going down enough to explain the drop in pageviews. I'm copying this email to Analytics in the hope that they'll comment about the probable causes of the pageview decreases. Pine On Sun, Aug 24, 2014 at 6:06 PM, MZMcBride z...@mzmcbride.com wrote: Risker wrote: Given the mission is sharing information, I'd suggest that if we have a 95% drop in readership, we're failing the mission. Donations are only a means to an end. I think this assumes a direct correlation between pageviews and sharing information and I'm not sure such a direct correlation exists. When you do a Google search for abraham lincoln, there's now an infobox on the search results page with content from Wikipedia. This could easily result in a drop in the number of Wikipedia pageviews, but does that mean that Wikipedia is failing its mission? The goal is a world in which we freely share in the sum of all human knowledge. If third parties are picking up and re-using our free content (and they are), I think we're certainly not losing. We may even be winning(!). We offer bulk-download options for our content, as well as the ability to directly query for article content on-demand via the MediaWIki API. Both of these access methods very likely result in 0 pageviews being registered (XML dump downloads and api.php hits aren't considered pageviews, as far as I'm aware), but we're directly sharing content. As a metric, pageviews are probably not very meaningful. One way we can observe whether we're fulfilling our mission is to see how ubiquitous our content has become. An even better metric might be the quality of the articles we have. Anecdotal evidence suggests that higher article quality is not really tied to the readership rate, though perhaps article size is. MZMcBride ___ 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
[Wikimedia-l] The reader, who doesn't exist
MZMcBride, I agree with you, but let me split out one thing: On 20 August 2014 04:09, MZMcBride wrote: the one complaint I _never_ hear is that Wikipedia has a readership problem. Then you'll hear it from me. First, let's make one thing clear: the reader doesn't exist; it's just a rhetorical trick, and a very dangerous one. For more: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader Page views, however brute a concept, exist; and I think they're telling us we do have a readership problem. For it.wiki, in the last year I see a suspiciously similar decrease in desktop pageviews and editing activity (possibly around –20 %). It would *seem* that every user converted to the mobile site is a step towards extinction of the wiki. Long story: https://meta.wikimedia.org/wiki/Research:The_sudden_decline_of_Italian_Wikipedia The page above is just a collection of pointers that I probably won't be able to pursue in the coming months, to study an unprecedented collapse of editing activity and active editors on it.wiki. However, there /are/ several things worth looking into and we do have a huge problem (or several). Can anything be done about it? I don't know. In its brief history, WMF software development has always been irrelevant for the increase of editing activity and reach. Let's hope for a counterexample. Nemo P.s.: Yes, this message is focused on one small thing only. That's just about what we are/were already doing, while most opportunities lie in what we're not doing, see the sister projects and [[strategy:List of things that need to be free]]; we like to think otherwise, but our free culture projects are still very marginal. ___ 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] The reader, who doesn't exist
2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemow...@gmail.com: It would *seem* that every user converted to the mobile site is a step towards extinction of the wiki. That is an excellent point Frederico. In addition to the inherent difficulties of editing on small screen, especially large articles and the we know better approach discussed in detail in the last weeks, there is also the problem of navigating between articles - the mobile website arbitrarily skips some elements visible on desktop, such as navboxes and significantly alter some infoboxes because it doesn't look good. This makes it difficult to just browse the Wikipedia (thus finding mistakes that you might want to correct) and encourages searching for the information, which means going right on target Hopefully the future announced at Wikimania, no more mobile team, but mobile in every team will solve some of these problems. It's just a matter of when will this future be. Strainu ___ 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] The reader, who doesn't exist
On 21 August 2014 10:31, Strainu strain...@gmail.com wrote: the mobile website arbitrarily skips some elements visible on desktop, such as navboxes I've noticed this; and other deficiencies (such as no did you know on main page, not even as a link to a subpage). and significantly alter some infoboxes because it doesn't look good. I'd not noticed this; can you give examples, please? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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] The reader, who doesn't exist
On 21 August 2014 05:31, Strainu strain...@gmail.com wrote: 2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemow...@gmail.com: It would *seem* that every user converted to the mobile site is a step towards extinction of the wiki. That is an excellent point Frederico. In addition to the inherent difficulties of editing on small screen, especially large articles and the we know better approach discussed in detail in the last weeks, there is also the problem of navigating between articles - the mobile website arbitrarily skips some elements visible on desktop, such as navboxes and significantly alter some infoboxes because it doesn't look good. This makes it difficult to just browse the Wikipedia (thus finding mistakes that you might want to correct) and encourages searching for the information, which means going right on target Hopefully the future announced at Wikimania, no more mobile team, but mobile in every team will solve some of these problems. It's just a matter of when will this future be. Well, now. Here's a classic example of what is sometimes called a first world problem. I know that, even on desktops, the more infoboxes and navboxes and succession boxes on an article (regardless of article length), the longer it takes to load. On a slower desktop collection, some really large, complex articles sometimes time out. I went to look at some of those same articles using my smartphone with the desktop option turned on. Many of them timed out without fully loading; others took several minutes. There was a very, very noticeable difference in load time between the mobile view and the desktop view. And that was in North America with fast, very good connection on an up-to-date phone. Many of our editors and readers don't have this kind of infrastructure available to them. So - we know there is a definite cost to having all these navigation aids in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need to find ways to make them more efficient so that they're suitable for mobile devices. If they're hardly ever being used, we need to reconsider their existence. Perhaps this becomes some sort of meta data tab from articles. The current format isn't sustainable, though. 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] The reader, who doesn't exist
Editing via the mobile view is made more painful by the use of navboxes, tables
and complex templates of any kind. Even the {{cite}} template can occupy
several lines of the display on a mobile device making it hard to discern the
text. Maybe Wikidata will solve some of this by shifting the creation of
navigation links (for example) out of article editing and into metadata
maintenance. I've not tried working on Wikidata via a mobile device so can't
comment on its accessibility
Neil
Risker wrote
On 21 August 2014 05:31, Strainu strain...@gmail.com wrote:
2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemow...@gmail.com:
It would *seem* that every user
converted to the mobile site is a step towards extinction of the wiki.
That is an excellent point Frederico. In addition to the inherent
difficulties of editing on small screen, especially large articles and
the we know better approach discussed in detail in the last weeks,
there is also the problem of navigating between articles - the mobile
website arbitrarily skips some elements visible on desktop, such as
navboxes and significantly alter some infoboxes because it doesn't
look good. This makes it difficult to just browse the Wikipedia (thus
finding mistakes that you might want to correct) and encourages
searching for the information, which means going right on target
Hopefully the future announced at Wikimania, no more mobile team, but
mobile in every team will solve some of these problems. It's just a
matter of when will this future be.
Well, now. Here's a classic example of what is sometimes called a first
world problem. I know that, even on desktops, the more infoboxes and
navboxes and succession boxes on an article (regardless of article length),
the longer it takes to load. On a slower desktop collection, some really
large, complex articles sometimes time out.
I went to look at some of those same articles using my smartphone with the
desktop option turned on. Many of them timed out without fully loading;
others took several minutes. There was a very, very noticeable difference
in load time between the mobile view and the desktop view. And that was in
North America with fast, very good connection on an up-to-date phone. Many
of our editors and readers don't have this kind of infrastructure available
to them.
So - we know there is a definite cost to having all these navigation aids
in articles. We need to justify their use, instead of simply adding them
by reflex. So here is where analytics teams can really be useful: tell us
whether or not these navboxes are actually being used to go to other
articles. If they're widely used to leap to the next article, then we need
to find ways to make them more efficient so that they're suitable for
mobile devices. If they're hardly ever being used, we need to reconsider
their existence. Perhaps this becomes some sort of meta data tab from
articles. The current format isn't sustainable, though.
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
___
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] The reader, who doesn't exist
On 21.08.2014 14:26, Risker wrote: On 21 August 2014 05:31, Strainu strain...@gmail.com wrote: ... I went to look at some of those same articles using my smartphone with the desktop option turned on. Many of them timed out without fully loading; others took several minutes. There was a very, very noticeable difference in load time between the mobile view and the desktop view. And that was in North America with fast, very good connection on an up-to-date phone. Many of our editors and readers don't have this kind of infrastructure available to them. So - we know there is a definite cost to having all these navigation aids in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need to find ways to make them more efficient so that they're suitable for mobile devices. If they're hardly ever being used, we need to reconsider their existence. Perhaps this becomes some sort of meta data tab from articles. The current format isn't sustainable, though. Risker/Anne ___ For me the conclusion would be not that we should drop them altogether in the mobile version (most of them are useful navigation means after all) but that the mobile version should be improved to parse them and to present them as a piece of plain text, not as a template. Cheers Yaroslav ___ 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] The reader, who doesn't exist
On 21 August 2014 09:18, Yaroslav M. Blanter pute...@mccme.ru wrote: On 21.08.2014 14:26, Risker wrote: On 21 August 2014 05:31, Strainu strain...@gmail.com wrote: ... I went to look at some of those same articles using my smartphone with the desktop option turned on. Many of them timed out without fully loading; others took several minutes. There was a very, very noticeable difference in load time between the mobile view and the desktop view. And that was in North America with fast, very good connection on an up-to-date phone. Many of our editors and readers don't have this kind of infrastructure available to them. So - we know there is a definite cost to having all these navigation aids in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need to find ways to make them more efficient so that they're suitable for mobile devices. If they're hardly ever being used, we need to reconsider their existence. Perhaps this becomes some sort of meta data tab from articles. The current format isn't sustainable, though. Risker/Anne ___ For me the conclusion would be not that we should drop them altogether in the mobile version (most of them are useful navigation means after all) but that the mobile version should be improved to parse them and to present them as a piece of plain text, not as a template. Many of these templates have over 100 links in them; a surprisingly large number have subtemplates built into them. I'm having a hard time seeing how adding all those links at the bottom of an article is actually going to help that much. Unless we have some evidence to confirm this information is actually useful to readers -seriously, this is a community-designed feature targeted at readers as opposed to editors - it's probably time to rethink what indirectly related information on our article pages is made routinely available. We want people to use our information, not give up because it takes too long to load. 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] The reader, who doesn't exist
On Thu, Aug 21, 2014 at 7:26 PM, Risker risker...@gmail.com wrote: On 21 August 2014 05:31, Strainu strain...@gmail.com wrote: 2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemow...@gmail.com: It would *seem* that every user converted to the mobile site is a step towards extinction of the wiki. That is an excellent point Frederico. In addition to the inherent difficulties of editing on small screen, especially large articles and the we know better approach discussed in detail in the last weeks, there is also the problem of navigating between articles - the mobile website arbitrarily skips some elements visible on desktop, such as navboxes and significantly alter some infoboxes because it doesn't look good. This makes it difficult to just browse the Wikipedia (thus finding mistakes that you might want to correct) and encourages searching for the information, which means going right on target Hopefully the future announced at Wikimania, no more mobile team, but mobile in every team will solve some of these problems. It's just a matter of when will this future be. Well, now. Here's a classic example of what is sometimes called a first world problem. I know that, even on desktops, the more infoboxes and navboxes and succession boxes on an article (regardless of article length), the longer it takes to load. On a slower desktop collection, some really large, complex articles sometimes time out. I went to look at some of those same articles using my smartphone with the desktop option turned on. Many of them timed out without fully loading; others took several minutes. There was a very, very noticeable difference in load time between the mobile view and the desktop view. And that was in North America with fast, very good connection on an up-to-date phone. Many of our editors and readers don't have this kind of infrastructure available to them. So - we know there is a definite cost to having all these navigation aids in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need to find ways to make them more efficient so that they're suitable for mobile devices. If they're hardly ever being used, we need to reconsider their existence. Perhaps this becomes some sort of meta data tab from articles. The current format isn't sustainable, though. If we're talking about navboxes, they are navigational and I agree the software should replace them with something else, or drop them entirely, if it helps rendering performance or the UI design. I'd be interested to hear of examples of infoboxes that are being altered by the mobile view. I expect it being done for overly complex parts of some infoboxes. While we're talking about the first world problem, I have first hand experience that the MediaViewer is a backwards step for people on dialup (e.g. people in regional Australia who rarely get the telco promised maximum of 28.8kbit/s) or on crappy mobile connections (which is most of Indonesia, fwiw, where many people use a _desktop_ or old laptop connected to the internet via 3G modem or their mobile phone). Sure they can disable it with their preferences, but to get to that they need to download the MediaViewer software and *while* the image is downloading at a much higher res than it would have previously, figure out to scroll down, and press the 'Disable Media Viewer' link. *But*, that only works on the normal website. On the mobile website, I cant figure out how to disable the Media Viewer. To check I wasnt missing something, I asked someone at the Wikimedia Indonesia office (https://en.wikipedia.org/wiki/Special:CentralAuth/Beeyan) to try to disable it on his phone, and he couldnt work it out either. Go to: https://en.m.wikipedia.org/wiki/Horse_Protection_Act_of_1970 Scroll down to the Tennessee Walking Horse photo and click on it. As far as I can see it has downloaded the 200+KB photo, and I may either close the MediaViewer or go to the page on Commons. There are no other options. We can't figure out how to disable this. Even after logging in on the mobile site, there is no preference to disable it in the Settings. If you click the Details button to return to go to Commons, only a 70KB photo is shown, which is what used to occur. -- John Vandenberg ___ 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] The reader, who doesn't exist
On 21.08.2014 15:24, Risker wrote: On 21 August 2014 09:18, Yaroslav M. Blanter pute...@mccme.ru wrote: On 21.08.2014 14:26, Risker wrote: On 21 August 2014 05:31, Strainu strain...@gmail.com wrote: ... Many of these templates have over 100 links in them; a surprisingly large number have subtemplates built into them. I'm having a hard time seeing how adding all those links at the bottom of an article is actually going to help that much. Unless we have some evidence to confirm this information is actually useful to readers -seriously, this is a community-designed feature targeted at readers as opposed to editors - it's probably time to rethink what indirectly related information on our article pages is made routinely available. We want people to use our information, not give up because it takes too long to load. Risker/Anne Right, and if the feature is not useful for readers (and I do not see how it is useful for editors, except for making the pages looking nicer) it possibly should not be there at all. But I do not think that just ignoring it in the mobile version without any relation to the desktop version is a good direction to follow. Cheers Yaroslav ___ 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] The reader, who doesn't exist
I find navboxes useful as an editor, and frequently use them to keep track of the related articles I edit. I would prefer to keep the functionality, but would not have a problem with it being opt-in. Cheers, Peter -Original Message- From: wikimedia-l-boun...@lists.wikimedia.org [mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of Yaroslav M. Blanter Sent: 21 August 2014 03:29 PM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] The reader, who doesn't exist On 21.08.2014 15:24, Risker wrote: On 21 August 2014 09:18, Yaroslav M. Blanter pute...@mccme.ru wrote: On 21.08.2014 14:26, Risker wrote: On 21 August 2014 05:31, Strainu strain...@gmail.com wrote: ... Many of these templates have over 100 links in them; a surprisingly large number have subtemplates built into them. I'm having a hard time seeing how adding all those links at the bottom of an article is actually going to help that much. Unless we have some evidence to confirm this information is actually useful to readers -seriously, this is a community-designed feature targeted at readers as opposed to editors - it's probably time to rethink what indirectly related information on our article pages is made routinely available. We want people to use our information, not give up because it takes too long to load. Risker/Anne Right, and if the feature is not useful for readers (and I do not see how it is useful for editors, except for making the pages looking nicer) it possibly should not be there at all. But I do not think that just ignoring it in the mobile version without any relation to the desktop version is a good direction to follow. Cheers Yaroslav ___ 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4745 / Virus Database: 4007/8073 - Release Date: 08/21/14 ___ 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] The reader, who doesn't exist
On 21/08/14 13:24, Risker wrote: On 21 August 2014 09:18, Yaroslav M. Blanter pute...@mccme.ru wrote: For me the conclusion would be not that we should drop them altogether in the mobile version (most of them are useful navigation means after all) but that the mobile version should be improved to parse them and to present them as a piece of plain text, not as a template. Many of these templates have over 100 links in them; a surprisingly large number have subtemplates built into them. I'm having a hard time seeing how adding all those links at the bottom of an article is actually going to help that much. Unless we have some evidence to confirm this information is actually useful to readers -seriously, this is a community-designed feature targeted at readers as opposed to editors - it's probably time to rethink what indirectly related information on our article pages is made routinely available. We want people to use our information, not give up because it takes too long to load. Risker/Anne Man, I forgot how over the top some projects get with their navigation templates. But what Yaroslav said might actually provide a good guideline - if they CAN be reasonably simplified, then the templates themselves are probably reasonable. If not, they need to be fixed. Just hiding them isn't the solution - the templates themselves need to be made more realistic, because while they may be a bit overwhelming on the desktop (I mean, I looked at [[red]] and was overwhelmed by the bottom of the page), the issues they present on mobile devices should be a real incentive. But if you just hide them, that removes the incentive to fix them up. That doesn't make much sense to me. -I ___ 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] The reader, who doesn't exist
On 21 August 2014 17:08, Isarra Yos zhoris...@gmail.com wrote: Man, I forgot how over the top some projects get with their navigation templates. Perhaps the answer is to refactor them as separate pages to which mobile (and even desktop) pages can use a single link? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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] The reader, who doesn't exist
On Thu, Aug 21, 2014 at 11:04 AM, Magnus Manske magnusman...@googlemail.com
wrote:
Or, have them filled from Wikidata. Then, {{Infobox}} would be all the
wikitext you need. This could also help to abstract infoboxes to load a
placeholder/hint on mobile, then loading the box on request (click).
Well, one can dream...
This would be ideal I think, since it would allow for more responsive
styling without resorting to ugly hacks specific to infobox markup.
So far as I can tell though, there is one major blocker to this: edibility.
People need to be able to update the infobox data without leaving Wikipedia
and being sent to Yet Another Wiki. This is potentially doable in
VisualEditor I think, but is hard or maybe impossible to do with any
elegance in wikitext.
___
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] The reader, who doesn't exist
On 21.08.2014 21:17, Steven Walling wrote:
On Thu, Aug 21, 2014 at 11:04 AM, Magnus Manske
magnusman...@googlemail.com
wrote:
Or, have them filled from Wikidata. Then, {{Infobox}} would be all
the
wikitext you need. This could also help to abstract infoboxes to
load a
placeholder/hint on mobile, then loading the box on request (click).
Well, one can dream...
This would be ideal I think, since it would allow for more responsive
styling without resorting to ugly hacks specific to infobox markup.
So far as I can tell though, there is one major blocker to this:
edibility.
People need to be able to update the infobox data without leaving
Wikipedia
and being sent to Yet Another Wiki. This is potentially doable in
VisualEditor I think, but is hard or maybe impossible to do with any
elegance in wikitext.
___
Another problem, at least for the time being, is that connection to
Wikidata is still slow (I feel it even with very good Internet access),
and eventually will impede slow mobile connections. I hope this is
curable though.
Cheers
Yaroslav
___
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] The reader, who doesn't exist
On 21 Aug 2014, at 13:03, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 21 August 2014 10:31, Strainu strain...@gmail.com wrote: the mobile website arbitrarily skips some elements visible on desktop, such as navboxes I've noticed this; and other deficiencies (such as no did you know on main page, not even as a link to a subpage). I thought this was set in the source code for the main page, see: https://www.mediawiki.org/wiki/Extension:MobileFrontend#Configuring_the_main_page which would mean that this could easily be fixed if there was consensus. However, that documentation may be out of date, since I can't spot any mf- ID's in the enwp main page? Thanks, Mike ___ 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] The reader, who doesn't exist
I was talking about navboxes, not infoboxes.
On 21 August 2014 19:04, Magnus Manske magnusman...@googlemail.com wrote:
Or, have them filled from Wikidata. Then, {{Infobox}} would be all the
wikitext you need. This could also help to abstract infoboxes to load a
placeholder/hint on mobile, then loading the box on request (click).
Well, one can dream...
Magnus
On Thu, Aug 21, 2014 at 6:45 PM, Andy Mabbett a...@pigsonthewing.org.uk
wrote:
On 21 August 2014 17:08, Isarra Yos zhoris...@gmail.com wrote:
Man, I forgot how over the top some projects get
with their navigation templates.
Perhaps the answer is to refactor them as separate pages to which
mobile (and even desktop) pages can use a single link?
--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
___
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
--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
___
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] The reader, who doesn't exist
2014-08-21 15:03 GMT+03:00 Andy Mabbett a...@pigsonthewing.org.uk: On 21 August 2014 10:31, Strainu strain...@gmail.com wrote: and significantly alter some infoboxes because it doesn't look good. I'd not noticed this; can you give examples, please? It seems this is not the case at en.wp, but take a look at how infoboxes (and especially coordinates) are displayed at ro.wp and fr.wp for [[:ro:București]]/[[:fr:Bucarest]]. There might be some underlying HTML problem that causes the box to move left, but what's the deal with the decimal coordinates? I thought we were trying to save bandwitdh? 2014-08-21 22:56 GMT+03:00 Michael Peel em...@mikepeel.net: I thought this was set in the source code for the main page, see: https://www.mediawiki.org/wiki/Extension:MobileFrontend#Configuring_the_main_page which would mean that this could easily be fixed if there was consensus. However, that documentation may be out of date, since I can't spot any mf- ID's in the enwp main page? Last edit to the main page on the subject is 31 May 2013. I haven't tried, but I would guess it's out of date. 2014-08-21 16:24 GMT+03:00 Risker risker...@gmail.com: So - we know there is a definite cost to having all these navigation aids in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need You mean on the desktop? Risker, why not talk to Erik Zachte directly and see if he can do anything withing the privacy policy's boundaries? For me the conclusion would be not that we should drop them altogether in the mobile version (most of them are useful navigation means after all) but that the mobile version should be improved to parse them and to present them as a piece of plain text, not as a template. Many of these templates have over 100 links in them; a surprisingly large number have subtemplates built into them. You both have a point. I'm sure there are some ways that the HTML code can get semantic information in order to determine the main links from such a box and display them. I'm glad Frederico brought this up (even if it might not have been his original point, and I apologize for hijacking his thread). If people agree that the mobile version needs to be smarter in deciding what to parse from the page, we can log some enhancements and push on the wikitech list to have them at least considered, if not prioritized. Thanks, Strainu ___ 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] The reader, who doesn't exist
On Thu, Aug 21, 2014 at 6:29 AM, John Mark Vandenberg jay...@gmail.com wrote: *But*, that only works on the normal website. On the mobile website, I cant figure out how to disable the Media Viewer. To check I wasnt missing something, I asked someone at the Wikimedia Indonesia office (https://en.wikipedia.org/wiki/Special:CentralAuth/Beeyan) to try to disable it on his phone, and he couldnt work it out either. Go to: https://en.m.wikipedia.org/wiki/Horse_Protection_Act_of_1970 Scroll down to the Tennessee Walking Horse photo and click on it. As far as I can see it has downloaded the 200+KB photo, and I may either close the MediaViewer or go to the page on Commons. There are no other options. We can't figure out how to disable this. Even after logging in on the mobile site, there is no preference to disable it in the Settings. If you click the Details button to return to go to Commons, only a 70KB photo is shown, which is what used to occur. Hi all, A few points of clarification on MediaViewer and mobile. The Mobile Web team built a custom image-viewing experience for users accessing Wikimedia projects on phones and tablets; we're not actually using desktop MediaViewer. The mobile implementation loads a size of the image adapted for the viewport (which may be larger than the screen size due to retina support). It does not load the full-size image unless that image is very small. Users accessing the mobile site via Wikipedia Zero or from lower-end no-JS phones/browsers go straight to the file page. Performance and bandwidth are definitely things we think about a lot. The Zero team is currently experimenting with different thumbnail compression ratios for mobile users who access the site via Wikipedia Zero carriers, in order to keep bandwidth impact minimal. Based on the outcome, we're considering using extra compression in the mobile media viewing experience for all users, though we'll need to study the caching implications, because it could potentially make performance worse but bandwidth better. Making sure the default experience works well for both high-end and low-end device users is a much higher priority on mobile than creating layers of opt-in/out preferences, because people use mobile differently from laptops/computers and complex preference screens are difficult to navigate on a smaller device. We do already have a preference to turn images off entirely on the mobile site for users who want to save bandwidth; adding more granular options to this is not something we're considering at this time, though it's entirely possible that we may revisit this in the future. -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org ___ 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
