Re: [Wikimedia-l] Wikisource type of site for sheet music at kickstarter
On 23/06/17 12:48, Romaine Wiki wrote: > Hi all, > > I came across the following Kickstarter project about sheet music. The > project aims for making public domain sheet musuc available and keeping > them open. The project is a sort of Wikisource, but then for sheet music, > and I think as Wikimedia movement we should support this somehow. Seems like a duplicate of Mutopia, except funded via Kickstarter. You give them money on Kickstarter and they download the score from IMSLP and transcribe it for you. This doesn't appear to be a business model that would benefit from our help. -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: 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] Let's set up a Tor onion service for Wikipedia
On 19/06/17 16:20, Rogol Domedonfors wrote: > I quite agree that Phabricator is not suitable for these discussions. > Perhaps Tim would like to say where and how discussions between the > Community and Foundation staff about the need for, and desirability of, > projects like this should be held. After all, we all want projects to go > ahead on the basis of Community input, don't we? We've had community input in this thread, but I haven't actually seen any objection to this proposal raised that stands up to analysis. Maybe meta would provide a platform for more organised discussion. Almost everyone talked about abuse potential, ignoring the fact that we already allow editing via Tor. Nothing actually changes in terms of abuse potential. The same people can edit, they can just use a different URL. The only other argument I saw was that by doing this, we are supporting Tor, and Tor is evil. But the hidden service only handles traffic which is directed to the service. It does not support the network in general. Meanwhile, since 2014 we are operating a relay which routinely forwards traffic for script kiddies, terrorists and child pornographers, and nobody complains about that? I think we should shut down the relay, which in my opinion is not mission-aligned, and set up the hidden service, which clearly is mission-aligned. A hidden service provides a small security improvement compared to plain HTTPS, and is marginally more censorship-resistant than a VPN. Its privacy protection is not perfect, but it is probably better than any other existing solution (except of course [1] ;-). It is a small technical project, which provides a small benefit to security-conscious users. -- Tim Starling [1] <https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2016-04-01/Technology_report> ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: 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] Let's set up a Tor onion service for Wikipedia
On 13/06/17 20:28, Gergő Tisza wrote: > Now that we have ascertained (again) that wikimedia-l is a poor channel > for focused discussions about tech proposals, can we move this to > Phabricator? I filed https://phabricator.wikimedia.org/T168218 On 14/06/17 12:12, Risker wrote: > I see your point, Gergo, but in reality Phabricator is an even worse > channel to discuss projects that are, essentially, social issues. I'd rather you didn't discuss social issues on Phabricator. I filed the task for the technical part of the project. -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: 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 end
On 18/05/16 01:18, Richard Symonds wrote: > Hi all, > > I wonder if that's the time to end the thread now (which is on a very > public list) and let people reach out privately. Discussion of this sort of > topic, especially when a specific person is involved, is not ideal, and > could make things worse. Fair enough. But for the benefit of concerned readers, I think it's appropriate to relay the news from Facebook this morning (AEST) that Chris is OK, he is feeling better. Also, I've heard that the WMF response last night was appropriate and treated the matter with all due seriousness. -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] Account of the events leading to James Heilman's removal
On 05/05/16 11:10, Tim Starling wrote: > In fact, employees disagreed with Lila's decision to pursue large > restricted grants for a stupid pet project, in secret, supported by > almost nobody, without Board knowledge let alone approval. This has > nothing to do with education versus technology (if such a dichotomy > can even be said to exist). It's likely that at some point, someone said to Lila "I don't think building a new Internet search engine to take on Google is within our (educational) mission". Perhaps that's where her "strategic conflict" story came from. It's a good point, but it's certainly not the only problem with the proposal, and it wasn't the subject of the complaints made against her. The conflict between Lila and the rest of the staff was over process, not strategy. -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] Account of the events leading to James Heilman's removal
On 04/05/16 12:02, MZMcBride wrote: > https://wikimediafoundation.org/wiki/Whistleblower_policy > > You mention anonymous complaints and serious concerns, but the current > whistleblower policy seems to be pretty clear that it only applies to > laws, rules, and regulations. The text of the policy indicates, to me at > least, that even alleged violations of other Wikimedia Foundation policies > would not be covered by the whistleblower policy. Would you extend the > Wikimedia Foundation whistleblower policy to cover regular (i.e., > non-legal and non-regulatory) grievances? The third and fourth paragraphs are not so narrow, but otherwise, yes, I think it should be extended. > My understanding is that the Wikimedia Foundation Board of Trustees sought > out and then appointed a tech-minded chief executive, who came from a tech > organization, in order to "transform" the Wikimedia Foundation from an > educational non-profit to be more like a traditional tech company. Many > employees of the Wikimedia Foundation disagreed with this decision and the > chief executive made a series of poor hires who ran amok (looking at you, > Damon), but I don't think anything rose to the level of illegal behavior. You are just regurgitating Lila's email. No transformation was attempted or executed. The first time I heard about this supposed conflict over strategy was when Lila posted her claims about it to this list, shortly before her resignation. In fact, employees disagreed with Lila's decision to pursue large restricted grants for a stupid pet project, in secret, supported by almost nobody, without Board knowledge let alone approval. This has nothing to do with education versus technology (if such a dichotomy can even be said to exist). Damon merely suggested the project in question, he did not "run amok". -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] Account of the events leading to James Heilman's removal
On 03/05/16 08:27, James Heilman wrote: > As for my willingness to share all communications with the entire board, I > believe I managed to communicate all relevant details without violating the > explicit confidence requested of me by staff members. (Note that in later > conversations I was informed that it may not be legal for board members to > promise confidentiality to individual staff, as our ultimate duty is to the > WMF as a whole). Board members have a duty to act in the interests of the WMF as a whole, but it does not follow that denying anonymity to whistleblowers is in the best interests of the WMF. In fact, I think this Lila/KF/KE case demonstrates the opposite. I would encourage the Board to extend the current whistleblower policy to provide protection to employees making anonymous complaints via certain intermediaries (such as active Board members), rather than requiring complaints to be made directly to the Chair of the Board; and to specify that the forwarding of such anonymous reports by Board members to the Chair would be permissible. If we want to avoid a repeat of this affair, then employees should be encouraged to communicate serious concerns to the Board as early as possible. -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] Wikimedia Foundation executive transition update
On 11/03/16 13:55, Patricio Lorente wrote: > Hello all, > > I’m happy to announce that the Wikimedia Foundation leadership team has > proposed an interim Executive Director, and the Board has given our full > support. Starting on March 14th, current Chief Communications Officer > Katherine Maher (https://meta.wikimedia.org/wiki/User:Katherine_(WMF)) will > step into the role of interim Executive Director. We thank the C-levels for > their careful consideration in this process, and Katherine for stepping up > during this period of transition. To pre-empt any suggestion of disharmony from the usual wikimedia-l agitators, I think it's worth mentioning that Katherine Maher was the most-supported nominee in staff discussions on the office wiki. (I mean the tally on <https://office.wikimedia.org/wiki/ED_transition>) -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] Why we changed
On 22/02/16 18:45, Erik Moeller wrote: > The numbers for "very active editors" appear to have stabilized at a > slightly higher level than previously. I can't find any firm > conclusion on what has caused this in Wikimedia's public > communications, but the HHVM rollout, long-planned and implemented in > December 2014 under Ori Livneh's leadership seems like a plausible > hypothesis: > > https://blog.wikimedia.org/2014/12/29/how-we-made-editing-wikipedia-twice-as-fast/ I don't think it is plausible, given the data collected at: <https://meta.wikimedia.org/wiki/Research:HHVM_newcomer_engagement_experiment> 25,000 new users were put into an HHVM bucket, so the whole site was twice as fast for them. Then they were tracked for a week. There was no improvement in engagement or productivity. I'm sure the performance improvements we did in 2004-2005 had a big impact, especially initial batch of 9 Tampa servers in February 2004. There must be a scale effect: going from 20s to 10s is much more important than going from 2s to 1s. -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] Why we changed
On 22/02/16 11:22, Lila Tretikov wrote: > We started this transformation, but as we move > forward we are facing a crisis that is rooted in our choice of direction. Not really. The crisis has always been about means, not ends. I keep hearing people say "this is a good idea, but why did it have to be done this way?" The gripe list which the staff presented to you in November essentially said the same thing. It complained about process and the absence of strategy, not the choice of direction. > The choice in front the WMF is that of our core identity. Our mission can > be served in many ways, but we cannot do them all. We could either fully > focus on building our content and educational programs. Or we can get great > at technology as the force multiplier for our movement. I believe the the > former belongs to our volunteers and affiliates and that the role of the > WMF is in providing global support and coordination of this work. I believe > in -- and the board hired me to -- focus on the latter. You are referring to the "narrowing focus" strategy introduced by Sue Gardner in 2012. Indeed, you were hired to continue with Sue's tech-focused strategy, which was already fully established by the time you took office. Until now, I have not heard anyone suggest that it is still a significant source of conflict within the Foundation. > In the past year we managed -- for the first time since 2007 -- to finally > stem the editor decline. Well, the minimum number of very active editors on en.wikipedia.org was in September 2013, but yes, more or less. As the blog post said, nobody is quite sure why this has happened. Nobody is saying that Wikipedia is a lovely and friendly place to work. There is no WMF initiative that fully explains the reversal, although the Teahouse (which was not officially supported by WMF engineering) may have played a role. > Over the past two years I have actively pushed funding to improve > anti-harassment, child protection and safety programs; work in these areas > is ongoing. We are actively exploring some tangible approaches that -- I > hope -- will turn into concrete outcomes > <https://meta.wikimedia.org/wiki/Harassment_workshop>. I am very happy to see this. For years I argued for more effective moderation of Wikipedia as key to editor retention, and I was very frustrated that nobody ever had the guts to do anything about it. Not Sue, not the Board, not the ArbCom. I agree with your broad strategic goals (educate, innovate, retain volunteers, secure funding), I just doubt your ability to implement them. Because an ED of a non-profit organisation needs to be able to lead, not just dictate. And an effective manager should make decisions rationally and collaboratively. -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] Can we see the Knight grant application and grant offer?
On 07/02/16 09:41, Chris Keating wrote: >> >> >> I have some one question for you. >> >> I am having a very hard time wrapping my head around how the grant >> information you posted lead to WMF BoT voting James Heilman of the board in >> a vote of no-confidence. >> > > Ruslan - what makes you think the two issues are connected? > > I have heard nothing from the WMF that suggests that they are. > > A few other people are trying to draw some link between the two, but the > burden of proof is on them not on Lila Maybe you missed this: <https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Board_noticeboard/James_Heilman_removal_FAQ#What_happened.3F> In which James Heilman, by way of explaining why he was removed from the board, complains of a lack of transparency, links to the announcement of the Knight Foundation grant, and comments "many details however are still missing." -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] In Support of Community
On 13/01/16 04:36, Damon Sicore wrote: > Hi Doma, > > These are links to public posts containing cryptographic hash > values generated from documents that I wrote on or before the dates > of the posts. By posting these hash values publicly, I’m proving > to the world that I said something specific at a specific time. > The world does not know what I said, and only I can produce the > documents which, when hashed, produce these exact hash values. I guess this is a way to make predictions but avoid being laughed at if they don't come true? There are plenty of ways to do this without spamming wikimedia-l. For example: https://www.freetsa.org/ http://truetimestamp.org/ https://www.btproof.com/ -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] Announcement about changes to the Board
On 07/01/16 06:44, Denny Vrandecic wrote: > -- James was not removed from the Board because he was demanding more > transparency. I'm inclined to believe James at this point, since he is the only one giving a credible explanation of causes. If he was not dismissed for this, then why was he dismissed? That he lost the confidence of the board is obvious, a truism. > As I saw it, James acted out of process, ignored advice and caused > disruption. Which process? What advice? What disruption? Are you afraid he will sue you for libel? Tell the truth: I believe that is a defence in US law, as is fair comment on a matter of public interest. I will donate to your legal costs if he does sue you. People willing to talk to the public get to influence public opinion. That is an appropriate reward for transparency. > But I wonder what kind of changes would > be required to avoid a situation like this - if the rest of the Board loses > the trust in one of its members, how should we handle this? By putting personal sensitivities aside and acting in the common good. I support the power of the board to act quickly and decisively to protect the mission, but not without public review. To act in such a way without public review is contrary to the Guiding Principles. -- Tim Starling ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: 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] California drought and WMF
On 15/09/15 22:32, Milos Rancic wrote: > For the last few years I am thinking about this issue, and as I didn't see > anybody talking about that, I think we should start a kind of low level > discussion, as it doesn't require immediate action. > > From what I read, Bay Area is not particularly endangered (although it > could be in the future). Even so, I am sure all WMF employees have enough > money to buy bottled water. I know, of course, they are not in the same > position as Google or Facebook employees, but I think the whole story is > not about water safety of our headquarters. > > It's about responsibility. WMF shouldn't spend resources unreasonably if it > doesn't have to. And it's not just about possible "fund for water", which > could become a standard for every Bay Area employer, but also about the > environmental harm of the attitude of keeping yourself in hostile place if > not necessary. California is not a "hostile place" in terms of water resources. And according to [1], no long-term trend is evident in the historical record, and preciptation is forecast to drop by only 10% through to the late 21st century. California has by far the cleanest power in the US, and could easily afford to desalinate its way out of a drought if it chose to do so. Although it may be more efficient to use groundwater recharge as a multi-year reservoir instead of allowing farmers to make unrestricted withdrawals as is currently the case. -- Tim Starling [1] Our Changing Climate 2012 Vulnerability & Adaptation to the Increasing Risks from Climate Change in California - Brochure http://www.energy.ca.gov/2012publications/CEC-500-2012-007/CEC-500-2012-007.pdf ___ 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] WMF office location and remodel
On 17/04/15 19:13, rupert THURNER wrote: Tim, I am not too sure about this. No single piece of open source software comes to my mind when hearing bay area or silicon Valley. BSD, sendmail, vi, GTK+ and GIMP, Mozilla, Ceph, Docker. Do you not have the impression beeing located in the United states poisons the minds of people and has quite a bad influence on the technology output of Wmf? No. Did you ever meet some young hungry person with good ideas there willing to contribute? Yes, we hired some of them. The only goal of a brilliant person in the this area is to get rich with his own company. Maybe you should visit some day. Urban California is left-leaning, at least by American standards, full of compassionate, progressive people. San Francisco was at the centre of the hippie movement in the 1960s, and continues to have a leading role in America's civil rights dialogue. We get a constant stream of prospective employees who say their main reason for wanting to work for Wikimedia is because they want to do something positive with their lives, not just earn money. That would probably be true anywhere, but it underscores the fact that the Bay Area does not poison their minds. -- Tim Starling ___ 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] Access to Private Information Policy: How Long Will This Be Left a Question Mark?
On 13/04/15 00:12, Trillium Corsage wrote: On 25 April last year, the board of trustees approved, in a non-public and scantily-documented meeting, a policy that accords Checkuser and Oversight and other statuses to community members appointed by a community process with essentially a mere two requirements: provide an email address, and assert that you are 18 or over. Name, address, NOT required. Is this truly an adequate way to protect the privacy interests of all those that edit Wikipedia? Well, I don't think so, but my purpose right now is to try to eliminate the ambiguity of what is actually occurring at this time. I was not involved in the development of this policy, either the original one or the current iteration. So what follows are my independent, unofficial thoughts on the issue. I don't know what identifying people with checkuser permissions is meant to achieve, when they are not liable for a breach of the privacy policy. I can understand requiring identification for Board members, who have legal responsibilities. But what is the point of having a photocopy of a CheckUser's passport when there are no conceivable circumstances under which you would give that photocopy to police? Maybe the idea is that if a CheckUser publically doxes someone for some petty purpose, such as revenge, then the victim may subpoena identifying records from the Foundation as part of a suit against the CheckUser. Note that I have done my fair share of troll hunting, it occupied quite a bit of my time between when I first got shell access in early 2004 and when I introduced CheckUser in late 2005. I have publically discussed identifying information of logged-in users. I never heard any credible theory on how my actions at that time might have created legal liability. Surely, if there was such a legal remedy, trolls would constantly threaten to use it. I think that the most important practical measure we can take to protect users' privacy against CheckUser is to regularly audit the CheckUser logs. We should also work to improve their auditability. The logs have hundreds of entries of the form: * AdminUser got IP addresses for Spambot10255787 (Investigating spam) * AdminUser got users for 11.22.33.44/16 (Investigating spam) What auditor is ever going to do another CheckUser request to make sure that 11.22.33.44 really was an IP address used by Spambot10255787? How can we tell if AdminUser was interested in 11.22.33.44 for some other reason? Linked log entries should probably be explicitly annotated by the software. -- Tim Starling ___ 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 Signpost, 1 April 2015
It's nice that someone in the movement still has a sense of humour. Did you see the English Wikipedia's TFA box? https://en.wikipedia.org/w/index.php?title=Wikipedia:Today%27s_featured_article/requestsoldid=651029553#April_1 Support running as a straight ornithology article, with no attempt to be funny; Oppose any version played for laughs where the blurb is intentionally misleading. This make-the-blurb-misleading tradition is a legacy of Raul and should have been jettisoned a decade ago; it makes a mockery of genuinely important topics, it's incomprehensible to those in parts of the world which don't observe April Fools (that the stream of complaints it generate every year are always scrubbed from Talk:Main page and the complainants sneered at for not getting the joke, doesn't mean they're not genuine complaints), and it means anything that has genuine date significance for April 1 gets bumped to make way for cack-handed jokes. Yes, DYK and OTD still do this (although ITN doesn't), but the standards of DYK is not something that TFA should set as its ambition. – iridescent 21:36, 15 February 2015 (UTC) -- Tim Starling On 02/04/15 07:48, Andrea Zanni wrote: Well, I was really excited about the Sister project news... :-( (but I think it's a pretty neat joke) Aubrey On Wed, Apr 1, 2015 at 9:10 PM, Asaf Bartov abar...@wikimedia.org wrote: (reminder: This is a prank, for April Fools Day. Please feel free to ignore this issue entirely, or at any rate don't waste your time responding to this or getting upset/excited by it.) A. On Tue, Mar 31, 2015 at 10:06 PM, Wikipedia Signpost wikipediasignp...@gmail.com wrote: News and notes: New edits-by-mail option will revolutionize Wikipedia and its editor base http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2015-04-01/News_and_notes Special report: Pictures of the Year 2015 http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2015-04-01/Special_report Featured content: Stop Press. *Marie Celeste* Mystery Solved. Crew Found Hiding In Wardrobe. http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2015-04-01/Featured_content Single page view http://en.wikipedia.org/wiki/Wikipedia:Signpost/Single PDF version http://en.wikipedia.org/wiki/Book:Wikipedia_Signpost/2015-04-01 http://www.facebook.com/wikisignpost / https://twitter.com/wikisignpost -- Wikipedia Signpost Staff http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost ___ 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 -- Asaf Bartov Wikimedia Foundation http://www.wikimediafoundation.org Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us make it a reality! https://donate.wikimedia.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 ___ 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] Announcing: The Wikipedia Prize!
On 30/03/15 09:25, Brian wrote: I suspect this challenge will be very easy for anyone who is determined. Indeed, even if MediaWiki no longer displayed IP addresses, there would still be enough information to identify people. Completely getting rid of the edit history would largely solve the problem. So... what do you actually want? I am having trouble working out how many layers of sarcasm to strip back here to find your actual point. There are alternatives to publishing IP addresses that we have discussed before, for example automatically creating a user account with a random name and associating it with a persistent cookie. The user could set a password or just abandon the account by letting the cookie expire. CheckUser would still provide access to IP addresses. I would support such a change. I have no idea whether you would. After reading this post and your posts on wikien-l, here are my theories on what your non-sarcastic beliefs may be: 1. That we shouldn't store or use IP addresses at all, and that identification for abuse prevention should be done by some kind of unspecified cryptographic magic. 2. That disclosure and storage of IP addresses should be limited in some pragmatic way to reduce the risk of identification by cross-correlation in the manner you suggest in your $2.50 prize. 3. That Wikimedia's suit against the NSA is hypocritical and that both Wikimedia and the NSA have legitimate needs for data collection. Feel free to narrow it down for me. -- Tim Starling ___ 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] Commons copyright extremism
On 12/12/14 03:40, Steven Walling wrote: Commons should really just have stayed a database shared among projects, not been made into a wiki where all our more important projects are subject to the rules mongering of a tiny broken community. I don't know what that would technically look like. Commons was always a wiki with a community and a mission, it has never been just a database, so there is no obvious precedent to follow. If you have a central repository, then you at least need someone to review uploads. It would be technically trivial to make a second central image repository wiki, explicitly for fair use images. So maybe that is a solution. -- Tim Starling ___ 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] WaPo Wikipedia's 'complicated; relationship with net neutrality
On 01/12/14 15:24, svetlana wrote: Wikipedia is naturally slow and expensive for many ISPs, because we don't use a big CDN. Why don't we? Is it one of the expensive for us, cheap for users things? That may be part of it. Also, we have unusual technical requirements for freshness of content and prompt removal (revision deletion etc.), and an ops team with a desire for independence. -- Tim Starling ___ 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] [offlist] Re: WaPo Wikipedia's 'complicated; relationship with net neutrality
On 01/12/14 23:11, Federico Leva (Nemo) wrote: This comparison is quite useful and got rather popular: «For all the arcana in telecommunications law, there is a really simple way of thinking of the debate over net neutrality: Is access to the Internet more like access to electricity, or more like cable television service?». http://www.nytimes.com/2014/11/11/upshot/a-super-simple-way-to-understand-the-net-neutrality-debate.html I don't think the internet is especially similar to either. I think it is like the postal service. The analogous question to net neutrality is whether priority mail should be allowed, and whether it should cost more to send a package to another continent than it does to send it within the same city. Nobody is saying ISPs should adopt a cable model, giving you a subscription to a bundle of 100 websites tailored to your tastes and preventing access to anything else, as that article suggests. That is a straw man. Obviously your electricity company has no opinion on what brand of hairdryer you use, because your electricity company is not in the business of shipping hairdryers. But if you buy hairdryers online, the postal service or courier company will often have bulk discounts with certain suppliers, so they do effectively participate in selecting your hairdryer brand. You don't connect your laptop to the internet each morning and say one million bits, please! which is then delivered as white noise through your speakers. ISPs are not selling a commodity. -- Tim Starling ___ 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] WaPo Wikipedia's 'complicated; relationship with net neutrality
On 01/12/14 06:10, Todd Allen wrote: Second, well, of course all providers are happy to use Wikipedia (Zero) as a door opener to get the customer used to different treatment of data (which is a clear violation of net neutrality). Exactly this. Net neutrality means that the pipes are totally dumb, not favoring -any- service over any other in any way. Not Netflix, not Youtube, not Amazon, and not Wikimedia. Anything that says Data from this source will be (treated|priced) differently than data from another source is a violation of net neutrality. Period. That does not mean the definition is inadequate. The definition is there to ensure the pipe -stays dumb-, and that preferential treatment is never accepted. But the pipes are fundamentally not dumb -- there is a complex arrangement of transit prices and peering, and the companies that built transoceanic links want to recoup their investment. What you are saying is that you want the ISPs to provide the necessary cross-subsidies so that the pipes will appear to be dumb, to the end user. The question for any regulated cross-subsidy should be: what is its social benefit? If certain telcos are allowed to choose, it will be cheaper to access Wikipedia than cheezburger.com. Is that appropriate? What social benefits will it provide if we regulate to ensure that they are the same price? Vertical integration between content providers and ISPs is probably harmful to competition. The obvious way to deal with that is to split those companies. But even in a competitive marketplace, from a cost perspective, it totally makes sense that certain content providers will continue to be cheaper and/or faster, just because of geography. Wikipedia is naturally slow and expensive for many ISPs, because we don't use a big CDN. If ISPs sold services on a cost-plus basis, you would expect websites delivered via CDN to be cheaper than websites that are located at a single site, geographically distant from their users. -- Tim Starling ___ 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] Odder on moderation?!
On 12/08/14 11:23, John Mark Vandenberg wrote: Hi, Has Odder / Tomasz Kozłowski been put on moderation? I'm informed his emails sent to this list havent come through to the list for nearly 24 hrs, and he has not been notified of having been put on any moderation, and the moderators havent responded to queries sent directly, and havent actioned these moderated emails (deny or approve, doesnt matter) for almost a day. Yes, according to the mailman admin interface, he's on moderation. There are no pending moderator requests for wikimedia-l. -- Tim Starling ___ 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, Comming to a wiki near you
On 11/08/14 21:49, Brad Jorsch (Anomie) wrote: On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jay...@gmail.com wrote: Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'. Most of what MZMcBride posted there has nothing to do with actually breaking superprotection. Editing a page that isn't superprotected isn't a break in the protection feature itself, for example. Nor is hacking people's accounts. Right, we (devs) weren't asked to prevent admins from disabling MediaViewer, we were only asked to make it possible to protect pages in the MediaWiki namespace such that ordinary admins couldn't edit them. I understood the feature request as introducing a more gradual escalation path, it wasn't an attempt to directly achieve a particular goal. John Mark Vandenberg wrote: These patches only introduce a new policy, signalling a new era, and make it technically more challenging to bypass that new policy. The policy written says Sysops are not allowed to inject JavaScript into the reader's user-agent which interferes with WMF's favoured features. Erik was very clear about this policy change in his first email to this thread. -- Tim Starling ___ 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] Please rename this list to shitfight-l, and give us a list where civil discussion about wikimedia can take place
On 16/06/14 13:03, billinghurst wrote: I am looking for a productive mailing list that discusses matters of importance to the Wikimedia community. That the people on such a list can have these discussions politely, respectfully, and with concern for others in that the words that say, and attitudes taken. I want to see announcements, I want to see a higher quality of conversation on what should be a flaglist in the mailing list space of Wikimedia. That's a tautology. You can't postmoderate a mailing list. There's not even any meaningful access control (luckily the trolls haven't figured that out yet). You can't even premoderate in any meaningful way, because people use reply all to send messages directly to the thread participants. So there's not really any way to do better than what we're doing already. People get angry when there are 10 posts in a row on a topic that they don't care about, because they use unthreaded clients and so have no way to organise messages into groups. And people that do use threaded clients are constantly annoyed when people send to the list in a way that breaks threading. The way to have a better mailing list is to not use a mailing list. NNTP with a web frontend would be better in pretty much every way. -- Tim Starling ___ 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] RfC: Should we support MP4 Video on our sites?
On 17/01/14 01:14, Todd Allen wrote: This proposal asks to move to a free as in beer model, where content will be free to view, but not necessarily to reuse (and with the opaque license, it may not even be possible to tell). I don't really understand this argument. It's not like there are video cameras that record directly to Theora. So presumably, most videos uploaded to Commons start life as H.264 or some other proprietary format, and are transcoded to Theora before they are uploaded to Commons. The proposal is to make it possible to upload the source file and have the server do the transcode, whereas currently, the source file is private and thus not distributed under a free license. Currently, if you want to reuse an H.264 source file, you have to somehow contact the author, beg for a copy of the file, and hope that they haven't deleted it. With this proposal, if you want to reuse an H.264 file without a patent license, you can just download the Theora transcode from the server. I am having trouble thinking of a scenario where the current situation would be better for reuse than the proposed situation. If you can think of one, please tell me. -- Tim Starling ___ Wikimedia-l mailing list 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] Thanking anonymous users
On 14/01/14 00:18, Marc A. Pelletier wrote: On 01/13/2014 12:19 AM, Tim Starling wrote: Not as fast as revisions, and we seem to cope with those. Fair enough. So you'd implicitly create the user, track it by cookie? With some well designed UX this'd work well and hide IPs entirely (and allow users that do create an account to retroactively rename their contribs). Yes. Wouldn't that affect caching though? Not very much. We already give anonymous users a session cookie on edit, which suppresses the frontend cache, the primary reason being (drumroll) user talk page message notification. So the impact would be that the cache-suppressing cookie would have a longer expiry time. -- Tim Starling ___ Wikimedia-l mailing list 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] Thanking anonymous users
On 14/01/14 15:38, Marc A. Pelletier wrote: On 01/13/2014 11:20 PM, Tim Starling wrote: The English Wikipedia edit rate has been declining since about January 2007, and is now only 67% of the rate at that time. A linear regression on the edit rate from that time predicts death of the project at around 2030. That's... come /on/ Tim! You know better than to say silly things like that. The abuse filter alone could very well account for this (the prevented edits and the revert that would have taken place). :-) I used to do a lot of patrol back in those years and - for nostalgia's sake - I tried doing a bit over a year ago. The amount of surface vandalism has gone down a *lot* since. Reversing the decline in editor population has been a major strategic priority of WMF for many years. You are saying you have never heard of it before? Well, here is some reading material for you: http://blog.wikimedia.org/2009/11/26/wikipedias-volunteer-story/ https://strategy.wikimedia.org/wiki/Wikimedia_Movement_Strategic_Plan_Summary/Increase_Participation http://blog.wikimedia.org/2011/07/22/year-in-review-and-the-road-ahead-for-global-development/ http://opensourcebridge.org/sessions/1061 http://thread.gmane.org/gmane.org.wikimedia.foundation/63549 -- Tim Starling ___ Wikimedia-l mailing list 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] Thanking anonymous users
On 14/01/14 16:08, Marc A. Pelletier wrote: On 01/13/2014 11:56 PM, Tim Starling wrote: Reversing the decline in editor population has been a major strategic priority of WMF for many years. My own opinion about how that decline isn't nearly as bad as some claim is well known. But also entirely besides the point: I was referring to that specific statement of yours: A linear regression on the edit rate from that time predicts death of the project at around 2030. I kept expecting you to add Netcraft confirms it at some point. :-) Well, obviously I extrapolated a model to the point of absurdity, but I think it's better to derive a model from data than to make predictions based on unsubstantiated hope. In my post at 05:19 UTC, I assumed a stable edit rate, which I thought was an optimistic upper bound. But Matt thought that it was actually pessimistic? So I gave an example of a model that I consider to be pessimistic, for comparison. I don't think either model is realistic, I think the most likely reality lies somewhere in between. -- Tim Starling ___ Wikimedia-l mailing list 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] Thanking anonymous users
On 11/01/14 06:21, Ryan Kaldari wrote: These are two reason we don't have Thanks for anonymous editors: 1. Anonymous editors don't get notifications 2. Multiple editors often share the same IP address Problem #2 isn't as prominent as it use to be, but there are still many large companies and schools that connect to the internet through a single IP. I imagine that once IPv6 is widely in use, this problem will go away and we'll be able to turn on all notifications (including Thanks) for anonymous editors. We could have a persistent cookie with an ID number assigned to anonymous users, and send messages to that. Then anons would get their messages despite roaming between IP addresses, and they wouldn't get messages for other people who happen to share their IP. We could even allocate a row in the user table for them, which would be beneficial for various features that currently exclude anons due to the need to link to a user ID. -- Tim Starling ___ Wikimedia-l mailing list 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] Thanking anonymous users
On 13/01/14 15:35, Marc A. Pelletier wrote: What you're discussing is an unnamed user account that's implicitly created and lasts as long as the cookie does. Those are going to pile up *really* fast, especially from browsers that do not keep cookies for any reason. Not as fast as revisions, and we seem to cope with those. On the English Wikipedia, there were only ~27k anonymous edits per day over the last month, so it would take 10 years to add 100M rows at that rate, and the revision table has ~550M rows and we still haven't bothered to shard it. -- Tim Starling ___ Wikimedia-l mailing list 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] Dells are backdoored
On 30/12/13 23:28, James Salsman wrote: Tim was asking about benchmark fairness, so here, read this: http://armservers.com/2012/09/11/benchmarks-versus-the-real-world/ Yes, that seems pretty clear. They say that you can replace underutilised Intel CPUs with ARM CPUs, but agree with Intel's conclusion that if the CPU is fully utilised, Xeon is better than ARM in terms of performance per watt. Of course, there are other ways to deal with underutilised CPUs. For example, we have 16 memcached servers with 24 cores each, all with negligible CPU utilisation. They could have, say 4 cores each instead, right-sizing the compute infrastructure in Calxeda's lingo, which would greatly reduce the power requirements without the cost of deploying a new system architecture. Maybe if the workload was such that servers with 1 or 2 Xeon cores would still be underutilised, ARM would be worth a look. But we don't appear to have that situation at the moment, at least, not at a sufficient scale to warrant an investment of staff time. There are much larger inefficiencies that we don't have time to deal with. In eqiad, we have about 4700 cores running MediaWiki. Those are fully utilised except for essential headroom, so they wouldn't be appropriate for ARM, according to Calxeda's article. Neither of Calxeda's articles gives a figure for capital cost, so that a performance per dollar figure can be calculated, whereas Intel does provide that information. The obvious conclusion is that the cost is embarrassingly high. Calxeda only tells us that their server is cheaper and slower than the Intel one, they don't claim to have a lower capital cost for a given processing throughput. -- Tim Starling ___ Wikimedia-l mailing list 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] Dells are backdored
On 29/12/13 23:55, James Salsman wrote: Can we please stop paying the Microsoft and NSA taxes and start buying datacenter equipment which costs a lot less? Cubieboard/Cubietrucks for instance? Ref.: http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-doors-for-numerous-devices-a-940994.html That article doesn't say Dell equipment has a back door, it just says that there is surveillance software or hardware designed to work with Dell equipment. It doesn't even say that Dell equipment is especially vulnerable. There is no information in the documents seen by SPIEGEL to suggest that the companies whose products are mentioned in the catalog provided any support to the NSA or even had any knowledge of the intelligence solutions. -- Tim Starling ___ Wikimedia-l mailing list 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] Dells are backdored
On 30/12/13 14:55, James Salsman wrote: If you don't like Cubietrucks, then how about RADXA? At least with http://dl.radxa.com/rock/docs/hw/RADXA_ROCK_schematic_20130903.pdf you know exactly what you're getting and it doesn't cost a huge power bill. Maximum 100 Mbps ethernet connection. Also, it doesn't exist yet. We still failover when machines go out of service, and sure the caches would have different RAM configurations, but the fact is it doesn't cost more money to switch to ARM, and you jettison a bunch of legacy x86 crap that nobody uses but take millions of transistors which need to be powered. Why ask our donors to keep all those useless transistors warm? Are there some benchmarks which support this idea? I read http://armservers.com/2012/06/18/apache-benchmarks-for-calxedas-5-watt-web-server/ But it was full of distortions, like comparing the actual power usage of the ARM system with the TDP of the Intel system, and then using a workload which saturated the network link of the Intel system versus the CPU of the ARM system. Maybe this sort of fluff is part of the reason why Calxeda went bust. Marketing materials on Calxeda's website indicated that the system was priced such that it would be more expensive than Intel on a per-MIPS basis, but that you'd win in the long run through reduced power bills. It didn't sound like a cheap solution to me. I read this: http://www.theregister.co.uk/2013/12/13/facebook_arm_chips/ But it was clear that it was only at a prototype stage -- the benchmarks are not in yet because the development work needs to be done first. I read this: http://www.theregister.co.uk/2013/12/16/google_intel_arm_analysis/ which speculated that Xeon may still be better for CPU-intensive tasks, and ARM chips may be useful for storage control. But a Cubieboard or Radxa can't be used for storage, since they lack the necessary high-bandwidth connections. Leslie Carr wrote: At that point we'll probably need to redesign those boards which are incapable of doing these things, so we'll need a team of hardware engineers, plus a deal with a manufacturing plant. Google and Facebook are apparently taking that route. Maybe some day, this technology will be available for anyone to buy. -- Tim Starling ___ Wikimedia-l mailing list 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] Let's accept Bitcoin as a donation method
On 12/12/13 02:54, Nathan wrote: Bitcoin isn't native currency for anyone, and anyone who wishes to make a Bitcoin donation could certainly do so using a more standard currency. Well, this article from a year ago argues that bitcoin is safer for donors than donating national currency: http://www.forbes.com/sites/jonmatonis/2012/06/29/wikipedia-accepts-enemies-of-the-internet-currencies/ But just don’t try to donate safely in bitcoin — it’s not accepted. [...] Accepting anonymous bitcoin in addition to political currencies can be a way of declaring that freedom of speech still does matter. I would think that if anonymity is the main concern, a transaction system with a public log of all transactions would not be the best choice. https://en.bitcoin.it/wiki/Anonymity The obvious time-tested choice for anonymous payment is, of course, cash. Many charities do accept cash donations. Cash could be donated to the local chapter by dropping it into a donation box, then it could be either spent on local programs or forwarded to WMF. -- Tim Starling ___ Wikimedia-l mailing list 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] Let's accept Bitcoin as a donation method
On 11/12/13 06:58, Tomasz W. Kozlowski wrote: I'm sure those reading this list can Google the topic themselves, so I won't link to the many angry discussion that are taking place on the interwebs right now; I tried Googling, including news and blog searches, and couldn't work out what you are talking about. Maybe you should provide links. -- Tim Starling ___ Wikimedia-l mailing list 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] September 11 wiki
https://meta.wikimedia.org/wiki/Sep11wiki I think it's disrespectful to solicit contributions towards a memorial website, and then to fail to maintain that memorial website in a searchable format. Today, searching the web for phrases in contributed memorial pages brings up only ancient, presumably unmaintained Wikipedia mirrors, such as these: http://encyclopedia.kids.net.au/page/da/Daniel_Brandhorst http://www.knowledgerush.com/kr/encyclopedia/Daniel_Brandhorst/ In time, those will disappear from the web, as all other copies have done. Thus, relatives of the deceased will have no way to discover that these pages ever existed. In 2007, the September 11 wiki was moved to a non-Wikimedia site, evidently hosted by an individual without the capacity to preserve that content for posterity. It was offline after only 3 years. The data is still on our servers. I propose bringing the wiki back up, in read only mode, and leaving it like that either until such time as there is interest from a non-profit or government organisation in taking over the responsibility of indefinite hosting. It would only take an hour or so of ops work. It could stay like that for decades without needing any further maintenance. -- Tim Starling ___ Wikimedia-l mailing list 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] Office hours for VisualEditor
On 31/10/13 02:51, Newyorkbrad wrote: In an arbitration committee election a couple of years ago, I definitely recall confusion about whether a deadline of on a given date meant that the deadline expired as of the beginning of that date or the end of that date. Voting periods in SecurePoll are actually half-open intervals [S, E), i.e. starting at exactly time S, proceeding up to but not including time E. So E = 2013-11-03 00:00:00 is actually the correct way to express a voting interval that includes the whole of 2013-11-02 and nothing after that. However, I have been browbeaten into using 23:59:59 in more recent elections, thus stealing a whole second of potential voting time from our poor voters. -- Tim Starling ___ Wikimedia-l mailing list 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] Carbon footprints on Wikipedia.
Please either turn off digests and reply to the individual list mails, or use the NNTP interface at gmane.org, so that your Subject and References headers will be correct and threading will work. On 09/10/13 20:48, Geoff Beacon wrote: The work of Adrian Mitchell that I used was in a report to the UK Department of Food and Rural Affairs. I find it now hard to find. I think that is because it is politically inconvenient. The point about this work, as far as this discussion is concerned, is that it was not peer reviewed but a report to a government department. In my view it is clearly an important piece of work but I fear it would be rejected because it was not peer reviewed. See the moderator's comment mentioned in my BrusselsBlog piece I can see only one reason for citing a non-peer reviewed article: ego-spam. (That wasn't actually directed at me.) Wikipedia doesn't have moderators. It does have POV pushers, which are a different thing. [[WP:V]] recommends, but does not require, peer review for sources. I have just noticed that almost a year ago a prospective entry was put in the talk section of Wilipedia's [beef] article. It suggests a new section [Environmental impacts of beef] and has important information in it. This has not made its way into the main article. It should have despite any reservations. To only include absolutely polished information just gives and advantage to those with the resources to polish and possibly dubious motives. It's definitely a good idea to polish your text, especially if you are writing about a controversial topic. Note that text doesn't just make its way from the talk page to the article, an ordinary editor (like you) has to put it there. There is important information that should be on Wikipedia that is missing. I'm pleased to say that my shortened section on the Beddington Zero Energy Development [BedZED] hasn't yet been removed. It says Embodied Carbon: Large. 67.5 tonnes CO2e for a 100 square metre flat. (OK. Perhaps I should have dug out the non-peer reviewed reference that gives this figure which was done by one of the project sponsors.) If it stays perhaps I will add a section to [Beef], following the note in the talk section. The carbon footprint of beef: Very large. Between 12 and 35kg of CO2e are produced for every 1 kg of beef consumed What do you think? I think very large is too vague, it needs to be compared to something. Also, if you are concerned that 100 year GWP underestimates the impact of beef production, and want to use the 20 year GWP, then the obvious solution is to quote both. NPOV policy favours expansion over replacement. -- Tim Starling ___ Wikimedia-l mailing list 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] Carbon footprints on Wikipedia.
On 09/10/13 06:49, Geoff Beacon wrote: An authoritative and easy to used resource giving of the effect or our everyday activities is essential if voters are to know enough to influence politics. I cant find any entries on Wikipedia to match this. To some extent I blame Wikipedia's over emphasis on peer review and official sources. The [Carbon footprint] entry is probably counter-productive as it implies that the quoted sources are more reliable than they are. I fear some of these sources are incorrect, hide their proprietary information or are influenced by politics (i.e. government departments). What I would like to see are lots of entries on Wikipedia like: [the carbon footprint of beef] [the carbon footprint of air travel] [the carbon footprint of a new house] etc. I don't really understand where you are coming from with this. Your own website http://www.greenrationbook.org.uk/resources/ cites plenty of official, reliable sources which you could presumably cite when you write about these topics. On your blog, you complain about Wikipedians getting annoyed when you cite yourself as a secondary source, which seems fair enough -- why not just cite the primary sources directly? -- Tim Starling ___ Wikimedia-l mailing list 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] Invalid security certificate for en.wikipedia.beta.wmflabs.org
On 02/10/13 05:56, Federico Leva (Nemo) wrote: Yes, beta can't currently really be used unless you manually confirm certificates. (Which, by the way, you should never do on any website.) Why not? Self-signed certificates are as secure as plain HTTP, which you would think would be good enough for most people for connecting to a test wiki. We give all sorts of people access to labs, so a proper certificate for *.wmflabs.org shouldn't give you much additional confidence. -- Tim Starling ___ Wikimedia-l mailing list 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] Fwd: [Wikimania-l] git.wikimedia.org dead due to wikimania ; )
On 14/08/13 07:40, Oliver Keyes wrote: We have weekend support - for core services, which constitute our MediaWiki instances. Git, however, is not a core service - as Max accurately notes, while it makes development finicky and frustrating, I didn't know anyone used git.wikimedia.org. I think I've only visited it once. We're not talking about Git being down, just about one of the two web viewers being down (the other being GitHub). Web viewers of source code are a luxury -- they're handy when you're not a developer and so couldn't be bothered to clone the repository, but they're hardly a human right. Despite that, note that Leslie Carr did work on fixing it on the weekend. -- Tim Starling ___ Wikimedia-l mailing list 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] NSA
On 01/08/13 14:15, Anthony wrote: On Wed, Jul 31, 2013 at 9:27 PM, Ryan Lane rl...@wikimedia.org wrote: I would be fired and jailed before I knowingly let that occur. If this was the case I'd very surely not be working for Wikimedia Foundation. Key word there being knowingly. I don't know why the NSA would sneak around in our data centres mirroring our ethernet ports if they already have almost all of our access logs by capturing unencrypted traffic as it passes through XKeyscore nodes. I think you should save the conspiracy theories until after we switch anons to HTTPS, that's when they will have an incentive. -- Tim Starling ___ Wikimedia-l mailing list 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] What community initiatives have made an impact on editor engagement?
On 05/07/13 22:09, Federico Leva (Nemo) wrote: The recent community initiative with the highest impact I can think of is surely what Platonides and other members of the global (technical) community did on pt.wiki. Platonides noticed a configuration error on pt.wiki: CAPTCHA was required for all edits since 2008. The error was fixed in April. https://bugzilla.wikimedia.org/41745 Fresh stats produced by the WMF show that in May and June this produced a decrease of overall vandalism (or rather, of reverted edits) with a shocking +58 % increase of productive edits by IPs and +23 % for registered users. It seems pt.wiki may see the end of the decline after many years. :) https://pt.wikipedia.org/w/index.php?title=Usu%C3%A1rio(a):HAndrade_(WMF)/Pesquisa_Vandalismo/Segunda_Faseoldid=36301585 Discussion is ongoing on how pt.wiki will address this growth. Part of the community may think that nao estamos preparados para crescer. https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Projetos/Wikip%C3%A9dia/Reuni%C3%B5es/Reuni%C3%A3o_IRC_21-06-2013 Note that CAPTCHAs have now been re-enabled on the Portuguese Wikipedia. Erik made the decision, in response to on-wiki consensus. I deployed the change just now. https://bugzilla.wikimedia.org/show_bug.cgi?id=49860#c75 -- Tim Starling ___ Wikimedia-l mailing list 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] What community initiatives have made an impact on editor engagement?
On 05/07/13 22:09, Federico Leva (Nemo) wrote: The recent community initiative with the highest impact I can think of is surely what Platonides and other members of the global (technical) community did on pt.wiki. Platonides noticed a configuration error on pt.wiki: CAPTCHA was required for all edits since 2008. The error was fixed in April. https://bugzilla.wikimedia.org/41745 Saying that Platonides discovered a configuration error on pt.wp and fixed it is a bit like saying Captain Cook discovered New Zealand and fixed its lack of pigs. Of course, the pt.wp community was well aware of the situation. The response of the pt.wp community to the original emergency -- asking for CAPTCHAs to be enabled for everyone -- was very specific to that community. I have to wonder whether the requesters were hoping for implicit permanence. It's a reminder that we need a robust procedure for making temporary changes. In the past we have relied on the requester saying to us afterwards ok, it's all done now, you can revert it. That doesn't work if temporary is said with a wink. -- Tim Starling ___ Wikimedia-l mailing list 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] Blocking of HTTPS connection by China
On Fri, Jun 7, 2013 at 2:31 PM, Ryan Lane rl...@wikimedia.org wrote: A very small minority of users don't have HTTPS support, or their computers are so old that it makes the site unusably slow. That's a *very* small percentage of users, though. There's also the small issue of a billion people in China who can access our site by HTTP but not HTTPS. Making *.wikipedia.org unconditionally redirect from HTTP to HTTPS would have the effect of making it completely impossible for them to read anything, whereas currently, it is only difficult to read information on certain politically-sensitive topics. HTTPS would be useful for reducing government snooping in developed countries like the UK and Australia. But it's not a solution for China (because HTTPS is equivalent to null routing) or the US (because they can use court orders to accomplish whatever they want to achieve on the server side). -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] PRISM
On 11/06/13 05:21, Anthony wrote: On Mon, Jun 10, 2013 at 9:36 AM, Fred Bauder fredb...@fairpoint.net wrote: You are right, Anthony, never assume you're not dealing with idiots. If NSA is doing doing detailed surveillance of Tea Party activists or defense lawyers we are truly well along the road to hell. Maybe we are. It certainly wouldn't be unprecedented for the government to engage in witch hunts against certain political groups. Granted, it's more likely to be the FBI that has a file on Tea Party groups than the NSA, but still... According to the Washington Post, PRISM is primarily operated by the FBI. The data is stored by the FBI, and the NSA requests data from the FBI on a case-by-case basis. The FBI checks each search term to make sure the person named is not a US citizen. http://www.washingtonpost.com/world/national-security/us-company-officials-internet-surveillance-does-not-indiscriminately-mine-data/2013/06/08/5b3bb234-d07d-11e2-9f1a-1a7cdee20287_story_1.html So there is a separation of responsibilities, but there is no reason to think that US citizens are better protected against snooping than foreigners. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] PRISM
On 11/06/13 10:41, Anthony wrote: One thing I'd also appreciate is that if indeed Wikipedia access logs are not even collected in the first place (except for 1/1000 samples), that this be stated officially, rather than relying on a two-year-old comment by a single, now-former employee. In October 2012, I introduced an unsampled log of API requests, including IP addresses. This was in response to a server overload caused by the API which was very difficult to isolate due to the lack of meaningful logs. The retention time is currently 30 days. This means that, among other things, search autocomplete is logged. The logs are collected at the backend, which means that Squid cache hits will not be logged. So autocomplete requests for common terms and prefixes will appear rarely. This is not a secret -- the changes that made it happen were public at the time: https://gerrit.wikimedia.org/r/#/c/24274/ https://gerrit.wikimedia.org/r/#/c/26434/ I'm sure that the other teams (e.g. fundraising, mobile and analytics) can give you details of what access logs they collect and store. In general, access logs haven't been stored due to cost, rather than for any privacy reason. Lots of smaller services (e.g. blog.wikimedia.org) store access logs. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Go away, community (from WMF wiki at least)
On 12/05/13 02:48, Sue Gardner wrote: The staff working on the Wikimedia Foundation wiki have jobs they've got to get done, in support of the entire movement. If they spend days or weeks needing to persuade a single community member of the merits of something they want to do on the Foundation wiki, or if they need to modify their plans extensively to accommodate the opinions of a single community member, that reduces the amount of time available for them to do the rest of their work. Which, I repeat, is in the service of the movement overall. So it was a response to a particular conflict? My understanding is that the Wikimedia Foundation staff who work on the Foundation wiki have been grateful (and are grateful) for the help they've gotten from community members in maintaining the Foundation wiki, and that we hope they'll continue to help us. Let's hope so. But in my experience, stripping titles such as administrator from volunteers is an excellent way to get them to leave. It's not really about the technical privileges, these titles are a recognition of good work done, and a symbol of trust, and are one of the few rewards we give to volunteers. Stripping privileges from a volunteer is upsetting, and undermines their core motivation for contributing. So I can appreciate that the conflict needed to be resolved, but I have to wonder whether this was the best way to go about it. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] UK.Gov passes Instagram Act
On 02/05/13 18:07, Federico Leva (Nemo) wrote: A document describing best practices for diligent search in Wikimedia projects can be interesting, but for what Mathias says there is little use in it as part of this initiative, unless UK government wants to act in EU to find a common ground making the directive useful [hahahahah]. Orlowski is outraged at the idea of being able to use orphan works by paying a fee into a pool, because he thinks the fee will be too low. He is afraid of a world where the low fees paid to the pool will incentise users to be less diligent in their search for an owner. So imagine what he (and his supporters) would think of the idea of giving orphan works away for free, irrevocably, as would be required for Wikimedia use. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Wikimedia Foundation's non-disclosure agreement
On 10/03/13 01:30, David Gerard wrote: On 9 March 2013 14:20, Tomasz W. Kozłowski odder.w...@gmail.com wrote: #1: Does anyone know who might be able to provide a copy of an example NDA signed by WMF staff for use on Meta (at https://meta.wikimedia.org/wiki/Non-disclosure_agreements)? #2: If it isn't possible to release the text for the public, is there any particular reason behind that? We all know (or can guess) what's usually covered by such documents, so it doesn't really make sense /not/ to publish that. +1 - is the NDA itself under NDA or something? As I said already, it is not. On 10/03/13 01:32, K. Peachey wrote: 1. The legal department could quiet easily do it. If you ask a lawyer whether it is OK to blow your nose in public, they'll say with great anxiety hmmm, I don't know, let me get back to you on that. Then depending on how busy they are with other stuff, maybe they'll get back to you a few weeks later with some relevant case law. That is to say, there are plenty of people who could do it more easily than the legal department. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Editor retention (was Re: Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices))
On 08/01/13 20:30, Nikola Smolenski wrote: On 05/01/13 04:47, Tim Starling wrote: For example, requiring phone number verification for new users from developed countries would be less damaging. I don't see how is this supposed to help (and I don't think most new users would want to do this; I certainly wouldn't). Phone number verification would dramatically reduce the rate of new user creation. It would especially discourage casual vandalism and casual good-faith contributions (typo fixes, etc.). Combined with disabling anonymous edits, and allowing phone number ranges to be blocked, it should reduce the vandalism rate by at least an order of magnitude. The case for restricting the use of semi-automated anti-vandal tools would then be much stronger. Since the rate of new user creation would slow from a flood to a trickle, constructive and friendly engagement with new users would seem both more feasible and more essential. So editor retention would be improved, at the expense of editor recruitment. I don't know whether the net effect on the editor population would be positive or negative. But my theory is that the people who are discouraged by phone number verification would be less likely to hold a grudge against Wikipedia than the people who have their contributions reverted and nasty messages placed on their talk pages. Thus, editor numbers will rebound after phone number verification is disabled. The editor retention problem is best solved by enforcing policies which are aimed at ensuring new users feel welcomed. But if enforcement is impossible, then a weaker alternative would be to implement technical measures which will make those policies seem attractive. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] No access to the Uzbek Wikipedia in Uzbekistan
On 24/12/12 20:23, Anonymous User wrote: I don't know how much effort each of these two measures would be. If you'd ask me, I would suggest to be very serious, but we are not under a deadline (the situation has been like this for more than a year now), and setting the rel=caonical would already be really, really helpful. This is done now. It would be good if Google could crawl uz.wikipedia.org to update the canonical URLs. In case anyone is wondering, I don't think this would be a good thing to do on zh.wikipedia.org. The Chinese government would happily block *.wikipedia.org port 443 if it became popular. At least the current situation provides a way to work around keyword filtering for people who are sufficiently motivated -- if HTTPS was blocked, it would be much less useful. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Editor retention (was Re: Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices))
On 04/01/13 18:02, Erik Moeller wrote: I do agree that better mechanisms for dispute resolution, dealing with topic warring, article ownership, and plain old incivility are needed. But I don't believe that those issues are at the heart of the editor retention problem as you seem to suggest, but rather, that they tend to occur later in the editor lifecycle, among a subset of editors which in fact already has survived many of the primary factors that deter new editors and are therefore relatively likely to retain. The new editor experience is characterized more by templating and assembly line style enforcement of existing policies than it is by incivility, topic warring, article ownership and incivility. I'm wondering whether the key findings in Halfaker's recent rise and decline paper resonate with you: http://www-users.cs.umn.edu/~halfak/publications/The_Rise_and_Decline/ Yes, they do resonate with me. The paper says that established users who use Huggle and similar tools do not follow best practices when they revert the edits of new users. This leads to poor editor retention. I am saying that an expanded arbcom and its delegated officers should reprimand those Huggle users. I am not saying that the editor retention problem is the kind of thing that the arbcom currently deals with. I think the arbcom is limited in the kinds of problems it can deal with because its mandate and resources are limited. Existing data like the above supports strongly the notion that well-intentioned, good faith contributors are much more heavily discouraged in 2012 than they were in 2004 or 2005, but this can be explained in significant part with the influx of bad faith contributors that have necessitated increasingly heavy handed ways to control against bad edits (Huggle, Twinkle, AbuseFilter, etc.) -- which catch good faith editors in the crossfire -- as well as increasing expectations of what constitutes an acceptable quality edit / page creation. We need ways to deal with bad faith edits that don't require destruction of the project to achieve their purpose. For example, requiring phone number verification for new users from developed countries would be less damaging. When a Huggle user drives away a new good faith user, that new user might not return for decades. You can't reverse it no matter what new policies you introduce, you just have to wait for another person to be born and grow up. It would be less damaging to tell them sorry, we can't accept any new users from Comcast this year, try again next year! Note that the total edit rate has declined from 4.5M in January 2007 to 3.5M per month in October 2012. As a metric of the workload that places on very active users, consider that figure divided by the number of users with more than 100 edits per month: it works out to 950 per very active user per month in January 2007, up to 1078 per very active user per month in October 2012. So it is hard for me to believe that the total review workload has increased over that period to such an extent that our only option is now to revert both good and bad edits on sight, with no discussion. Presumably the proportion of bad edits has increased, but it should be quicker to deal with simple vandalism than to review a good faith edit and engage with the editor. But we can always do new user phone number verification if enforcing the revert policy turns out to be too hard, right? -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
[Wikimedia-l] Editor retention (was Re: Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices))
On 03/01/13 22:46, Martijn Hoekstra wrote: Editor retention programmes have some data there. Check wp:wer on en.wiki. how the data for the other projects match up I don't know. Yes, that page describes the problem in detail. But the suggestions they offer under how you can help are along the same lines as policies that have been in place on Wikipedia since 2002 or earlier. It's been tried, it didn't work. The problem is, some people want to feel powerful more than they want Wikipedia to grow. Or even if they want Wikipedia to grow on a cerebral level, exercising power over another user is immediately pleasurable, and they don't have sufficient impulse control to stop themselves from doing it. It should be obvious that what is missing is discipline. An arbitration committee with expanded scope, with full-time members funded by the WMF (at arm's length for legal reasons), could go a long way towards solving the problem. Some users will be reformed when their technical power is threatened (be that editing or admin access), others will just leave as soon as their reputation is at stake. There is risk, because the editor population will probably be reduced in the short term, and it's hard to know if it will ever recover. I don't know if there is anyone with the power to save Wikipedia who also has the required courage. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Editor retention (was Re: Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices))
On 04/01/13 16:01, Steven Walling wrote: On Thu, Jan 3, 2013 at 8:13 PM, Tim Starling tstarl...@wikimedia.orgwrote: It should be obvious that what is missing is discipline. An arbitration committee with expanded scope, with full-time members funded by the WMF (at arm's length for legal reasons), could go a long way towards solving the problem. Some users will be reformed when their technical power is threatened (be that editing or admin access), others will just leave as soon as their reputation is at stake. Right! Because we all know the solution to social problems is oligarchy. The solution for social problems is to have rules and a means to punish people who break them. This is well-established by experimental psychology, see for example: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2599936/ Oligarchy is not the only way to achieve this, but it is the model typically used in these game theory experiments. So it is hard for me to understand why you think it is ridiculous. Oligarchy is a popular model for the governance of organisations. WMF itself is governed by a Board of Trustees. Nobody seems to think that is ridiculous. I'm not saying that good behaviour on Wikipedia can be enforced by the direct efforts of a governing committee. I am saying that a governing committee could have sufficient resources under its control (case officers, etc.) to effect significant change. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices)
On 02/01/13 09:33, ENWP Pine wrote: Hi Pine, It might be because of the alcohol I've ingested these last days, but - what are you proposing exactly? Hapy new year, strainu I wasn't proposing any specific action. I was thinking, Big Data is a cool topic, it's a big topic in its own right, it's relevant to several aspects of Wikimedia, and other people might be interested in reading about it or thinking about it in relation to work that they're doing or priorities that they have. Maybe Wikimedia should have some sort of Buzzword Compliance Officer to manage this sort of thing. You know, scalable P2P in the cloud, mining big data on a NoSQL platform etc. etc. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] WMF HR and leadership questions
On 28/12/12 12:14, Gayle Karen Young wrote: *2d. Does WMF have a talent retention problem and if so what is being done about this? The short answer is No. The simplicity of this question is a bit misleading. I don't think we have a talent retention problem because we have amazing people working for us who have and will continue to. The reasons that people move on are sometimes but not always problematic. I think it's GOOD for people to leave the organization at various points - for their own career development, because the things that were more endemic to a start-up environment are a little less prevalent at our stage of organizational growth, etc. A count of office.wikimedia.org account deactivations suggests that about 59 people left the WMF in 2012, for whatever reason. To me, that seems like a lot of people. Maybe it's occasionally good for people to leave, but so many? -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] No access to the Uzbek Wikipedia in Uzbekistan
On 23/12/12 22:15, Anonymous User wrote: We discussed both with search engine providers and Wikimedia developers if there is a way to resolve this issue, and there is: by making the HTTPS version of the Uzbek Wikipedia canonical the search engines would list the HTTPS version in the search results, thus circumventing the glitch. As far as I understood the technical folks at Wikimedia this can be done with a small amount of effort. Is it enough to set the link rel=canonical, or is it also necessary to redirect? Either way, the Squid cache would have to be purged, then the search engines would have to reread that site. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Banners are too bright, too long
On 03/12/12 20:04, Erik Moeller wrote: Activation on hover (current behavior): https://en.wikipedia.org/wiki/Giovanni_Lorenzo?banner=B12_5C_120216_SuperCondensed_Hover If you ignore the banner and scroll down, then later accidentally move the cursor over the banner, the article scrolls up to the top, losing your place. That could be annoying, especially on long articles. It happens because the collapsed banner has position: fixed, whereas the expanded banner has position: absolute. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] (semi-OT) Open access catastrophic for Elsevier
On 23/09/12 05:24, David Gerard wrote: It's such a pity that Elsevier's attempt to legally block open access requirements [1] means that they must be destroyed utterly with not one stone left upon another and the ground salted. I'm crying real[2] tears here. http://blogs.library.duke.edu/scholcomm/2012/09/21/how-do-you-recognize-a-catastrophe/ http://blogs.library.duke.edu/scholcomm/files/2012/09/Berstein-report-on-Elsevier.pdf The world's smallest violin is playing the world's quietest tune, at $39.50 a play for non-subscribers. According to the PDF, each published article costs them 1954 GBP, and brings in a revenue of 3256 GBP. A very nice business to be in. They already charge the authors a processing fee of 2000 GBP per article, so they could break even with open access, without increasing the author fee at all. That would be bad for investors, but the company would survive. So maybe it's not quite time to dance on Elselvier's grave. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Russian Wikipedia goes on strike
On 11/07/12 00:32, David Gerard wrote: On 10 July 2012 15:29, Tim Starling tstarl...@wikimedia.org wrote: SOPA didn't threaten the existence of Wikipedia, Geoff Brigham opined otherwise, IIRC. Yes, on the basis that Wikipedia arguably falls under the definition of an 'Internet search engine'. http://blog.wikimedia.org/2011/12/13/how-sopa-will-hurt-the-free-web-and-wikipedia/ The definition was: The term ‘Internet search engine’ means a service made available via the Internet that searches, crawls, categorizes, or indexes information or Web sites available elsewhere on the Internet and on the basis of a user query or selection that consists of terms, concepts, categories, questions, or other data returns to the user a means, such as a hyperlinked list of Uniform Resource Locators, of locating, viewing, or downloading such information or data available on the Internet relating to such query or selection. http://www.govtrack.us/congress/bills/112/hr3261/text It's hard to see how Wikipedia could fall under this definition, but even if it did, what would be the consequences? A provider of an Internet search engine shall take technically feasible and reasonable measures, as expeditiously as possible, but in any case within 5 days after being served with a copy of the order, or within such time as the court may order, designed to prevent the foreign infringing site that is subject to the order, or a portion of such site specified in the order, from being served as a direct hypertext link. Geoff argued that we would have to manually review millions of links in order to comply with such a court order. But the definition of an internet site that would be specified under such a court order is: [T]he collection of digital assets, including links, indexes, or pointers to digital assets, accessible through the Internet that are addressed relative to a common domain name or, if there is no domain name, a common Internet Protocol address. We already index external links by domain name or IP address for easy searching, and we have the ability to prevent further such links from being submitted, for the purposes of spam control. The compliance cost would be no worse than a typical [[WP:RSPAM]] report. Maybe SOPA was a serious threat to freedom of expression on the Internet, and worth fighting against, but it wasn't a threat to Wikipedia's existence. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Why is not free?
On 09/07/12 06:17, birgitte...@yahoo.com wrote: The most basic answer (someone form WMF can correct me if I am somehow misled here) is that the logos are not released under a free license because they are trademarks. To be precise, the logos were not released under a free license because it was imagined that some day they would be trademarks. According to the trademark searches I did just now, the Wikipedia logo was only registered as a trademark in 2008, and the other projects as late as May 2012. The WMF felt that trademark licensing would be a useful way to raise money, as a complement to donations. For example, this website has a trademark license: http://wikipedia.wp.pl/ Obviously to support that sort of licensing arrangement, you need at least one sort of protection (copyright or trademark). Also, there was concern that a free license like the GFDL might be argued to be an implicit trademark license. Lawyers tend to be conservative on that type of issue. Currently, WMF does not even publish the 3D source files for the Wikipedia logo, or a high-resolution rendered image. I think that's a bigger problem than the lack of a free license, since it prevents people from improving the current poor-quality 3D rendering and contributing the results back to the project. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] TVTropes deletes all pages with Rape in title under advertising pressure.
On 27/06/12 06:46, Nathan wrote: It's simple. The WMF didn't do anything. The English Wikipedia did. That project effectively changed the content of the entire encyclopedia for political reasons. Actually, the SOPA blackout notice was developed and deployed by WMF staff. http://meta.wikimedia.org/w/index.php?title=MediaWiki:Centralnotice-template-blackoutaction=history http://meta.wikimedia.org/w/index.php?title=Special:CentralNoticeLogsoffset=2012011805limit=100 -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Re: [Wikimedia-l] Update on IPv6
On 02/06/12 05:04, Hersfold wrote: I'm very concerned that this is what's going to happen with the IPv6 change - something major is going to fail, and the wiki will become inaccessible, or some major security feature (blocking or protection, for example) will be rendered inoperable, leaving the wikis vulnerable to attack from all fronts. The latter situation seems to be more likely based on past issues, and unfortunately more problematic; once these issues get noted, it'll take only minutes for /b/, GNAA, and a long list of other vandals to figure it out and launch a full-scale attack that'll take weeks to clean up. We could just allow blocking of arbitrarily large IPv6 ranges. Then if there is some emergency, you can just block everyone who is using IPv6 from editing. The collateral damage would be smaller than the IPv4 /16 blocks which admins apply routinely. -- Tim Starling ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
