Wikimedia Blog

I'll quote myself from http://blog.wikimedia.org/2011/06/28/data-competition-announcing-the-wikipedia-participation-challenge/ about the competition:

Reading more, I’m pretty troubled by the selection of data: http://www.kaggle.com/c/wikichallenge/forums/t/674/sampling-approach

What’s the point of predicting only about recent editors, whose ranks have already been thoroughly harrowed by the endless tightening of policy and rise of deletionists? Wikipedia already has a horrendous reputation for screwing over contributors, so anyone who does much editing (and whose departure would be noticed by the criterion) is self-selecting now.

just the other day cryonics researcher Mike Darwin told me he had no interest in contributing because he was sure all his contributions would be reverted under an extremely narrow reading of WP:RS, and wondered whether his BLP article could just be deleted since he certainly wasn’t going to edit it into an article worth a damn

reading wikipedia blog post:
https://blog.wikimedia.org/2014/08/01/wikipedia-zero-and-net-neutrality-protecting-the-internet/

"We believe that free access to public interest resources can be provided in a manner that keeps the playing field level and avoids net neutrality issues."

The program is partnering with carriers to give away access to Wikipedia (although no money is exchanged between the carrier and Wikipedia). It doesn't sound like it avoids NN issues. Giving away access to a certain website.. sounds exactly like an NN issue.

And I don't think Wikipedia's competitors would think this "keeps the playing field level" either. How would they compete against Wikipedia, when their users have to pay to access their service, but dont have to pay to access wikipedia?

Wasn't this the same issue we had with Facebook's Zero program in India?

Wikimedia has always been in favor of net neutrality, it's just that their role in the issue was always muddled by zero rating. From 2014:

> The Wikimedia Foundation believes that the principle of net neutrality is critical to the future of the open Internet. (https://blog.wikimedia.org/2014/08/01/wikipedia-zero-and-net-neutrality-protecting-the-internet/)

In that article they also discuss how they reconcile net neutrality with Wikimedia Zero. From December 2017:

> Net neutrality is essential for access to knowledge (https://blog.wikimedia.org/2017/12/04/net-neutrality-access-to-knowledge/)

Regarding Wikipedia strongly supporting net neutrality, I'm not sure I would agree considering it didn't participate in the day of action on December 12. (https://en.wikipedia.org/wiki/Day_of_Action_to_Save_Net_Neutrality)

Project: R.I.P.Link - a tool for finding dead links on the web[0].

The inspiration for this project came from Wikipedia and the Internet Archive partnering to fix broken links on Wikipedia[1]. After briefly searching around I couldn't find any great tools for this, and I decided it would be an interesting side-project. I was also looking for a good medium-size project to improve my Go skills and understanding of concurrent programming.

From here I'd like to implement recursive searching functionality and depth limiting. I think this would greatly improve the appeal of the tool.

* [0] https://github.com/mschwager/riplink
* [1] https://blog.wikimedia.org/2016/10/26/internet-archive-broken-links/

Some organizations such as the Wikimedia Foundation, Google, and Facebook believe that their services are more important than others. As such, they consider themselves deserving of cheaper, free, or the "fast lane" internet, especially in less developed areas without sufficient infrastructure to serve all websites. The rationale is that providing a limited set of websites for free is better than if those areas have no access to internet at all.

Note: The views of the mentioned organizations do not necessarily reflect my own views.

[0] https://en.wikipedia.org/wiki/Free_Basics

[1] https://blog.wikimedia.org/2014/08/01/wikipedia-zero-and-net-neutrality-protecting-the-internet/

Two points:

- Performance is important even for web applications. For example, after migrating to HHVM, Wikipedia could buy less servers, serve pages faster, and reduce latency.[1] Rust is fast, even compared to other statically compiled languages.

- Safety is also good to have for web development. I personally find it difficult to refactor my Python web applications. This isn't necessarily an advantage of Rust solely, statically typed languages tend to have this property more or less. But Rust does provide more guarantees than ordinary languages do.

[1] http://blog.wikimedia.org/2014/12/29/how-we-made-editing-wikipedia-twice-as-fast/