[Wikimedia-l] Re: EU designates Wikipedia a Very Large Online Platform

2023-04-27 Thread Magnus Manske via Wikimedia-l
We'll have to start stealing and selling user data to fit in...


On Thu, Apr 27, 2023 at 10:13 AM David Gerard  wrote:

> https://ec.europa.eu/commission/presscorner/detail/en/ip_23_2413
>
> In the same category as Facebook, Twitter, Amazon, TikTok ...
>
> On the face of it, this seems a miscategorisation. However, the
> recommendations aren't *bad*, and they're stuff we basically do anyway
> - though through volunteer editors, not the Foundation.
>
> The main nuisance will be a report as if we're Facebook.
>
> How are we approaching this one?
>
>
> - d.
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/AEWKAMWM3WITONWYEG3LUY4PR7R4RFVT/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/HOAWCHBAN26NWWOXZPOTS2I56DKAMP5Y/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

Re: [Wikimedia-l] Fresh data on the gender gap in content

2020-02-10 Thread Magnus Manske via Wikimedia-l
I also had a tweet, about gender ratio in Wikidata, grouped by external
property:
https://twitter.com/MagnusManske/status/1224703188693069827

On Sat, Feb 8, 2020 at 9:25 AM Asaf Bartov  wrote:

> Hello, everyone.
>
> Back in June 2016, on this thread, I had published some data on the
> *content
> gender gap* in Wikipedia biographies (i.e. how many articles are about men
> versus how many are about women). I intended to keep generating snapshots
> of these stats, to track progress against the gap, but then realized the
> excellent WHGI project[1] is already collecting and preserving snapshots of
> the data, so I did not do so myself.
>
> However, being curious about the numbers for a particular community, I
> realized WHGI does not provide an easy way to compare snapshots across
> time.  The data is all there[2], but a convenient visualization and
> comparison tool between two arbitrary snapshots is not available yet.  So
> while I did not build such a tool myself, I did update my little page with
> fresh numbers, *plus a comparison to the June 2016 *numbers.
>
> You may find the data interesting:
>
> https://meta.wikimedia.org/wiki/User:Ijon/Content_gap#Data_as_of_February_2020
> (note that the table is sortable by clicking the column heads)
>
> While it is difficult to ascribe the change to specific programs, overall
> there can be little doubt that the increased attention to the content
> gender gap, alongside specific programs and groups such as Women in Red,
> Art+Feminism, WikiMujeres, WikiDonne, and even certain runs of
> #100wikidays, have all contributed to narrowing the gap on most Wikipedias.
>
> Special congratulations to the Punjabi, Malayalam, and Odia Wikipedias,
> which have all narrowed the gap by more than 10 points!  Of the larger
> wikis, great progress was made by the Vietnamese and Armenian Wikipedias.
>
> As before, I'll note:
>
> 1. Your efforts, particularly on small-to-medium wikis, can really make a
> dent in these numbers!
>
> 2. I encourage you to share these numbers with your communities.  Perhaps
> you'd like to overtake the wiki just above yours? :)
>
> Cheers,
>
>A.
>
> [1] https://whgi.wmflabs.org/gender-by-language.html
> [2] https://whgi.wmflabs.org/snapshot_data/
>
> On Thu, Jun 16, 2016 at 10:14 PM Asaf Bartov 
> wrote:
>
> > Hullo everyone.
> >
> > I was asked by a volunteer for help getting stats on the gender gap in
> > content on a certain Wikipedia, and came up with simple Wikidata Query
> > Service[1] queries that pulled the total number of articles on a given
> > Wikipedia about men and about women, to calculate *the proportion of
> > articles about women out of all articles about humans*.
> >
> > Then I was curious about how that wiki compared to other wikis, so I ran
> > the queries on a bunch of languages, and gathered the results into a
> table,
> > here:
> > https://meta.wikimedia.org/wiki/User:Ijon/Content_gap
> >
> > (please see the *caveat* there.)
> >
> > I don't have time to fully write-up everything I find interesting in
> those
> > results, but I will quickly point out the following:
> >
> > 1. The Nepali statistic is simply astonishing! There must be a story
> > there.  I'm keen on learning more about this, if anyone can shed light.
> >
> > 2. Evidently, ~13%-17% seems like a robust average of the proportion of
> > articles about women among all biographies.
> >
> > 3. among the top 10 largest wikis, Japanese is the least imbalanced.
> Good
> > job, Japanese Wikipedians!  I wonder if you have a good sense of what
> > drives this relatively better balance. (my instinctive guess is pop
> culture
> > coverage.)
> >
> > 4. among the top 10 largest wikis, Russian is the most imbalanced.
> >
> > 5. I intend to re-generate these stats every two months or so, to
> > eventually have some sense of trends and changes.
> >
> > 6. Your efforts, particularly on small-to-medium wikis, can really make a
> > dent in these numbers!  For example, it seems I am personally
> > responsible[2] for almost 1% of the coverage of women on Hebrew
> Wikipedia!
> > :)
> >
> > 7. I encourage you to share these numbers with your communities.  Perhaps
> > you'd like to overtake the wiki just above yours? :)
> >
> > 8. I'm happy to add additional languages to the table, by request.  Or
> you
> > can do it yourself, too. :)
> >
> >A.
> >
> > [1] https://query.wikidata.org/
> > [2] Yay #100wikidays :) https://meta.wikimedia.org/wiki/100wikidays
> > --
> > Asaf Bartov
> > Wikimedia Foundation 
> >
> > 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
> >
>
>
> --
> Asaf Bartov
> Wikimedia Foundation 
>
> 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
> 

Re: [Wikimedia-l] Farewell, Erik!

2019-02-07 Thread Magnus Manske via Wikimedia-l
Erik,

thanks for your great work on stats, and welcome back to the volunteer
force.
Where the real work is done :-)

Magnus

On Thu, Feb 7, 2019 at 10:31 AM Sandra Rientjes - Wikimedia Nederland <
rient...@wikimedia.nl> wrote:

> Dear Erik,
>
> Many thanks for all the help and support you gave Wikimedia Nederland and
> myself over the past years. Whenever we had tricky stats-related questions,
> we knew we could turn to you.
>
> I hope to see you at many WMNL-events in the future.
>
> Enjoy the freedom!
>
> Best,
>
> Sandra
>
>
> Sandra Rientjes
> Directeur/Executive Director Wikimedia Nederland
>
> tel.(+31) (0)30 3200238 <+31%2030%20320%200238> (ma, di, do)
> mob. (+31) (0)6  31786379 <+31%206%2031786379> (wo, vrij)
>
> www.wikimedia.nl
>
>
> Mariaplaats 3
> 3511 LH  Utrecht
>
>
> Op do 7 feb. 2019 om 11:22 schreef rupert THURNER <
> rupert.thur...@gmail.com
> >:
>
> > Many thanks erik and all the best!! One sentence in eriks blog post
> cited i
> > found surprising. What type of modesty you guys were talking about?
> >
> > "At Wikimania London (2014) I talked about how we should err on the side
> of
> > modesty. That message never came across. I started to have a discussion
> on
> > this within WMF but failed to bring this to fruition. My bad."
> >
> >
> >
> > On Wed, Feb 6, 2019, 22:18 Dario Taraborelli  > wrote:
> >
> > > “[R]ecent revisions of an article can be peeled off to reveal older
> > layers,
> > > which are still meaningful for historians. Even graffiti applied by
> > vandals
> > > can by its sheer informality convey meaningful information, just like
> > > historians learned a lot from graffiti on walls of classic Pompei.
> > Likewise
> > > view patterns can tell future historians a lot about what was hot and
> > what
> > > wasn’t in our times. Reason why these raw view data are meant to be
> > > preserved for a long time.”
> > >
> > > Erik Zachte wrote these lines in a blog post
> > > <
> > >
> >
> https://web.archive.org/web/20171018194720/http://infodisiac.com/blog/2009/07/michael-jackson/
> > > >
> > > almost
> > > ten years ago, and I cannot find better words to describe the gift he
> > gave
> > > us. Erik retired 
> this
> > > past Friday, leaving behind an immense legacy. I had the honor to work
> > with
> > > him for several years, and I hosted this morning an intimate, tearful
> > > celebration of what Erik has represented for the Wikimedia movement.
> > >
> > > His Wikistats project —with his
> signature
> > > pale yellow background we've known and loved since the mid 2000s
> > > <
> https://web.archive.org/web/20060412043240/https://stats.wikimedia.org/
> > > >—has
> > > been much more than an "analytics platform". It's been an individual
> > > attempt he initiated, and grew over time, to try and comprehend and
> make
> > > sense of the largest open collaboration project in human history,
> driven
> > by
> > > curiosity and by an insatiable desire to serve data to the communities
> > that
> > > most needed it.
> > >
> > > Through this project, Erik has created a live record of data describing
> > the
> > > growth and reach of all Wikimedia communities, across languages and
> > > projects, putting multi-lingualism and smaller communities at the very
> > > center of his attention. He coined metrics such as "active editors"
> that
> > > defined the benchmark for volunteers, the Wikimedia Foundation, and the
> > > academic community to understand some of the growing pains and editor
> > > retention issues
> > > <
> > >
> >
> https://web.archive.org/web/20110608214507/http://infodisiac.com/blog/2009/12/new-editors-are-joining-english-wikipedia-in-droves/
> > > >
> > > the movement has faced. He created countless reports—that predate by
> > nearly
> > > a decade modern visualizations of online attention—to understand what
> > > Wikipedia traffic means in the context of current events like elections
> > > <
> > >
> >
> https://web.archive.org/web/20160405055621/http://infodisiac.com/blog/2008/09/sarah-palin/
> > > >
> > > or public health crises
> > > <
> > >
> >
> https://web.archive.org/web/20090708011216/http://infodisiac.com/blog/2009/05/h1n1-flu-or-new-flu-or/
> > > >.
> > > He has created countless
> > > 
> > visualizations
> > > <
> > >
> >
> https://blog.wikimedia.org/2017/10/27/new-interactive-visualization-wikipedia/
> > > >
> > > that show the enormous gaps in local language content and
> representation
> > > that, as a movement, we face in our efforts to build an encyclopedia
> for
> > > and about everyone. He has also made extensive use of pie charts
> > > <
> > >
> >
> https://web.archive.org/web/20141222073751/http://infodisiac.com/blog/wp-content/uploads/2008/10/piechartscorrected.png
> > > >,
> > > which—as friends—we are ready to turn a blind eye towards.
> > >
> > > Most importantly, the data Erik has brougth to life has been ci

Re: [Wikimedia-l] UNESCO Challenge

2017-04-18 Thread Magnus Manske
On-topic: All UNESCO sites on WIkidata (red=no image!)
https://tools.wmflabs.org/wikishootme/#lat=11.328998809313038&lng=-14.4140625&zoom=3&layers=wikidata_image,wikidata_no_image&sparql_filter=%3Fq%20wdt%3AP757%20%5B%5D&worldwide=1

On Tue, Apr 18, 2017 at 8:35 AM James Heilman  wrote:

> This is wonderful. Will at this to the Travelers pub at Wikivoyage :-)
>
> J
>
> On Tue, Apr 18, 2017 at 12:53 AM, Eric Luth 
> wrote:
>
> > Dear Wikimedians,
> >
> > On 18 April (today), the International Day for Monuments and Sites is
> > celebrated. On the same day, the first edition of the UNESCO Challenge
> >  will also take place.
> > The challenge will last for a full month.
> >
> > The UNESCO Challenge is a challenge co-arranged by UNESCO, the Swedish
> > National Heritage Board and Wikimedia Sverige, with the purpose to
> improve
> > Wikipedia articles on world heritage sites. UNESCO are going to release a
> > couple of thousand images (they will be added in this category
> >  >),
> > and a lot of Open Access texts about the sites, which may be used in the
> > challenge.
> >
> > Write in whatever language you like! You find the page for participation
> > and points registration here
> > .
> >
> > Please help us spread the word!
> >
> > *Eric Luth,*
> > Wikimedia Sverige
> > ___
> > 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,
> > 
>
>
>
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
>
> The Wikipedia Open Textbook of Medicine
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

2017-03-15 Thread Magnus Manske
Hi Josh, all,

I am not one hell-bent on "FOSS or death"; I tend to use whatever works
best.

That said, the cost-benefit analysis of using Apple Maps seems to boil down:
* Apple Maps has slightly better rendering (didn't check, but I assume)
* Apple Maps uses less mobile bandwidth
* Apple Maps is not free (as in freedom)

Now, looking at these points:

* Somewhat better quality is not an argument. If it were, we would have
stayed with Britannica, and skipped that whole Wikipedia nonsense.
Wikipedia became better, in part, because people actually used it, saw the
issues, and fixed them. And OSM rendering might be not quite en par with
Apple Maps, it is quite usable, in my experience.

* Less bandwidth usage is not an argument either. I doubt we are talking
about a significant percentage of an average users' data volume here. If
Android users can afford the bandwidth, so can people who buy an iPhone
(source: used to have iPhone).

* The price tag is the "non-freedom". As far as I can tell, this would be
the very first Wikimedia "product" that incorporates non-free technology
and data. It sets a precedence. It also has the potential to poison the
otherwise great relations between the Wikipedia, Wikidata, and OSM
community. It says "OSM is not good enough (at least for Apple users)"
quite plainly. How would we feel if OSM started to remove Wikidata tags and
replace them with Britannica links?

All in all, IMHO, the cost is too high for the (at best) flimsy benefits.

Cheers,
Magnus


On Wed, Mar 15, 2017 at 12:52 AM Joshua Minor  wrote:

> Hello,
>
> My name is Josh Minor, and I am the Product Manager for the Wikipedia iOS
> app. I wanted to speak to a couple specific issues and misunderstandings
> raised by this email thread.
>
> First, please take a look at
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service which
> provides some background on this decision. Jonatan linked to it, and it
> covers several of the concerns raised on the thread and gives our
> reasoning. I'd also suggest subscribing to this ticket:
> https://phabricator.wikimedia.org/T157763 which Jonatan filed, and where
> you can track efforts and issues with replacement maps.
>
> A few clarifying points:
>
> 1. The Places tab[1], and its use of Apple’s maps tiles, is not part of the
> articles or article display, it is a navigational aid to help you find
> articles. This doesn’t mean it’s exempt from considerations raised here,
> but just want to clarify that this is not about editor created maps in
> projects, but rather an app-specific discovery mechanism.
>
> 2. The feature doesn’t violate our privacy policy[2] and was reviewed by
> Wikimedia Foundation's Legal department before entering beta. The App’s
> access to the users’ geolocation to recommend nearby articles, with the
> users’ explicit consent, is already part of both apps. The new feature
> merely adds a different way to visually view nearby articles - the user
> must, as before, still provide explicit consent for the App to access their
> geolocation. Users can always turn on or off the provision of their
> geolocation via their iPhone location settings.
>
> The feature also makes requests to Apple’s map tile servers for display on
> the App. These tiles may or may not be near the actual location of the
> user. It doesn’t involve sending Apple the articles you read or anything
> about your Wikipedia usage. Apple has public statements and documentation
> to explain[3] how their maps service preserves privacy by using a
> randomized and frequently changing device ID to request the maps, by not
> tracking users over time, and by not  building map usage profiles of users.
> Overall, Apple’s data collection practices are governed by their privacy
> policy [4], which  users must agree to order to use their iPhones.
>
> We plan to further expand the explanation in the FAQ/privacy section of the
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service page
> in
> the next day or so.
>
> 3. As stated by others on this thread, the issue at hand is the feasibility
> and usability of a libre maps tile server, and impacts on users and how it
> reflects (or doesn’t) the values of Wikimedians. The rest of the work on
> this feature (such as the time spent on search, visually clustering items
> on the map, a list view of nearby landmarks, and the Wikipedia article
> pins) will be applicable, independent of the map provider. In fact, I’d
> estimate the engineer doing the work spent more time on hacking to try to
> make a combination of MapBox and Wikimedia tiles work, than he did/will on
> integrating/removing Apple maps.
>
> 4. This feature was announced on the Wikimedia Blog[5], described in an
> initial MediaWiki.org page[6], all work was documented and tracked on
> Phabricator (including an initial tech investigation, the request to remove
> Apple Maps during development, and the overall feature[7]) and then the
> decision to push into beta with Apple Maps furth

Re: [Wikimedia-l] Pebble smartwatch tool for finding Wikipedia photo opportunities

2016-11-07 Thread Magnus Manske
Looks like a cool thing indeed! Any chance to expand that to Wikidata? It's
a superset of all Wikipedias, plus things like UK National Heritage sites,
so it will give you many more candidates in some regions.

On Sat, Nov 5, 2016 at 10:30 PM Sage Ross 
wrote:

> Hi folks!
>
> I made something that I think is pretty cool: a watchface for Pebble
> smartwatches that shows you the nearest unphotographed Wikipedia
> article. I've been using it for about a month, and I'm really happy
> with how it's turned out. I've taken a lot of photos for articles that
> I wouldn't have otherwise.
>
> It's called "Diderot". If you have a Pebble, check it out:
> https://apps.getpebble.com/en_US/application/57dc94602a6ea66551f0
>
> A few neat things about it:
>
> * You can configure it for a number of different language versions of
> Wikipedia
> * It uses a wmflabs API by Albin Larrson which filters out articles
> that have only a png or svg illustration, so you still see the
> articles that have a map or logo but lack a real photograph.
>
> -Sage
>
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Fresh data on the gender gap in content

2016-06-17 Thread Magnus Manske
Nepali seems to have come a long way since I ran my analysis:
http://magnusmanske.de/wordpress/?p=250
(see the big dot-plot; note that I compare the length of the articles,
rather than their number)

On Fri, Jun 17, 2016 at 11:01 AM Ting Chen  wrote:

> Hello Asaf, hello Florence,
>
> the inbalance is surely partly due to the cultural bias (both
> contemprary as well as historical) of our world. Across the cultures in
> before 18th century women found less notice in the historical
> documentation. As far as I know about Japanese history, this bias was
> less prominant in the Japanese history, this only change since the rise
> of the Shoguns (about 12th century). Could this be part of the reason of
> the ja-wp result?
>
> If it is the case than Wikipedia and Wikidata could be a very valuable
> resource for cultural history researches since never before there was
> such a systematic gathering of so much correlated data.
>
> Take the 20th century, would the data reflect the change (or reluctance
> to change) of the bias in art, politics and economy?
>
> If yes, I think we should spread word inside of the research community
> because in my opinion the research community had until now still didn't
> pay attention to this pile of data that all the volunteers had put
> together and are just waiting for them to mine.
>
> Greetings
> Ting
>
>
> Am 16.06.2016 um 23:14 schrieb Florence Devouard:
> > Hello Asaf,
> > Just making sure that you knew about WHGI :
> > http://whgi.wmflabs.org/gender-by-language.html
> >
> > Do you know if there are differences in analysis between the two
> > analysis ?
> >
> > I checked a few figures and it fits pretty well.
> >
> > Flo
> >
> >
> > Le 16/06/16 à 21:14, Asaf Bartov a écrit :
> >> Hullo everyone.
> >>
> >> I was asked by a volunteer for help getting stats on the gender gap in
> >> content on a certain Wikipedia, and came up with simple Wikidata Query
> >> Service[1] queries that pulled the total number of articles on a given
> >> Wikipedia about men and about women, to calculate *the proportion of
> >> articles about women out of all articles about humans*.
> >>
> >> Then I was curious about how that wiki compared to other wikis, so I ran
> >> the queries on a bunch of languages, and gathered the results into a
> >> table,
> >> here:
> >> https://meta.wikimedia.org/wiki/User:Ijon/Content_gap
> >>
> >> (please see the *caveat* there.)
> >>
> >> I don't have time to fully write-up everything I find interesting in
> >> those
> >> results, but I will quickly point out the following:
> >>
> >> 1. The Nepali statistic is simply astonishing! There must be a story
> >> there.  I'm keen on learning more about this, if anyone can shed light.
> >>
> >> 2. Evidently, ~13%-17% seems like a robust average of the proportion of
> >> articles about women among all biographies.
> >>
> >> 3. among the top 10 largest wikis, Japanese is the least imbalanced.
> >> Good
> >> job, Japanese Wikipedians!  I wonder if you have a good sense of what
> >> drives this relatively better balance. (my instinctive guess is pop
> >> culture
> >> coverage.)
> >>
> >> 4. among the top 10 largest wikis, Russian is the most imbalanced.
> >>
> >> 5. I intend to re-generate these stats every two months or so, to
> >> eventually have some sense of trends and changes.
> >>
> >> 6. Your efforts, particularly on small-to-medium wikis, can really
> >> make a
> >> dent in these numbers!  For example, it seems I am personally
> >> responsible[2] for almost 1% of the coverage of women on Hebrew
> >> Wikipedia!
> >> :)
> >>
> >> 7. I encourage you to share these numbers with your communities.
> >> Perhaps
> >> you'd like to overtake the wiki just above yours? :)
> >>
> >> 8. I'm happy to add additional languages to the table, by request.
> >> Or you
> >> can do it yourself, too. :)
> >>
> >>A.
> >>
> >> [1] https://query.wikidata.org/
> >> [2] Yay #100wikidays :) https://meta.wikimedia.org/wiki/100wikidays
> >>
> >
> >
> >
> > ___
> > 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,
> > 
>
>
>
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Gender gap on "classical" encyclopedias

2016-04-20 Thread Magnus Manske
I wrote about gender coverage on Wikipedia and Wikidata, including ODNB
comparison:
http://magnusmanske.de/wordpress/?p=250


On Wed, Apr 20, 2016 at 8:39 AM  wrote:

> Hi, as some of you may know, the Wikipedia gender indicator [1] tells us
> how many articles are biographies about women x language/country/culture.
>
> In order to compare these numbers...Does anyone knows if there is an
> existing comparison with gender balance in classical encyclopedias?
> (Britannica, Larousse...) or, if not, could someone prepare a WD query
> about it?
>
> I think it could be a good argument for us to use: e.g "at cawiki 12% of
> bios are about women, compared to 5% in GEC, Our most famous encyclopedia".
>
> We could compare it also for temathic encyclopedias or other databases
> existing in projects like Mix and match.
>
> Can someone help? thanks in advance
>
>
> [1]http://wigi.wmflabs.org/
>
>
> Àlex Hinojo
> User:Kippelboy
> Amical Wikimedia Programme manager
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Wikiwand

2016-03-31 Thread Magnus Manske
While this is true, there has been some improvement on Wikipedia. Desktop
browsers now have the Wikiwand "media gallery" as the Media Viewer, and
Wikivoyage (as a test platform) has the interactive maps.

On mobile, things are even better; most of the Wikiwand mobile features are
also in the official Wikipedia app, and then some.

That multilingual search, though...

On Thu, Mar 31, 2016 at 8:33 AM Gerard Meijssen 
wrote:

> Hoi,
> If anything they provide us a service. Anything they can do, we can do
> integrated.  Anything they can do, we can learn from. Anything they prove
> works better is often a discussion the others have lost their firm footing.
>
> We are very much stuck in fixed thinking modes. It is why Wikisource is
> only about its editors and not about its readers. For one Wikisource there
> has been something like Wikiwand and nobody cared. We know we can improve
> the quality of Wikipedia's links and redlinks in the same way we improved
> interwiki links, the improvement will be measurable and quick and it is not
> even considered. There is enough we can do better, it is known by many,
> particularly by the developers and UI people.
>
> We deserve Wikiwand because we could have done better. By making it a
> company, the people behind Wikiwand put their money where there mouth is.
> As an argument it is a strong one.
>
> NB we are doing better in places. When you have followed the road towards
> mobile integration you will agree. However, there is still so much that can
> be done. It starts with reflection of many of our hobby horses and
> ingrained positions.
> Thanks,
>GerardM
>
> On 31 March 2016 at 08:39, Anders Wennersten 
> wrote:
>
> > What is WMFs position on Wikiwand [1]?
> >
> > is it a complement or a commercial run interface that is  better that we
> > can offer?
> >
> > Anders
> >
> > [1] http://www.wikiwand.com/about
> >
> > ___
> > 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,
> > 
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] [Maps-l] Wiki maps news and updates

2016-03-15 Thread Magnus Manske
Great work!

On Tue, Mar 15, 2016 at 12:13 AM Yuri Astrakhan 
wrote:

> The quest to bring maps to Wikipedia continues:
> * Kartographer has launched for WikiVoyage
> * Julien Girault will help maps with his UI expertise
> * Talk to us at the FreeNode IRC channel #wikipedia-interactive
>
> https://www.mediawiki.org/wiki/Help:Kartographer
>
> Last week we enabled Kartographer extension for Wikivoyage sites, allowing
> users to add maps to wiki pages without any additional wmflabs and
> JavaScript tricks.  Now you can simply add a  or  to a
> wiki page, or even use the Visual Editor to insert a map. Additionally, you
> can:
>
> * add markers and polygons visually
> * edit geojson and see how it changes the map on each keystroke
> * add auto-numbered markers (either numbers or letters), and have multiple
> counters
> * have multiple "groups" of markers/polygons and showing them on the same
> map or on separate maps (e.g. all food and all drink maps and one combined
> map)
> * markers can be of any color, 3 sizes, and contain many different icons
> * markers and polygons can be clicked and will show popups with wiki text
> and images
> * very fast full screen popup map
>
> Feedback: https://www.mediawiki.org/wiki/Talk:Maps
> Bugs & TODOs: https://phabricator.wikimedia.org/tag/kartographer/
> All maps-related tasks: https://phabricator.wikimedia.org/tag/maps/
>
> == What's next? ==
> There will be plenty of cleanup and polishing work to make Kartographer
> work seamlessly. We will need to address the missing functionality reported
> to us by the community, and help migrate existing wmflabs-based maps to the
> new platform. Lastly, VE editing will need some more work to become
> indispensable.
>
> Yet, our site is still set on the bigger target - maps for all of
> Wikipedia. For that we are waiting for more hardware, plus we will need to
> improve our static maps service to be able to handle wiki-load.
>
> Hardware task: https://phabricator.wikimedia.org/T125126
>
>
> Thank you Max Semenik, Ed Sanders, Alex Kosiaris, Brandon Black, Chris
> Koerner, Chris Steipp, Tomasz Finc, and Wes Moran for making this possible.
> ___
> Maps-l mailing list
> map...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/maps-l
>
___
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, 


Re: [Wikimedia-l] Profile of Magnus Manske

2016-03-12 Thread Magnus Manske
I like this for the interface, and as you said for the screen reading
function. I hear WMF is working on some TTS thing now?

Not sure it would significantly alter my ratios at the moment, especially
given its rather low takeup (i presume). In your example, it would actually
make the ratio worse for Wikipedia, providing evidence for more than one
statement per sentence ;-)


On Sat, Mar 12, 2016 at 6:53 PM Anthony Cole  wrote:

> Ugh. This: https://en.wikipedia.org/wiki/Template:Ref_supports2#Example
>
> Anthony Cole
>
>
> On Sun, Mar 13, 2016 at 2:51 AM, Anthony Cole  wrote:
>
> > Ugh.I just edited the page and now it's not working. Try this:
> > https://en.wikipedia.org/wiki/Template:Ref_supports2/Example
> >
> > Anthony Cole
> >
> >
> > On Sun, Mar 13, 2016 at 2:42 AM, Anthony Cole 
> wrote:
> >
> >> Regarding "Unless I missed it, there is no good way to automatically
> >> discern what a  refers to - a word, a sentence, a paragraph." Check
> >> out the first paragraph and its references here:
> >> https://en.wikipedia.org/wiki/Victoria_and_Albert_Museum_Spiral.
> >>
> >> Hovering your mouse over each footnote marker (or, depending on your
> >> MediaWiki preferences, the dotted line under it) will tell you what each
> >> reference is supporting. The ideal solution would be highlighting the
> >> supported text on the page, rather than having it appear in a tool tip.
> >>
> >> I wish the WMF would organise that - and organise it in a way that
> screen
> >> readers can read it.
> >>
> >> Anthony Cole
> >>
> >>
> >> On Sun, Mar 13, 2016 at 1:57 AM, Magnus Manske <
> >> magnusman...@googlemail.com> wrote:
> >>
> >>> On Sat, Mar 12, 2016 at 4:18 PM Anthony Cole 
> >>> wrote:
> >>>
> >>> > Ah. You mean you're counting all footnote markers (including those at
> >>> the
> >>> > end of paragraphs). You're not just counting the number of references
> >>> at
> >>> > the bottom of the page. Yes I saw that. But you are missing my point.
> >>> Many
> >>> > editors use one footnote marker to support all the sentences in a
> >>> > paragraph. Many use one footnote marker to support all sentences
> after
> >>> the
> >>> > last footnote marker.
> >>> >
> >>> > There are many multi-sentence paragraphs in
> >>> > https://en.wikipedia.org/wiki/Cancer_pain with just one footnote
> >>> marker
> >>> > supporting all the sentences. Using your metric, the sentences at the
> >>> > beginning and middle of those paragraphs would be counted as
> unsourced
> >>> > statements.
> >>> >
> >>>
> >>> Yes. Unless I missed it, there is no good way to automatically discern
> >>> what
> >>> a  refers to - a word, a sentence, a paragraph. As described, my
> >>> "one
> >>> sentence, one statement" metric is a lower bound of statement numbers.
> So
> >>> is my  count, then. I am certain you can find an article where my
> >>> statement-to-reference ratio is off against WIkipedia; but I believe I
> >>> could find more instances where it is in favour of Wikipedia.
> >>>
> >>>
> >>> >
> >>> > But, really, who cares? The whole thing is a non-argument. It just
> >>> doesn't
> >>> > matter which project is more poorly referenced.
> >>> >
> >>>
> >>> Well, considering the amount you write about it, apparently you care
> :-)
> >>>
> >>> My argument, and I believe I made this reasonably solid, is that one
> >>> can't
> >>> "sit on Wikipedia", pointing finders at Wikidata for poor referencing.
> >>> Which is what Andreas Kolbe implicitly did (amongst other things). That
> >>> is
> >>> all.
> >>>
> >>> Cheers,
> >>> Magnus
> >>>
> >>>
> >>> >
> >>> > Anthony Cole
> >>> >
> >>> >
> >>> > On Sat, Mar 12, 2016 at 11:59 PM, Anthony Cole 
> >>> > wrote:
> >>> >
> >>> > > Magnus, I've just re-scanned your essay and don't see mention of
> you
> >>> only
> >>> > > counting footnote markers within the paragraphs and not at the end
> of
&

Re: [Wikimedia-l] Profile of Magnus Manske

2016-03-12 Thread Magnus Manske
On Sat, Mar 12, 2016 at 4:18 PM Anthony Cole  wrote:

> Ah. You mean you're counting all footnote markers (including those at the
> end of paragraphs). You're not just counting the number of references at
> the bottom of the page. Yes I saw that. But you are missing my point. Many
> editors use one footnote marker to support all the sentences in a
> paragraph. Many use one footnote marker to support all sentences after the
> last footnote marker.
>
> There are many multi-sentence paragraphs in
> https://en.wikipedia.org/wiki/Cancer_pain with just one footnote marker
> supporting all the sentences. Using your metric, the sentences at the
> beginning and middle of those paragraphs would be counted as unsourced
> statements.
>

Yes. Unless I missed it, there is no good way to automatically discern what
a  refers to - a word, a sentence, a paragraph. As described, my "one
sentence, one statement" metric is a lower bound of statement numbers. So
is my  count, then. I am certain you can find an article where my
statement-to-reference ratio is off against WIkipedia; but I believe I
could find more instances where it is in favour of Wikipedia.


>
> But, really, who cares? The whole thing is a non-argument. It just doesn't
> matter which project is more poorly referenced.
>

Well, considering the amount you write about it, apparently you care :-)

My argument, and I believe I made this reasonably solid, is that one can't
"sit on Wikipedia", pointing finders at Wikidata for poor referencing.
Which is what Andreas Kolbe implicitly did (amongst other things). That is
all.

Cheers,
Magnus


>
> Anthony Cole
>
>
> On Sat, Mar 12, 2016 at 11:59 PM, Anthony Cole 
> wrote:
>
> > Magnus, I've just re-scanned your essay and don't see mention of you only
> > counting footnote markers within the paragraphs and not at the end of
> > paragraphs.
> >
> > And why wouldn't you count a footnote marker at the end of a paragraph
> if,
> > as I've just explained, the sole citation at the end of a paragraph often
> > supports all statements in the paragraph?
> >
> > Why would you assume one sentence only contains one fact?
> >
> > Choosing a lead sentence as your example - Denny did the same in his
> > response to Andreas's critique - is potentially misleading because,
> > provided statements are repeated and supported by a reliable source in
> the
> > body of an article, citations are not expected or required in
> en.Wikipedia
> > article leads.
> >
> > Your methodology is flawed; fatally biased toward exaggerating
> Wikipedia's
> > lack of references. But. I really don't care because I think the
> > reliability of Wikipedia and level of referencing in Wikipedia is
> > appalling.
> >
> > Forgive me for mischaracterising your argument as, ""Wikipedia is worse".
> > You appear to be saying, "Well, Wikipedia is bad, too." That's true but
> > still an invalid argument.
> >
> > It was someone else who put the "It's a wiki" argument.
> >
> > Several of your colleagues above have complained that adding references
> is
> > difficult in Wikidata. And your response is what? "Actually, it is easy
> > to add references to Wikidata, certainly not more difficult than adding
> > them to Wikipedia." Please listen to people, will you?
> >
> > You still seem to think the problem with the roll-out of the media viewer
> > and visual editor was the stoopid power users.
> >
> > Anthony Cole
> >
> >
> > On Sat, Mar 12, 2016 at 10:11 PM, Magnus Manske <
> > magnusman...@googlemail.com> wrote:
> >
> >> On Sat, Mar 12, 2016 at 12:27 PM Anthony Cole 
> >> wrote:
> >>
> >> > Hi Magnus.
> >> >
> >> > I'm re-reading this thread and just noticed you linked me to an essay
> >> [1]
> >> > earlier. I'm sorry, I didn't realise at the time that you were
> >> addressing
> >> > me.
> >> >
> >> > Comments have closed there, so I'll post my thoughts here. You
> describe
> >> a
> >> > formula for measuring how well Wikipedia is supported by reliable
> >> sources.
> >> > Basically, correct me if this is wrong, you presume that each sentence
> >> > contains one statement of fact and compare the number of sentences
> with
> >> the
> >> > number of footnote markers. That ratio is what you call the references
> >> per
> >> > statement (RPS) ratio. You have another formula

Re: [Wikimedia-l] Profile of Magnus Manske

2016-03-12 Thread Magnus Manske
rge that they do not want the product at all *until they are
> > resolved*. By not only using the user as a beta tester, but also
> > forcing the product on them in the period between the discovery of the
> > issues/bugs and the time they are resolved, Wikimedia in my opinion is
> > instrumental in turning the objections against specific issues into
> > resistance against the product as a whole.
> >
> >
> > On Tue, Jan 19, 2016 at 3:56 PM, Magnus Manske
> >  wrote:
> > > Anthony, it does seem you've missed some of which I wrote in this
> > thread. I
> > > have no problem with specific criticism where it is deserved, and I do
> > well
> > > remember that the Visual Editor, in its early incarnation, was not
> quite
> > up
> > > to the job.
> > >
> > > What I do have a problem with is people fixating on some technical or
> > > early-lifecycle issues, declaring the entire thing worthless, even
> > > dangerous, and spreading that view around. This behaviour, I have seen
> > time
> > > and again, with the Media Viewer, with Wikidata.
> > >
> > > It's bad because it's broken - let's come together and fix it.
> > >
> > > It's bad because ... well, everyone says it's bad. And new. And Not
> Made
> > > Here. THAT is a problem, and not a technological one.
> > >
> > > On Tue, Jan 19, 2016 at 2:39 PM Anthony Cole 
> > wrote:
> > >
> > >> Magnus, you've missed the point of the visual editor revolt. A couple
> of
> > >> people here have tried to explain that to you, politely. And you're
> > >> persisting with your idée fixe.
> > >>
> > >> There were two parts to the visual editor catastrophe, actually. The
> > >> product wasn't ready for anyone to use. Not veteran editors. Not
> > newbies.
> > >> Newbies who used it were less likely to successfully complete an edit.
> > It
> > >> was broken, and the WMF insisted we had to use it.
> > >>
> > >> The second part of the problem was arrogance. Yes, a few editors were
> > >> unnecessarily rude about the product and the developers. But then most
> > of
> > >> the developers and tech staff who dealt with the community arrogantly
> > >> characterised *anyone* who complained about the product as an
> ignorant,
> > >> selfish Ludite - and you're persisting with that characterisation now.
> > >>
> > >> The WMF under Lila has learned the lessons from that, and they have
> > >> fostered a much healthier relationship between the developers and the
> > >> community. You clearly haven't learned all you might have.
> > >>
> > >> In fact, reading the arrogant responses from you here and in the
> > concurrent
> > >> thread titled "How to disseminate free knowledge," and from Denny in
> > >> earlier threads addressing criticism of WikiData, it seems to me there
> > is
> > >> still a significant arrogance problem that needs addressing, at least
> > over
> > >> at WikiData.
> > >>
> > >> Some people may approach you arrogantly, maybe even insultingly, about
> > an
> > >> innovation, and I suppose you might be justified in talking down to
> > them or
> > >> ridiculing them (though I advise against it.). But if you can't
> > distinguish
> > >> them from those who approach you with genuine concerns and
> well-founded
> > >> criticisms, then no matter how clever you think your technical
> solutions
> > >> are, you will soon find you're no more welcome here than those WMF
> > staffers
> > >> who thought insulting well-meaning critics was a good career move.
> > >>
> > >> Denny's contemptuous dismissal of valid criticisms of his project, and
> > your
> > >> contemptuous dismissal of the valid criticisms of the early visual
> > editor
> > >> and its launch are both very disappointing.
> > >>
> > >> Anthony Cole
> > >>
> > >>
> > >> On Tue, Jan 19, 2016 at 7:24 AM, Magnus Manske <
> > >> magnusman...@googlemail.com>
> > >> wrote:
> > >>
> > >> > The iPhone was a commercial success because it let you do the basic
> > >> > functions easily and intuitively, and looked shiny at the same time.
> &

Re: [Wikimedia-l] Powerful on-wiki art visualization

2016-02-23 Thread Magnus Manske
I just saw! Exciting!!!

(I guess un-cached interactive graphs would make the "largest disasters"
list ;-)

On Tue, Feb 23, 2016 at 1:50 PM Yuri Astrakhan 
wrote:

> Who said you cannot already use Wikidata Query service? ))
>
> https://mediawiki.org/wiki/Extension:Graph/Demo/Sparql/Largest_disasters
>
> Limitation at the moment - not enabled for interactive graphs yet until we
> make better caching.
> On Feb 23, 2016 16:17, "Magnus Manske" 
> wrote:
>
> > Especially once it supports the Wikidata query engine.
> >
> > On Tue, Feb 23, 2016 at 1:12 PM  wrote:
> >
> > > Amazing stuff! This is going to change the face of Wikipedia.
> > >
> > > Best!
> > > Subhashish Panigrahi
> > > Programme Officer, Access To Knowledge
> > > Centre for Internet and Society
> > > @subhapa / https://cis-india.org
> > >
> > > - Original Message -
> > > From: "Edward Saperia" 
> > > To: "UK Wikimedia mailing list" 
> > > Sent: Tuesday, February 23, 2016 6:38:53 PM
> > > Subject: Re: [Wikimedia-l] Powerful on-wiki art visualization
> > >
> > > This... is... amazing!! The idea of commonly seeing these on Wikipedia
> > > pages fills me with immense joy!
> > >
> > > It seems to me like we might be able to kick off a big project to
> create
> > > and promote useful templates and guides for creating these. The dataviz
> > > movement is very popular among designers and journalists, and they're
> > > always looking for tools, lessons and data to practise on. Are there
> any
> > > existing efforts to popularise this, or would anyone like to help me do
> > so?
> > >
> > > *Edward Saperia*
> > > Founder Newspeak House <http://www.nwspk.com/>
> > > Conference Director Wikimania 2014 <http://wikimania2014.wikimedia.org
> >
> > > email  • facebook <
> > http://www.facebook.com/edsaperia>
> > > •
> > >  twitter <http://www.twitter.com/edsaperia> • 07796955572
> > > 133-135 Bethnal Green Road, E2 7DG
> > >
> > > On 23 February 2016 at 03:15, Yuri Astrakhan  >
> > > wrote:
> > >
> > > > First complex interactive graph in Wikipedia explores the most
> > expensive
> > > > paintings in history. Move the mouse around to view images, click the
> > > > period or artist to highlight their work.
> > > >
> > > >
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/List_of_most_expensive_paintings#Interactive_graph
> > > >
> > > > Thank you Jane [[user:Jhoffswell]], the VegaJS team, and
> > > [[user:Primaler]]
> > > > who designed the original graph!
> > > >
> > > > P.S. See graph demo page for examples and tutorial links
> > > > https://www.mediawiki.org/wiki/Extension:Graph/Demo
> > > >
> > > > P.P.S. The "click to open a page" feature is still missing in Graphs
> > > > extension, but is on my todo list.
> > > > ___
> > > > 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>
> > > ___
> > > 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>
> > >
> > > ___
> > > 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>
> > ___
> > 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>
> ___
> 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>
___
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] Powerful on-wiki art visualization

2016-02-23 Thread Magnus Manske
Especially once it supports the Wikidata query engine.

On Tue, Feb 23, 2016 at 1:12 PM  wrote:

> Amazing stuff! This is going to change the face of Wikipedia.
>
> Best!
> Subhashish Panigrahi
> Programme Officer, Access To Knowledge
> Centre for Internet and Society
> @subhapa / https://cis-india.org
>
> - Original Message -
> From: "Edward Saperia" 
> To: "UK Wikimedia mailing list" 
> Sent: Tuesday, February 23, 2016 6:38:53 PM
> Subject: Re: [Wikimedia-l] Powerful on-wiki art visualization
>
> This... is... amazing!! The idea of commonly seeing these on Wikipedia
> pages fills me with immense joy!
>
> It seems to me like we might be able to kick off a big project to create
> and promote useful templates and guides for creating these. The dataviz
> movement is very popular among designers and journalists, and they're
> always looking for tools, lessons and data to practise on. Are there any
> existing efforts to popularise this, or would anyone like to help me do so?
>
> *Edward Saperia*
> Founder Newspeak House 
> Conference Director Wikimania 2014 
> email  • facebook 
> •
>  twitter  • 07796955572
> 133-135 Bethnal Green Road, E2 7DG
>
> On 23 February 2016 at 03:15, Yuri Astrakhan 
> wrote:
>
> > First complex interactive graph in Wikipedia explores the most expensive
> > paintings in history. Move the mouse around to view images, click the
> > period or artist to highlight their work.
> >
> >
> >
> https://en.wikipedia.org/wiki/List_of_most_expensive_paintings#Interactive_graph
> >
> > Thank you Jane [[user:Jhoffswell]], the VegaJS team, and
> [[user:Primaler]]
> > who designed the original graph!
> >
> > P.S. See graph demo page for examples and tutorial links
> > https://www.mediawiki.org/wiki/Extension:Graph/Demo
> >
> > P.P.S. The "click to open a page" feature is still missing in Graphs
> > extension, but is on my todo list.
> > ___
> > 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,
> > 
> ___
> 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,
> 
>
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Ethics of launching Wikidata, vs. ethics of WMF plans for Wikidata

2016-01-26 Thread Magnus Manske
On Tue, Jan 26, 2016 at 7:33 AM Pete Forsyth  wrote:

> (Note: I'm creating a new thread which references several old ones; in the
> most recent, "Profile of Magnus Manske," the conversation has drifted back
> to Wikidata, so that subject line is no longer applicable.)
>
> Andreas Kolbe has argued in multiple threads that Wikidata is fundamentally
> problematic, on the basis that it does not require citations. (Please
> correct me if I am mistaken about this core premise.)


Every statement on Wikidata /should/ be referenced, unless the statement
itself points to a reference (e.g. VIAF, images). However, at the moment,
this is not a requirement, as Wikidata is still in a steep growth phase.
Over the last few years, many statements were added by bots, which can
process e.g. Wikipedia, but would be hard pressed to find the original
reference for a statement.

Humans, bots, and tools increaingly add references to Wikidata statements;
I wouldn't be surprised if Wikidata starts requiring references within the
next few years on all (new) statements.


> I've found these
> threads illuminating, and appreciate much of what has been said by all
> parties.
>
> However, that core premise is problematic. If the possibility of people
> publishing uncited information were fundamentally problematic, here are
> several platforms that we would have to consider ethically problematic at
> the core:
> * Wikipedia (which for many years had very loose standards around
> citations)
> * Wikipediocracy (of which Andreas is a founding member) and all Internet
> forums
> * All blogs
> * YouTube
> * Facebook
> * The Internet itself
> * The printing press
>
> Every one of the platforms listed above created opportunities for people --
> even anonymously -- to publish information without a citation. If we are to
> fault Wikidata on this basis, it would be wrong not to apply the same
> standard to other platforms.
>
> I'm addressing this now, because I think it is becoming problematic to
> paint Wikidata as a flawed project with a broad brush. Wikidata is an
> experiment, and it will surely lead to flawed information in some
> instances. But I think it would be a big problem to draw the conclusion
> that Wikidata is problematic overall.
>
> That said, it is becoming ever more clear that the Wikimedia Foundation has
> developed big plans that involve Wikidata; and those big plans are not open
> to scrutiny.
>
> THAT, I believe, is a problem.
>

Well, I sure hope WMF has big plans for Wikidata! But do you know of any
such plans that don't revolve around the usual suspects, such as
importing/linking to extisting datasets, or re-using Wikidata in
third-party sites and products?
For example, a "secret" plan along the lines of "company X wants to use
Wikidata, but they don't want to announce this publicly yet" would be
perfectly fine by me. Wikidata is CC-0; technically, no one needs to even
ask permission or link back.
I simply do not see any sinister, nefarious plan the WMF /could/ have for
Wikidata, given their long established policy of staying away from editing
contents.

If you have even minimum indications of "evil" WMF plans for Wikidata,
please share them! Saying "I know nothing about their plans, therefore they
must be evil" doesn't really cut it.

Cheers,
Magnus



>
> Wikidata is not a problem; but it is something that could be leveraged in
> problematic ways (and/or highly beneficial ways).
>
> I feel it is very important that we start looking at these issues from that
> perspective.
>
> -Pete
> [[User:Peteforsyth]]
> ___
> 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>
___
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] Profile of Magnus Manske

2016-01-26 Thread Magnus Manske
Be careful with that "obvious" word...

http://magnusmanske.de/wordpress/?p=378


On Mon, Jan 25, 2016 at 1:56 PM Andreas Kolbe  wrote:

> On Fri, Jan 22, 2016 at 9:34 AM, Magnus Manske <
> magnusman...@googlemail.com>
> wrote:
>
> > What you hear is "Wikidata is unreliable" (compared to the respective
> > Wikipedia; proof, anyone? Please, show me proof; silence or anecdotes
> don't
> > count)
>
>
>
> Any non-trivial content you want to add to Wikipedia today has to fulfil
> one basic criterion: that the content be traceable to a professionally
> published source.
>
> Most Wikidata content fails that criterion.[1] It's blooming obvious that
> Wikidata is "unreliable" according to Wikipedia's definition of a "reliable
> source", isn't it?[2]
>
> [1] https://tools.wmflabs.org/wikidata-todo/stats.php
> [2] https://en.wikipedia.org/w/index.php?title=Wikipedia:SPS
> ___
> 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>
___
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] Profile of Magnus Manske

2016-01-22 Thread Magnus Manske
Ah, I see. I am the problem. Glad we cleared that up.

On Fri, Jan 22, 2016 at 6:56 AM Isarra Yos  wrote:

> You just don't get it, do you? Even from the start this was all about
> social issues with rollouts, and still you are contributing to the very
> same social problems you so blindly condemned.
>
> -I
>
> On 20/01/16 14:16, Magnus Manske wrote:
> > On Wed, Jan 20, 2016 at 12:58 AM Todd Allen 
> wrote:
> >
> >> Once the VisualEditor was fit for purpose and a good deployment strategy
> >> had been developed, the English Wikipedia community overwhelmingly
> >> supported rolling it out. (
> >>
> >>
> https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_125#Gradually_enabling_VisualEditor_for_new_accounts
> >> )
> >>
> > That is for new accounts only. Without an account, still no VE for you,
> > even if you are probably the one needing it most.
> >
> >> It's not Luddism, it's not "resistance to change", it's not "power
> users"
> >> grumpy about newbies having an easier time, it's not anything like that.
> >> It's that in the state it was initially released in, the thing did not
> >> work.
> >>
> > No one said "Luddism", except to defend against its use. Odd.
> >
> >
> >> So yes, by all means, let's try new things. But try:
> >>
> >> 1: Asking us what we actually want, before coding something up and
> feeling
> >> obligated to push it out. People are a lot more receptive to something
> they
> >> asked for than something being forced upon them. That's been an issue
> with
> >> Flow. It's not that it doesn't work well (though it doesn't), it's that
> it
> >> wasn't wanted to start with. So instead of "Here's the new discussion
> >> system", ask "What can we do to make our system of discussion better?"
> >>
> > Listening to what editors want is important. ONLY listening to wad
> editors
> > want is bad. People often don't know what they want or need, until they
> see
> > it. Compare the famous (possibly misattributed) Henry Ford quote:
> > “If I had asked people what they wanted, they would have said faster
> > horses.”
> >
> > Also, veteran editors do not represent the readers or casual/newbie
> > editors; their needs are often quite different.
> >
> >
> >> 2: Make sure it works. Have an opt-in beta phase. Doesn't have to be
> >> perfect, but certainly make sure it's not breaking page formatting all
> over
> >> the place. You'll notice, for example, that there wasn't really any
> >> resistance to HHVM. It worked well, it was desirable, it was clearly fit
> >> for purpose. So no, there isn't just a reflexive change aversion. Though
> >> the previous missteps and hamfisted followups have, rather ironically,
> >> created a lot of the reflexive change aversion that people said was
> there.
> >>
> > Wrong example. The HHMV switch was a back-end change that should have had
> > no visible effect. As long as the servers are fast, people don't really
> > care what's going on there. Did e.g. English Wikipedia actually vote on
> > HHMV?
> >
> >> 3: Be nice (but NOT condescending or patronizing) if an issue comes up.
> >> "Superprotect" alienated people right quickly, and turned what could
> have
> >> been a productive (if tense) conversation into a war. Same with refusal
> to
> >> budge on VE and the arrogant tone several people took. Yes, some people
> >> might be rude about objecting to the change. Don't sink to their level.
> If
> >> they call the new software a steaming pile, ask "Could you offer more
> >> concrete feedback?"
> >>
> > Superprotect was used to revert an admin action on de.wikipedia, an
> action
> > that might actually fall under U.S. or German computer sabotage laws.
> This
> > was hailed as some heroic action by that vocal group I keep mentioning,
> > when it can easily be seen as someone abusing the privileges given by the
> > Foundation (as owners of the servers) to deactivate functionality put in
> > place by the Foundation.
> > The creation and subsequent use of superprotect was not exactly the most
> > wise decision ever undertaken, but neither was the original sabotage
> > (literally so; using access to a machine to stop it from working, just
> not
> > using a wooden shoe).
> > And while i

Re: [Wikimedia-l] Profile of Magnus Manske

2016-01-22 Thread Magnus Manske
On Thu, Jan 21, 2016 at 11:54 PM Jens Best  wrote:

> I'm not sure where you get your impressions, Magnus. But when I discuss
> ideas for a better implementation of Wikidata into Wikipedia to improve
> automatisation of repetitive editing procedures, including the
> implementation of the possible use of structured data, I rarely hear "It Is
> Not Made Here" or "It's Bad Because Its New".
>

No, of course you don't hear that, because no one wants to sound like that.
What you hear is "Wikidata is unreliable" (compared to the respective
Wikipedia; proof, anyone? Please, show me proof; silence or anecdotes don't
count), which is the "Wikipedia is unreliable" Spiel we heard from
Britannica or Brockhaus. I have a bot that can add and update lists on
Wikis, and it is accused by some of "vandalism", even though it doesn't
edit in the article namespace, and requires a user-made template to do
edits in the first place. Those are the kind of strawman "arguments" made
instead.


> When it comes to analyse the problems with Wikidata it isn't only about
> possible early-lifecycle issues(which can be fix), but about the blind spot
> when it comes to develope working social processes which keep everybody
> (especially the editors) in the picture.
>

People can edit Wikipedia. People can edit Wikidata. With the same account.
Erveryone can have as clear a picture as they want. Few do.

It strikes me that a similar thing was happening to Commons, in the same
"communities". There is still a "don't move your pictures to Commons, they
will be deleted!" meme floating around on German Wikipedia.


>
> Community involvement (especially consultations) are often seem to be
> organized only out of necessity. They not in the middle of the
> decision-making process. Nobody said that doing things the way they are
> done in a crowdsourced, community-driven process are easy, but this is no
> excuse for any Foundation or other similiar entity to set up an
> intransparent, precendents creating process where community becomes
> accessories.
>
> The whole way the Knowledge Engine process was implemented, the whole still
> intransparent incident of kicking a highly valued community-selected person
> out of the WMF board are clear signals that some people already decided
> about the future of Wikimedia and now staging a folksy broad consultation
> circus to create the impression of transparent community involvement. -
> Deciding about the color of the car if you would instead prefer to talk
> about the vehicle is the illusion of community-based decisionmaking.
>

Not sure what's with that "Knowledge Engine" phrase -  looks to me it was
used by the donating party, and made its way into a blog. Anyone know more
details?

And communities don't start new things. Individuals, or small groups of
them, do. I was on the GNU mailing list when, after the Nupedia launch,
they were discussing the creation of a "free encyclopedia". Lots of
high-flying plans, lots of talk. And if WIkipedia hadn't started, they
would still be talking. IIRC they shut up pretty quickly after that.
Sometimes, you just need to throw things at the wall and see what sticks.
And if you wait around for permission of communities, the wall will crumble
to dust before anything happens.

And we are NOT sidetracking to some WMF personell issues in a thread that
has my name on it, please! ;-)


> We need a lot of change in the social procedures at the level of really
> needed ground work which is important for changing the Wikiprojects to make
> them work for the future. To reflect and to work on the development of
> these social procedures would be the most precious work to be done by the
> Foundation. Instead the Foundation dreams of techbubble-driven, humanless
> wonderland full of free floading informations which magically forms into
> knowledge when it somehow hits a human being.
>

Still with the babbling about a "techbubble"? I thought we had moved past
that nonsense.


>
> I like the idea of Wikidata.
> I like the idea of combining Encylopedia with structured data to enable
> understanding and easy re-use at the reader-side of Wikiprojects. So many
> things are imaginable there when the culture of conveying the needed
> individual and social skills are done well. Tech is only tool to these
> processes. Tools are important, but not the purpose when it comes to
> disseminate knowledge.
>

I agree with this entire paragraph 100%. I would like to add, though, that
sometimes, technology opens an unexpected door, even, and especially, when
no one asked for it. Like Jimbo and Larry adding a wiki to the Nupedia
site, just to see what would happen.

Cheers,
Magnus


>
> regards,
> Jens
>

Re: [Wikimedia-l] Profile of Magnus Manske

2016-01-20 Thread Magnus Manske
ng.


>
> 6: Show willingness to budge. "No, we won't do ACTRIAL, period." "You get
> VE, like it or not." "You're getting Mediaviewer even if we have to develop
> a new protection level to cram it down your throats!" That type of
> hamfisted, I'm-right-you're-wrong approach will gear people right up for a
> fight. Fights are bad. Discussions are good. But people don't like to talk
> to a brick wall.
>

Everyone (as in, the vast majority of people I ever spoke to, approaching
100%) agreed that Wikipedia editing, especially for newbies, sucked.
Everyone agreed that what happened when clicking on a file in Wikipedia was
confusing for most readers.
These are not issues the Foundation just made up in some ivory tower; there
was little dispute that something should be done. So the Foundation did,
and switched their solution on, for everyone, because most users are "just"
readers, not editors, and see an actual improvement. Neiter VE nor MV was
perfect in the beginning; neither is now. They just got better over time.
So MV is active for everyone, including IPs, even on German Wikipedia,
right now. Because it's beeter for most people, and it works. Why did it
need to be completely switch off again?


>
> Many of us were asking for a WYSIWYG editor for some time, because we very
> much need a way to reach out to prospective editors who are intimidated by
> wikimarkup or just don't care to learn it. So it wasn't that we were
> opposed to VE in principle. Good idea, bad execution.
>

As someone who has worked on alternative Wikitext parsers, and alternative
interfaces, rest assured that the execution was quite good for an initial
version. As I said before, it is impossible to get this perfect right away.
Just like it is impossible (literally, as in "not possible") to reliably
get the license for an image in MV on all cases. The community/vocal group
needs to show some patience when developers are trying their best to get a
giant project up and running smoothy.

Cheers,
Magnus


>
> On Tue, Jan 19, 2016 at 7:39 AM, Anthony Cole  wrote:
>
> > Magnus, you've missed the point of the visual editor revolt. A couple of
> > people here have tried to explain that to you, politely. And you're
> > persisting with your idée fixe.
> >
> > There were two parts to the visual editor catastrophe, actually. The
> > product wasn't ready for anyone to use. Not veteran editors. Not newbies.
> > Newbies who used it were less likely to successfully complete an edit. It
> > was broken, and the WMF insisted we had to use it.
> >
> > The second part of the problem was arrogance. Yes, a few editors were
> > unnecessarily rude about the product and the developers. But then most of
> > the developers and tech staff who dealt with the community arrogantly
> > characterised *anyone* who complained about the product as an ignorant,
> > selfish Ludite - and you're persisting with that characterisation now.
> >
> > The WMF under Lila has learned the lessons from that, and they have
> > fostered a much healthier relationship between the developers and the
> > community. You clearly haven't learned all you might have.
> >
> > In fact, reading the arrogant responses from you here and in the
> concurrent
> > thread titled "How to disseminate free knowledge," and from Denny in
> > earlier threads addressing criticism of WikiData, it seems to me there is
> > still a significant arrogance problem that needs addressing, at least
> over
> > at WikiData.
> >
> > Some people may approach you arrogantly, maybe even insultingly, about an
> > innovation, and I suppose you might be justified in talking down to them
> or
> > ridiculing them (though I advise against it.). But if you can't
> distinguish
> > them from those who approach you with genuine concerns and well-founded
> > criticisms, then no matter how clever you think your technical solutions
> > are, you will soon find you're no more welcome here than those WMF
> staffers
> > who thought insulting well-meaning critics was a good career move.
> >
> > Denny's contemptuous dismissal of valid criticisms of his project, and
> your
> > contemptuous dismissal of the valid criticisms of the early visual editor
> > and its launch are both very disappointing.
> >
> > Anthony Cole
> >
> >
> > On Tue, Jan 19, 2016 at 7:24 AM, Magnus Manske <
> > magnusman...@googlemail.com>
> > wrote:
> >
> > > The iPhone was a commercial success because it let you do the basic
> > > functions easily and intuitively, and looked shiny at th

Re: [Wikimedia-l] Profile of Magnus Manske

2016-01-19 Thread Magnus Manske
On Tue, Jan 19, 2016 at 3:40 PM Anthony Cole  wrote:

> Magnus, in the interview you said "From the Media Viewer, the Visual
> Editor, to Wikidata transclusion, all have been resisted by vocal groups of
> editors, not because they are a problem, but because they represent change.
> For these editors, the site has worked fine for years; why change
> anything?"
>
> Well, yes. No one here, I'm sure, will argue there aren't such groups.
>
> But the problem with the blog post is you only mention them.


Because they are the problem, and they (by being vocal) often get more
attention than a more silent, sensible majority. But by getting attention,
they shape the general consensus, in a negative way.


> You don't take
> into account the very much larger crowd, including myself, who were hanging
> out for the visual editor and were contemptuously flicked off by the
> developers when we brought up fatal flaws, as just some more
> superconservative no-vision Ludites - haters of change.
>

I am not going to get into a who-said-what-to-whom-in-what-tone discussion
here. I wouldn't be surprised if some developers didn't bother to
differentiate between sensible feedback and nay-sayers. As I have said in
this mail thread, I hope the Foundation has learned how to deal with
feedback more sensibly.


>
> The first version of VE was so bad it was harming our mission. It was far
> worse than "didn't do everything 100% right." It would have been bounced
> back from the community to the developers even if that first group of
> bitter, change-hating autistic ranters hadn't said a word.
>

Consider this perspective: I doubt the developers would have pushed out
that first version if it had massively failed their own tests. But at some
point, you have to leave the test environment, and test your product
against reality. Remember, WMF is not Microsoft, with an army of thousands
of paid beta-testers.

So then it turns out there are more (and more really bad) bugs than
anticipated. Then you go and fix those bugs. Which is what they did. But
turning a major endeavour on and off repeatedly is just a bad thing to do.
AFICT the window where wrong edits were made by VE was not /that/ large.
Apparently, the decision was made to "power through it", rather than flip
the switch repeatedly. That may or may not have been the right strategy.


>
> I notice VE isn't even an option when I log out and edit en.Wikipedia, yet
> above others are saying it is much improved and ready for release. What are
> we waiting for?
>

This is the thing. The atmosphere has been poisoned against VE, which now
makes it much harder to get a good product deployed.

But I agree with the sentiment. What ARE we waiting for?

Cheers,
Magnus


>
>
>
> Anthony Cole
>
>
> On Tue, Jan 19, 2016 at 10:56 PM, Andrew Lih  wrote:
>
> > On Tue, Jan 19, 2016 at 9:39 AM, Anthony Cole 
> wrote:
> >
> > > Magnus, you've missed the point of the visual editor revolt. A couple
> of
> > > people here have tried to explain that to you, politely. And you're
> > > persisting with your idée fixe.
> > >
> >
> > To be fair, Magnus was addressing more than just the initial complaints
> > from 2013. He said, “condemning an entire product forever because the
> first
> > version didn’t do everything 100% right is just plain stupid.”
> > ___
> > 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,
> > 
> >
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Profile of Magnus Manske

2016-01-19 Thread Magnus Manske
Anthony, it does seem you've missed some of which I wrote in this thread. I
have no problem with specific criticism where it is deserved, and I do well
remember that the Visual Editor, in its early incarnation, was not quite up
to the job.

What I do have a problem with is people fixating on some technical or
early-lifecycle issues, declaring the entire thing worthless, even
dangerous, and spreading that view around. This behaviour, I have seen time
and again, with the Media Viewer, with Wikidata.

It's bad because it's broken - let's come together and fix it.

It's bad because ... well, everyone says it's bad. And new. And Not Made
Here. THAT is a problem, and not a technological one.

On Tue, Jan 19, 2016 at 2:39 PM Anthony Cole  wrote:

> Magnus, you've missed the point of the visual editor revolt. A couple of
> people here have tried to explain that to you, politely. And you're
> persisting with your idée fixe.
>
> There were two parts to the visual editor catastrophe, actually. The
> product wasn't ready for anyone to use. Not veteran editors. Not newbies.
> Newbies who used it were less likely to successfully complete an edit. It
> was broken, and the WMF insisted we had to use it.
>
> The second part of the problem was arrogance. Yes, a few editors were
> unnecessarily rude about the product and the developers. But then most of
> the developers and tech staff who dealt with the community arrogantly
> characterised *anyone* who complained about the product as an ignorant,
> selfish Ludite - and you're persisting with that characterisation now.
>
> The WMF under Lila has learned the lessons from that, and they have
> fostered a much healthier relationship between the developers and the
> community. You clearly haven't learned all you might have.
>
> In fact, reading the arrogant responses from you here and in the concurrent
> thread titled "How to disseminate free knowledge," and from Denny in
> earlier threads addressing criticism of WikiData, it seems to me there is
> still a significant arrogance problem that needs addressing, at least over
> at WikiData.
>
> Some people may approach you arrogantly, maybe even insultingly, about an
> innovation, and I suppose you might be justified in talking down to them or
> ridiculing them (though I advise against it.). But if you can't distinguish
> them from those who approach you with genuine concerns and well-founded
> criticisms, then no matter how clever you think your technical solutions
> are, you will soon find you're no more welcome here than those WMF staffers
> who thought insulting well-meaning critics was a good career move.
>
> Denny's contemptuous dismissal of valid criticisms of his project, and your
> contemptuous dismissal of the valid criticisms of the early visual editor
> and its launch are both very disappointing.
>
> Anthony Cole
>
>
> On Tue, Jan 19, 2016 at 7:24 AM, Magnus Manske <
> magnusman...@googlemail.com>
> wrote:
>
> > The iPhone was a commercial success because it let you do the basic
> > functions easily and intuitively, and looked shiny at the same time. We
> do
> > not charge a price; our "win" comes by people using our product. If we
> can
> > present the product in such a way that more people use it, it is a
> success
> > for us.
> >
> > I do stand by my example :-)
> >
> > On Mon, Jan 18, 2016 at 10:37 PM Michael Peel 
> wrote:
> >
> > >
> > > > On 18 Jan 2016, at 22:35, Magnus Manske  >
> > > wrote:
> > > >
> > > > As one can be overly conservative, one can also be overly
> > enthusiastic. I
> > > > would hope the Foundation by now understands better how to handle new
> > > > software releases. Apple here shows the way: Basic functionality, but
> > > > working smoothly first.
> > >
> > > But at a huge cost premium? I'm not sure that's a good example to make
> > > here. :-/
> > >
> > > Thanks,
> > > Mike
> > > ___
> > > 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>
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > New messages to: Wikimedia-l@lists.wikimedia.org
> >

Re: [Wikimedia-l] How to disseminate free knowledge? Was: Profile of Magnus Manske

2016-01-19 Thread Magnus Manske
ter all, when compared to beautiful, hand-illuminated manuscripts?
Out with that new "infotainmental" stuff!


>
> So the debate is not about castle-building, but about how we together
> re-shaping the ship called Wiki(pedia) to sail a daily demanding longterm
> mission and not following every techbubble-trends just because "more is
> better".
>

And this paragraph here proves that you haven't actually read anything I
wrote in the last few days. It also serves as a prefect example for the
self-righteous, get-off-my-lawn, stagnant spirit I criticize. "Following
every techbubble-trends just because 'more is
better'."? What have you been smoking?


> I hope that the upcoming strategic debate is as open as it needs to be.


I also wish for that. Sadly, judging from your previous statements, by
"open as it needs to be" will mean "closed to anything new".

A strategic debate which framework is already decided upon would only
> increase the distance created also by recent events.
>

I, for one, have not decided on any such framework.


>
> I hope this clarifies my POV, and doesn't offend too many people ;-)
>

What a witty and original remark!

Cheers,
Magnus



>
> Best regards,
> Jens Best
>
>
>
> 2016-01-18 21:33 GMT+01:00 Magnus Manske :
>
> > OK, long thread, I'll try to answer in one here...
> >
> > * I've been writing code for over thirty years now, so I'm the first to
> say
> > that technology in not "the" answer to social or structural issues. It
> can,
> > however, mitigate some of those issues, or at least show new ways of
> > dealing with them
> >
> > * New things are not necessarily good just because they are new. What
> seems
> > to be an improvement, especially for a technical mind, can be a huge step
> > backwards for the "general population". On the other hand, projects like
> > the Visual Editor can make work easier for many people, but few of them
> > will realize what a daunting undertaking such a project is. The
> complexity
> > of getting this right is staggering. Expectations of getting it all
> > perfect, all feature-complete, on the initial release, are unrealistic to
> > say the least. And many of the details can not be tested between a few
> > developers; things need to be tested under real-world conditions, and
> > testing means they can break. Feedback about problems with a software
> > release are actually quite welcome, but condemning an entire product
> > forever because the first version didn't do everything 100% right is just
> > plain stupid. If Wikipedia had been judged by such standards in 2001,
> there
> > would be no Wikipedia today, period. Technology improves all the time, be
> > it Visual Editor, Media Viewer, or Wikidata; but in the community, there
> is
> > a sense of "it was bad, it must be still bad", and I have a feeling that
> > this is extended to new projects by default these days.
> >
> > * In summary, what I criticize is that few people ask "how can we make
> this
> > better"; all they ask is "how can we get rid of it". This attitude
> prevents
> > the development of just about any new approach. If the result of a long,
> > thorough analysis is "it's bad, and it can't possibly be made better",
> > /then/ is the time to scrap it, but no sooner.
> >
> > * Of course, "the community" is an ill-defined construct to begin with.
> > When I use that phrase above, I do mean a small but prominent subgroup in
> > that demographic, mostly "old hands" of good editors, often with a "fan
> > club" of people repeating the opinions of the former on talk pages,
> without
> > really investigating on their own. After all, they are good editors, so
> > they must know what they are talking about, right?
> >
> > * As I tried to say in the interview, I do understand such a conservative
> > approach all to well. We worked hard for Wikipedia to get where it is
> now,
> > and with trolls, on the left, vandals on the right, and half-done tech
> > experiments in front, retreating into the safety of the castle seems
> like a
> > good choice. And sometimes it is. But while we can defend the castle
> > comfortably for some years to come, we will never grow beyond its walls.
> I
> > think we are already seeing the first fallout from this stagnation, in
> > terms of dropping page views (not to mention editors). If people stop
> > coming to a Wikipedia with 5 million articles, 10 million articles would
> > not make much difference by 

Re: [Wikimedia-l] Profile of Magnus Manske

2016-01-18 Thread Magnus Manske
The iPhone was a commercial success because it let you do the basic
functions easily and intuitively, and looked shiny at the same time. We do
not charge a price; our "win" comes by people using our product. If we can
present the product in such a way that more people use it, it is a success
for us.

I do stand by my example :-)

On Mon, Jan 18, 2016 at 10:37 PM Michael Peel  wrote:

>
> > On 18 Jan 2016, at 22:35, Magnus Manske 
> wrote:
> >
> > As one can be overly conservative, one can also be overly enthusiastic. I
> > would hope the Foundation by now understands better how to handle new
> > software releases. Apple here shows the way: Basic functionality, but
> > working smoothly first.
>
> But at a huge cost premium? I'm not sure that's a good example to make
> here. :-/
>
> Thanks,
> Mike
> ___
> 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>
___
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] Profile of Magnus Manske

2016-01-18 Thread Magnus Manske
As one can be overly conservative, one can also be overly enthusiastic. I
would hope the Foundation by now understands better how to handle new
software releases. Apple here shows the way: Basic functionality, but
working smoothly first. That said, problems are to be expected, and a new
Wikitext parser-and-back, plus new interface, were bound to produce some
broken edits.

On Mon, Jan 18, 2016 at 9:46 PM David Gerard  wrote:

> On 18 January 2016 at 20:33, Magnus Manske 
> wrote:
>
> > * New things are not necessarily good just because they are new. What
> seems
> > to be an improvement, especially for a technical mind, can be a huge step
> > backwards for the "general population". On the other hand, projects like
> > the Visual Editor can make work easier for many people, but few of them
> > will realize what a daunting undertaking such a project is. The
> complexity
>
>
> As a huge VE advocate, I was quite disconcerted how hard the WMF was
> trying to force through what was clearly an early beta in need of
> real-world testing as if it were a production-ready product; I think
> this was the problem and the reason for the backlash. VE *now* has had
> a couple of years' development in a real-world environment and is
> really quite excellent (and the only sensible way to edit tables). But
> the problem here was not fear of change or fear of technology, but
> rejecting technology that was being forced on editors when it was
> really obviously not up to the job as yet.
>
>
> - d.
>
> ___
> 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>
___
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] Profile of Magnus Manske

2016-01-18 Thread Magnus Manske
OK, long thread, I'll try to answer in one here...

* I've been writing code for over thirty years now, so I'm the first to say
that technology in not "the" answer to social or structural issues. It can,
however, mitigate some of those issues, or at least show new ways of
dealing with them

* New things are not necessarily good just because they are new. What seems
to be an improvement, especially for a technical mind, can be a huge step
backwards for the "general population". On the other hand, projects like
the Visual Editor can make work easier for many people, but few of them
will realize what a daunting undertaking such a project is. The complexity
of getting this right is staggering. Expectations of getting it all
perfect, all feature-complete, on the initial release, are unrealistic to
say the least. And many of the details can not be tested between a few
developers; things need to be tested under real-world conditions, and
testing means they can break. Feedback about problems with a software
release are actually quite welcome, but condemning an entire product
forever because the first version didn't do everything 100% right is just
plain stupid. If Wikipedia had been judged by such standards in 2001, there
would be no Wikipedia today, period. Technology improves all the time, be
it Visual Editor, Media Viewer, or Wikidata; but in the community, there is
a sense of "it was bad, it must be still bad", and I have a feeling that
this is extended to new projects by default these days.

* In summary, what I criticize is that few people ask "how can we make this
better"; all they ask is "how can we get rid of it". This attitude prevents
the development of just about any new approach. If the result of a long,
thorough analysis is "it's bad, and it can't possibly be made better",
/then/ is the time to scrap it, but no sooner.

* Of course, "the community" is an ill-defined construct to begin with.
When I use that phrase above, I do mean a small but prominent subgroup in
that demographic, mostly "old hands" of good editors, often with a "fan
club" of people repeating the opinions of the former on talk pages, without
really investigating on their own. After all, they are good editors, so
they must know what they are talking about, right?

* As I tried to say in the interview, I do understand such a conservative
approach all to well. We worked hard for Wikipedia to get where it is now,
and with trolls, on the left, vandals on the right, and half-done tech
experiments in front, retreating into the safety of the castle seems like a
good choice. And sometimes it is. But while we can defend the castle
comfortably for some years to come, we will never grow beyond its walls. I
think we are already seeing the first fallout from this stagnation, in
terms of dropping page views (not to mention editors). If people stop
coming to a Wikipedia with 5 million articles, 10 million articles would
not make much difference by themselves; more content is good, but it will
not turn this supertanker around on its own. We do have some time left to
change things, without undue haste, but we won't have forever.

* Just to make sure, I am NOT saying to throw away all the things that have
proven to work for us; I'm just saying we shouldn't restrict us to them.

* As for this "Wikidata is killing Wikipedia" sentiment - bullshit. (I
would like to be more eloquent here, but for once, this is the perfect
word.) Wikipedia and Wikidata are two very different beasts, though they do
have an overlap. And that overlap should be used on Wikipedia, where it can
help, even in the gigantic English Wikipedia, which covers but a third of
Wikidata items. Transcluded data in infoboxes; automatically generated
lists; a data source for timelines. Those are functions that will improve
Wikipedia, and will help especially the hundreds of smaller language
editions that are just getting towards critical mass. And there,
automatically generated descriptions can help get to that mass, until
someone writes an actual article in that language.

* So Google is using Wikidata in their search results? Good! In case you
have forgotten, our mission is not to have a nice article about your pet
topic, or have humans write articles that are little better than
bot-generated stubs, or have your name in ten thousand article histories;
the mission is the dissemination of free knowledge. And the more third
parties use the knowledge we assemble, even (or especially!) if it is that
other 800 pound gorilla on the web, the better we fulfil that mission.

I hope this clarifies my POV, and doesn't offend too many people ;-)

On Mon, Jan 18, 2016 at 7:10 PM Andrew Lih  wrote:

> I cannot speak for Magnus, but there’s a distinction that needs to be made:
>
> Writing, “… all have been resisted by vocal groups of editors, not because
> they are a problem, but because they represent change” is not maligning all
> editors who complain.
>
> It simply says that those who resist innovation be

Re: [Wikimedia-l] Monetizing Wikimedia APIs

2016-01-16 Thread Magnus Manske
On Sat, Jan 16, 2016 at 4:09 PM MZMcBride  wrote:

> Pete Forsyth wrote:
> >Lisa presented some alternative strategies for revenue needs for the
> >Foundation, including the possibility of charging for premium access to
> >the services and APIs, expanding major donor and foundation fundraising,
> >providing specific services for a fee, or limiting the Wikimedia
> >Foundation's growth. The Board emphasized the importance of keeping free
> >access to the existing APIs and services, keeping operational growth in
> >line with the organization's effectiveness, providing room for innovation
> >in the Foundation's activities, and other potential fundraising
> >strategies.
>
> This reminds me of the Wikimedia update feed service:
> . The
> Wikimedia Foundation basically allowed large search engines to access a
> private faster and dedicated stream of recent changes to Wikimedia wikis
> for a fee. While Google isn't mentioned on the Meta-Wiki page, I have a
> vague memory that they were (and maybe still are) involved.
>

I believe it was Yahoo. They were allowing us to use some of their servers
in Asia back in the day, and I believe they also paid for large-scale
access. There was even a special dump with the article start sections for
them.


> Somewhat related, there is also search.wikimedia.org:
> . This service
> was designed to give Apple a fast and dedicated stream for title prefix
> searches. Apple's built-in Dictionary application has been the primary
> consumer of this feed, though I believe it's open to anyone.
>
> MZMcBride
>
>
>
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Next step in the development

2015-10-29 Thread Magnus Manske
I think it might just be a question of phrasing, actually.

"Check if your new topic already exists in other languages, and connect it
to those!
Or [click here] to start a new Wikidata item for your article, so other
language editions of Wikipedia can find it more easily!"

For Wikipedians, the purpose of Wikidata is not "because Wikidata". It is
added value to their own work; language links are an important part of this.

On Thu, Oct 29, 2015 at 10:33 PM Leila Zia  wrote:

> Hi Risker,
>
> On Thu, Oct 29, 2015 at 1:20 PM, Risker  wrote:
>
> > We do not expect anyone to add information to any other
> > project when they create content on the project of their choice.
>
>
> I'm thinking the Insert Media option in VE: there, we are giving the editor
> the option to upload Media to the article which in reality means uploading
> Media to Commons if I'm not missing something. The workflow is very smooth,
> and the Wikipedia editor does not need to know about Commons to follow the
> flow.
>
> Leila
>
>
> > On 29 October 2015 at 16:08, Romaine Wiki 
> wrote:
> >
> > > That is comparing it with wrong examples that are not relevant here.
> > > On Wikipedia we have the guideline that articles an categories should
> be
> > > added to Wikidata, that originates back to the phase that only manual
> > > interwikis existed.
> > >
> > > And we have already received complaints why users do not get a message
> > > after they created a category/article to add it to Wikidata.
> > >
> > > Further I propose this only for (logged in) users, and perhaps further
> > > settings are possible.
> > >
> > > At the moment the largest workload is coming from articles that are not
> > > added to Wikidata. Some users produce five articles a day, all not
> added
> > to
> > > Wikidata, while the articles are fine. In two days we have about 100
> new
> > > articles on nl-wiki, all not added to Wikidata. This is just one wiki,
> > and
> > > a huge workload to get them added properly.
> > >
> > > Romaine
> > >
> > >
> > > 2015-10-29 20:46 GMT+01:00 Risker :
> > >
> > > > Whatever happened to "Wikipedia, the encyclopedia anyone can edit"?
> > > >
> > > > This is adding a layer of complexity and expectation that I don't
> > really
> > > > feel comfortable with.  We don't expect people to add images to
> Commons
> > > > when they write an article.  We don't expect people to include
> > > definitions
> > > > in Wiktionary when they are using a word.  We don't expect people to
> be
> > > > adding material to Wikisource or add quotes to Wikiquote.  For that
> > > matter,
> > > > we don't expect people to write Wikipedia articles about what they
> > review
> > > > on wikisource, or about images they add to Commons, or quotes they
> add
> > to
> > > > Wikiquote.  So why would we set up any kind of expectation that
> people
> > > > would add "data" to Wikidata?
> > > >
> > > > I also am concerned that people will add a new article that, bluntly
> > put,
> > > > isn't going to last more than an hour...get these messages, and add
> > junk
> > > > data to Wikidata.  Wikidatians are working hard to add referencing
> and
> > > > improve what is there already, but it's a huge labour and we
> shouldn't
> > be
> > > > adding to their mountain of work unnecessarily.
> > > >
> > > > Risker/Anne
> > > >
> > > > On 29 October 2015 at 14:37, Romaine Wiki 
> > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I think it is time for the next step in the Wikidata development: a
> > > > better
> > > > > integration in Wikipedia and her sisterprojects.
> > > > >
> > > > > Every day thousands of articles are created, and many of those are
> > not
> > > > > added to Wikidata, even while often an item about this subject
> > exists.
> > > > > Users forget to add a newly created article to Wikidata as there is
> > no
> > > > > stimulus at all. The next step in Wikidata development is that
> after
> > > the
> > > > > creation of an article, users get a message (pop-up, or screen,
> etc)
> > in
> > > > > what they are asked to add the article/category to Wikidata. In the
> > > first
> > > > > stage this can be just a pop-up with a message. But it would be
> > better
> > > if
> > > > > this can be a message + some help to do this, so that users can
> stay
> > in
> > > > > Wikipedia (or another project), without having to go to Wikidata.
> > > > >
> > > > > A further step that can be developed after is the suggestion of
> > > > properties
> > > > > (if missing), like instance of, and based on this entry further
> > > > properties.
> > > > >
> > > > > This will make sure that there is a better integration of Wikipedia
> > and
> > > > her
> > > > > sister projects with Wikidata through this workflow.
> > > > >
> > > > > For this I created a Phabricator task at:
> > > > > https://phabricator.wikimedia.org/T117070
> > > > >
> > > > > Thanks!
> > > > > Romaine
> > > > > ___
> > > > > Wikimedia-l mailing list, guidelines at:
> > > > > http

Re: [Wikimedia-l] Does openly declaring your gender change the probability of having an upload overwritten?

2015-08-14 Thread Magnus Manske
Looking at "male-female" and "female-male", and considering the much-cited
15% female editor ratio, it seems women are much more overwrite-happy than
men.

Then again, 139:110 are not exactly numbers one does want to base
statistics on...

On Fri, Aug 14, 2015 at 9:25 AM Tomasz Ganicz  wrote:

> 2015-08-14 2:20 GMT+02:00 Fæ :
>
> > 15716
>
>
> First of all it seems that vast majority of Commons users do not select
> their gender so they are "none". It obviously spoils the rest of the
> statistics. Would be good to add to it numbers of males, females and
> "nones" included, so it would be more clear which group has generally
> stronger tendency for overwriting.  For example strong "overwriter" can
> make a 1000 overwrites a year, and a weak one just 1. Such "strong"
> overwrites can also spoil this statistics. For example - one "strong"
> female overwrite can easily make all overwrites and the rest of females are
> not overwriting at all :-) The same apply the other way - i.e. we can say
> that women are more vulnerable to be overwriten if you divide numbers of
> overwrites by number of females and compare it to the other groups.
>
>
> --
> Tomek "Polimerek" Ganicz
> http://pl.wikimedia.org/wiki/User:Polimerek
> http://www.ganicz.pl/poli/
> http://www.cbmm.lodz.pl/work.php?id=29&title=tomasz-ganicz
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Superprotect's first birthday

2015-08-11 Thread Magnus Manske
So maybe it could stay, as a "technical office action" mechanism, if future
usage is clearly defined and accepted by "the community" (TM)?

Not advocating either way here...

On Tue, Aug 11, 2015 at 8:13 PM Dariusz Jemielniak 
wrote:

> On Tue, Aug 11, 2015 at 8:36 PM, John Lewis 
> wrote:
>
> >
> > Yes. It was used a few months ago to prevent editing the Germany item on
> > Wikidata due to a very serious breaking issue. Also on several pages
> > following legal disputes.
> >
> > Superprotect in my opinion if used correctly is an essential tool which
> can
> > prevent legal and technical issues that can in theory cause wide
> > disruption.
> >
> >
> In my private opinion the technical part of Superprotect has a potential to
> be useful, it is the social background (who approves its use, how it can be
> used, etc.) that matters and that is the bone of contention (and justified
> concerns). I have a hope that we will have it resolved before the next
> anniversary or earlier :)
>
> best,
>
> dariusz "pundit"
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Superprotect's first birthday

2015-08-11 Thread Magnus Manske
Out of curiosity, was it ever used again after that initial action?

On Tue, Aug 11, 2015 at 6:13 PM Laurentius 
wrote:

> Il giorno mer, 12/08/2015 alle 01.11 +0900, Hong, Yongmin ha scritto:
> > It has been a year (and a day) since the gerrit 153302 [1] has been
> > merged
> > and deployed to the dewiki.
>
> And it's high time it got removed.
>
> Laurentius
>
>
>
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] A transition and a new chapter.

2015-04-13 Thread Magnus Manske
Erik, it's been quite a ride. Wikimedia wouldn't be where it is without you.

Good luck and success in your next endeavour!

On Mon, Apr 13, 2015 at 7:27 PM Brion Vibber  wrote:

> It's been a long journey -- I remember that 2007 office well, and the crazy
> times before even that. :)
>
> Best of luck on what's next!
>
> -- brion
> On Apr 13, 2015 11:12 AM, "Erik Moeller"  wrote:
>
> > Hi all --
> >
> > As Lila noted, since January 2008 I've worn many hats at the Wikimedia
> > Foundation, and in the six years before that I was a Wikipedian,
> > MediaWiki developer, and member of the WMF board of trustees. I became
> > involved in Wikipedia when I was 22 years old. :) The Wikimedia
> > movement has accomplished amazing things, but I believe it's time now
> > for me to do something different and new.
> >
> > It's been a long and incredible journey, and one I am privileged to
> > have helped to shape. When I joined the Foundation in December 2007 we
> > were a staff of a dozen people, with barely enough funds to keep the
> > lights on. Since then, we've tackled challenges of a complexity and
> > scale faced by few other organisations. In doing so, we’ve been
> > generously supported by people all over the world who are grateful for
> > the gift of free knowledge.
> >
> > I’m proud of and happy with what we've achieved. Reaching people on
> > mobile. Pioneering new approaches working with universities.
> > Painstakingly building a visual editing experience on top of wikitext.
> > :) I’m glad we’ve taken a stand when it matters (SOPA blackout, NSA
> > lawsuit) and that we don’t shy away from complex issues such as
> > community health and diversity.
> >
> > I’m excited that Wikidata is growing in leaps and bounds with the help
> > of Wikimedia Germany, and that more and more powerful tools and
> > services are being built on the basis of Wikimedia APIs and data. I’ve
> > always believed that Wikimedia chapter and affiliate organizations are
> > key to the success of the movement, and I hope they are going to truly
> > thrive in years to come.
> >
> > But it's time. As the leadership team begins to coalesce under Lila, I
> > want to open up space for the organization to learn and explore anew
> > -- and I’d like to rediscover for myself what it means to tackle
> > challenges outside of my areas of comfort and familiarity.
> >
> > I’m very interested in the technical challenges of federated
> > collaboration, and am looking forward to getting my hands dirty in
> > that domain. I also want to explore how to make patterns of ethics,
> > policy, and self-governance more accessible and re-usable for
> > communities. In short, I’m itching to immerse myself in new problem
> > spaces and new ideas.
> >
> > Lila, Damon, Terry, myself and others in the org have been discussing
> > how to organize product going forward to set the org up for success in
> > the years to come, and we’ll have an update on that very soon. This is
> > a very natural point for me to pursue something new.
> >
> > What Wikimedia does in the world is wonderful & important. I’m sure I
> > will continue to cross paths with many of you in future as I continue
> > to move in free culture circles, and I very much look forward to it.
> >
> > I’ll continue to be @ WMF full-time through April, and will make
> > myself available as necessary afterwards, for when the org needs human
> > institutional memory that surpasses digital archives. I wish you all
> > success and joy :-)
> >
> > Love,
> >
> > Erik
> > --
> > Erik Möller
> > VP of Product & Strategy, Wikimedia Foundation
> >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> ___
> 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,
> 
___
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, 


Re: [Wikimedia-l] Android "Nearby" Feature (was: Re: Community RfCs about MediaViewer)

2014-10-15 Thread Magnus Manske
Hah! Of course, I pick the same day to rewrite WikiShootMe...

https://tools.wmflabs.org/wikishootme/

On Wed, Oct 15, 2014 at 1:27 AM, Erik Moeller  wrote:

> On Tue, Aug 5, 2014 at 7:28 PM, Andy Mabbett 
> wrote:
> > An answer would be appreciated...
>
> I know you've been in touch w/ the mobile web team since this thread,
> but just to close the loop for the record: "Nearby" (now
> re-implemented in native code and with a new UI) is part of today's
> stable release of the Android app.
>
> https://lists.wikimedia.org/pipermail/mobile-l/2014-October/008144.html
>
> Please join the mobile list for feedback, questions & suggestions.
>
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
> Cheers,
> Erik
> --
> Erik Möller
> VP of Product & Strategy, Wikimedia Foundation
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
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, 


Re: [Wikimedia-l] To Flow or not to Flow

2014-09-06 Thread Magnus Manske
On Sat, Sep 6, 2014 at 9:50 AM, Fæ  wrote:

> On 6 September 2014 07:11, Gerard Meijssen 
> wrote:
> > Hoi,
> > "We" includes anyone who wants to be involved and does not exclude him or
> > herself by his or her own actions or choices.
> > Thanks,
> > GerardM
>
> Incorrect.
>
> Erik's email includes phrases like "We're not pushing an aggressive
> schedule on Flow". This clearly means that "we" refers to the
> Wikimedia Foundation and excludes unpaid volunteers who hold no
> responsibility or authority for the deployment schedule.
>

Incorrect.

In such a long text, "we" can obviously refer to both "the Foundation" and
"the community" (both of which Erik is a member of), depending on context.
There would be little point in Erik asking "Do we want discussions to occur
in document mode, or in a structured comment mode?" on a public mailing
list, when he just wants to ask a Foundation-internal question, right?
Pretty obvious, really, unless your goal is to distract from the actual
topic.
___
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, 


Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Magnus Manske
Or, have them filled from Wikidata. Then, {{Infobox}} would be all the
wikitext you need. This could also help to "abstract" infoboxes to load a
placeholder/hint on mobile, then loading the box on request (click).

Well, one can dream...

Magnus


On Thu, Aug 21, 2014 at 6:45 PM, Andy Mabbett 
wrote:

> On 21 August 2014 17:08, Isarra Yos  wrote:
>
> > Man, I forgot how over the top some projects get
> > with their navigation templates.
>
> Perhaps the answer is to refactor them as separate pages to which
> mobile (and even desktop) pages can use a single link?
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
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, 


Re: [Wikimedia-l] [Wikidata-l] Compare person data

2014-08-20 Thread Magnus Manske
Thanks for this.

You might want to filter it, though: For example
https://www.wikidata.org/wiki/Q85256 states "born in 1606" (no month or day
given), but your report at
https://www.wikidata.org/wiki/User:Ladsgroup/Birth_date_report2/26 gives it
as 1606-01-01, which then conflicts with the date given in Wikipedias
(1606-03-18).

Wikidata is less precise than Wikipedia here, but not actually wrong. Maybe
these cases should be treated separately from the potential errors.

Cheers,
Magnus


On Wed, Aug 20, 2014 at 3:54 PM, Amir Ladsgroup  wrote:

> I started this report, you can find it here
> .
>
> Best
>
>
> On Tue, Aug 19, 2014 at 3:27 PM, Amir Ladsgroup 
> wrote:
>
>> It's possible and rather easy to add them  .just several regexes and list
>> of months in that language are needed. but the issue is no major wikis
>> except these three are using a person data template (Almost all of them
>> have the template but almost none of them are using it widely) If any other
>> wiki is using a person data template widely, I would be happy to implement
>> it.
>>
>> Best
>>
>>
>> On Tue, Aug 19, 2014 at 2:29 PM, Amir E. Aharoni <
>> amir.ahar...@mail.huji.ac.il> wrote:
>>
>>> Can we join more Wikipedias to the comparison?
>>>
>>>
>>> --
>>> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
>>> http://aharoni.wordpress.com
>>> ‪“We're living in pieces,
>>> I want to live in peace.” – T. Moore‬
>>>
>>>
>>> 2014-08-19 10:38 GMT+03:00 Gerard Meijssen :
>>>
  Hoi,
 Amir has created functionality that compares data from en.wp de.wp and
 it.wp. It is data about "humans" and it only shows differences where
 they
 exist. It compares those four Wikipedias with information in Wikidata.

 The idea is that the report will be updated regularly.

 The problem we face is: what should it actually look like. Should it
 just
 splatter the info on a page or is more needed. At this time we just have
 data [1].

 Please help us with something that works easily for now. Once we have
 something, it can be prettified and more functional.
 Thanks,
  GerardM

 [1] http://paste.ubuntu.com/8079742/
 ___
 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,
 
>>>
>>>
>>>
>>
>>
>> --
>> Amir
>>
>>
>
>
> --
> Amir
>
>
> ___
> Wikidata-l mailing list
> wikidat...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Compare person data

2014-08-19 Thread Magnus Manske
IMHO a simple table, maybe even a wikitable, would suffice for the initial
iteration. We can get much more fancy later.

Of course, if Infoboxes/Persondata on these Wikipedias were to use some Lua
magic, biographies with e.g. mismatching birthdates could automatically be
added to a maintenance category...

Cheers,
Magnus


On Tue, Aug 19, 2014 at 11:18 AM, Gerard Meijssen  wrote:

> HoI,
> You are absolutely right.. What is needed is a report that looks good
> enough for now and a public ie visible place to put it.
> Thanks,
>  GerardM
>
>
> On 19 August 2014 12:13, Joe Decker  wrote:
>
> > Pretty sure those are just the :first: 38... Note the q numbers.  (They
> > are ascending and don't make to q5000.)
> >
> > That suggests the full list will be very large indeed.
> >
> > Joe
> >
> > www.joedecker.net
> >
> > > On Aug 19, 2014, at 2:49, Cristian Consonni 
> > wrote:
> > >
> > > Hi Amir,
> > >
> > > 2014-08-19 10:38 GMT+02:00 Amir Ladsgroup :
> > >> It's three now but the way I designed, it's very easy to extend.
> > >
> > > Thanks for this report. I am amazed that over the hundreds of
> > > thousands of Wikipedia biographies[*] it seems that we have only 38
> > > inconsistencies.
> > > Am I understanding your report correctly?
> > >
> > > You may want to add some sort of "false positives" list. For example,
> > > for Jimmy Wales in it.wp[1] there's a through explanation about the
> > > uncertainty related to Jimbo's birth date. So I would consider that
> > > being a false positive. A similar situation occurs for Beethoven.
> > >
> > > That said I was able to find that Bob Marley's birth date in Wikidata
> > > was incorrectly set to 6 April 1945, when in fact it is indeed 6
> > > February 1945 as en.wp, de.wp, and it.wp where correctly reporting.
> > > (Fixed[2] now!)
> > >
> > > Thanks!
> > >
> > > Cristian
> > >
> > > [*] 265537 in it.wiki: https://it.wikipedia.org/wiki/Categoria:BioBot
> > > [1] https://it.wikipedia.org/wiki/Jimmy_Wales
> > > [2]
> >
> https://www.wikidata.org/w/index.php?title=Q409&diff=151644019&oldid=151167823
> > >
> > > ___
> > > 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,
> > 
> >
> > ___
> > 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,
> > 
> >
> ___
> 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,
> 
>
___
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, 


Re: [Wikimedia-l] how global.js works? (was: Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you)

2014-08-14 Thread Magnus Manske
Ah, I believe when the Italian (?) Wikipedia started using my JS-based
also-search-on-wikidata tool. A dependency JS file was hosted on Tools
Labs, effectively DDOSing it to a halt. Moved file to en.wp, cache can
handle it easily now.

So, not technically a Wikipedia server, but a Wikimedia server with
lots'o'tools got unresponsive for a while. Last one I can think of.

Cheers,
Magnus


On Thu, Aug 14, 2014 at 7:55 AM, John Mark Vandenberg 
wrote:

> On Thu, Aug 14, 2014 at 1:41 PM, Gerard Meijssen
>  wrote:
> > Hoi,
> > The big question is not so much where and when things happen, the big
> > question is who supports all the muck. There have been enough instances
> > where changes to for instance common.js brought down servers.
>
> Out of interest, when was the last time that a common.js change
> brought down the servers?
>
> --
> John Vandenberg
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
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, 


Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

2014-08-13 Thread Magnus Manske
On Wed, Aug 13, 2014 at 6:20 PM, rupert THURNER 
wrote:

> Am 13.08.2014 15:56 schrieb "Magnus Manske" :
> >
> > On Wed, Aug 13, 2014 at 6:51 AM, rupert THURNER <
> rupert.thur...@gmail.com>
> > wrote:
> >
> > > On Tue, Aug 12, 2014 at 6:26 PM, Erik Moeller 
> wrote:
> > > > On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske
> > > >  wrote:
>
> > > >> It's probably fine for "modern" viewing, although it's hard to guess
> > > that
> > > >> you get to the file page via the little Commons icon for people who
> (in
> > > all
> > > >> likelihood) have never seen that icon, or visited Commons.
> > >
> > > > Indeed, the icon to the File: page is currently very opaque. We're
> > > > preparing for a round of possible changes to the viewing experience,
> > > > potentially including
> > > > - moving caption above the fold so readers don't have to hunt for it
> > > > - moving disable action above-the-fold
> > > > - potentially eliminating the below-the-fold panel entirely
> > > > - emphasizing the File: page more prominently as the canonical source
> > > > of metadata
> > > > - separating out download/use actions more clearly
> > > >
> > > > These changes will need to be carefully tested/validated. If you want
> > > > to take a look at an early early (!) prototype (!!), see
> > > > http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please
> > >
> > > magnus, do these changes make you turn it on again? if not, what would
> need
> > > to be better?
> > >
> >
> > I think this is a non-issue. It took one click to get to the image page;
> > now it takes two. That's my main "problem" with it.
> > As I said, I'm not the target audience for this. I hope.
>
> to give back the one click experience one would need two entry points. a
> tab or a toolbox link to start mediaviewer, and standard behavior on the
> images. for one link more in the gui everybody would be happy?
>

Thanks for trying, but I wouldn't like to have some "click confusion" to be
added on my part. This is not really the issue that's being discussed here.
Some people felt that MediaViewer is too buggy to be default right now. WMF
disagreed. Disagreement escalated. This needs to calm down again. A quick
single-point tech fix won't make it go away, I'm afraid.

To be clear, I did not vote in the Meinungsbild, because I have no strong
feeling about the MediaViewer one way or the other.

Cheers,
Magnus
___
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

2014-08-13 Thread Magnus Manske
On Wed, Aug 13, 2014 at 6:51 AM, rupert THURNER 
wrote:

> On Tue, Aug 12, 2014 at 6:26 PM, Erik Moeller  wrote:
> > On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske
> >  wrote:
>
> >> Like many other "old hands", it seems to get in the way of my workflow.
> Not
> >> an issue for me, as long as I can turn it off.
>
> hehe, i suppose investing a million $$ to get you turning it off because
> it is
> in your way is probably not the goal :)
>

Well, for a million $$ MediaViewer would be slightly overpriced ;-)



>
> >> It's probably fine for "modern" viewing, although it's hard to guess
> that
> >> you get to the file page via the little Commons icon for people who (in
> all
> >> likelihood) have never seen that icon, or visited Commons.
>
> > Indeed, the icon to the File: page is currently very opaque. We're
> > preparing for a round of possible changes to the viewing experience,
> > potentially including
> > - moving caption above the fold so readers don't have to hunt for it
> > - moving disable action above-the-fold
> > - potentially eliminating the below-the-fold panel entirely
> > - emphasizing the File: page more prominently as the canonical source
> > of metadata
> > - separating out download/use actions more clearly
> >
> > These changes will need to be carefully tested/validated. If you want
> > to take a look at an early early (!) prototype (!!), see
> > http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please
>
> magnus, do these changes make you turn it on again? if not, what would need
> to be better?
>

I think this is a non-issue. It took one click to get to the image page;
now it takes two. That's my main "problem" with it.
As I said, I'm not the target audience for this. I hope.


>
> i think there is two kinds of feedback. (1) technical / feature / workflow
> issues. like "i cannot tag easy", "esc leaves mediaviewer instead of
> fullscreen", "browser zoom (ctrl-/+) does not work". "X takes one click
> more now". i d love this to be taken into account.
>
> while i find design issues more difficult. the whole user experience
> needs, at least imo, consistency. tinkering here and there
> may quite heavily break that. better would be to encourage
> getting alternative full designs. if this would include how to
> clean the commons page ... but that might be too much :)
>
> rupert
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

2014-08-12 Thread Magnus Manske
On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann 
wrote:

> On 12.08.2014 16:57, Magnus Manske wrote:
> > German Wikipedia had 1.1 billion page views in June [1]. ~300 votes (~2/3
> > against MediaViewer) do not represent the readers, IMHO.
>
> Claiming to speak for a perceived silent majority will not help you much
> in this discussion.
>

I do not make any such claim. All I say is that the 300 (is there a movie
plot here?) do not necessarily speak for it, either.


>
> There is a common pattern in the conflicts between WMF and several
> communities over software developments during the last few years. As I
> wrote two weeks ago to Rachel:
>
> | Decision making seems to be focused on reader experience, including
> | winning readers to become authors, but existing authors and their
> | experience (in both meanings of the word) is ignored. Even by people |
> like Eric, who once was a prolific author himself
>
> | Authors see themselves as the single most important group in the
> |Wikimedia universe. Without their content, there would be nothing: No
> | readers, no fundraising banners, no donations, no employees, no
> | foundation. On the other hand, WMF seems to see the readers (and
> | donors) as their main target audience. Of course WMF knows, that all
> | the projects need content and authors, but in my opinion most of them
> | fail in appreciating the existing authors and focus too much on
> | winning readers to become authors, by simplifying the entry.
>
> This is serious. WMF really needs to appreciate the expertise of the
> author community and accept their experience a important and valid. If
> authors tell the WMF and particularly the devs, that a particular
> function is necessary, then the devs really, really need to think.
>

I do agree with this. Visual Editor (which works much better these days)
and MediaViewer are not aimed at the experienced editor. They aim to make
the reader more comfortable, and try to ease the first steps into editing.
Winning new editors has been deemed a priority, somewhat at the expense of
WMF-made support for the power user. This is a judgement call the
Foundation has to make.


>
> If the community tells the devs, that a particular idea is a bad one, a
> feature is too buggy to be rolled out (as default) or is unsuitable for
> a project at all, this warrants more than just a cursory thought.
>
> A formal RfD must not be taken lightly, overruling it by creating a
> whole new user class, and crippling the elected admins is inpermissible.
> WMF has broken trust again and this time in a unprecedented way.
>

As Erik pointed out, WMF had made it quite clear that they reserve the
right to overrule the community in that specific matter, before the
Meinungsbild was done. WMF then acted as announced, and refused to be
"hacked" out of their own servers. An unfortunate escalation on both sides,
but since they never promised to accept the Meinungsbild (quite the
opposite!), it was not a breach of trust.


>
> Until this event, I thought the dev process to be broken, not just the
> communication around devs. But now I believe the conflict runs deeper.
>

It points out an issue we (community and WMF) should discuss, in a more
general sense. What should the decision process be for technical changes?
When does the Foundation get precendence, and when should the community
have the last word? What weight should small-scale "votes" of editors have?
Should random polls be done, and included in such votes? Etc.

The MediaViewer "affair" itself gets blown out of proportion IMO.


Cheers,
Magnus
___
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

2014-08-12 Thread Magnus Manske
On Tue, Aug 12, 2014 at 5:26 PM, Erik Moeller  wrote:

>
>
> These changes will need to be carefully tested/validated. If you want
> to take a look at an early early (!) prototype (!!), see
> http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please
> note that anything but the basic view experience is placeholder right
> now (as is the "Details" icon etc.), and the caption-above-the-fold is
> not implemented yet. We've looked at some of this with folks at
> Wikimania, and the community feedback there was very positive. But
> like I said, give us a bit more time on this.
>

This looks much better! (though it appears to have problems with PNGs...)


>
> In answer to your query regarding how we communicated about this,
> please note that we posted the following at the beginning of the poll:
>
> https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbilder/Medienbetrachter&diff=prev&oldid=132469014
>
>
Thanks Erik, I somehow missed this. It is indeed ample notification.

Cheers,
Magnus
___
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, 


Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

2014-08-12 Thread Magnus Manske
On Tue, Aug 12, 2014 at 4:21 PM, Romaine Wiki 
wrote:

> 2014-08-12 16:57 GMT+02:00 Magnus Manske :
>
> > On Tue, Aug 12, 2014 at 3:19 PM, rupert THURNER <
> rupert.thur...@gmail.com>
> > wrote:
> >
> > > so i did not vote. because i can live with both. but i do respect the
> > vote.
> > > i do respect admin decisions, i even voted for some admins.
> > >
> > > at the end it is very simple. the one who produces software has a
> > conflict
> > > of interest. so this person or organisation is not in a good position
> to
> > > decide when it is used.
> > >
> > > wmf, its employees and voluntary officers need to be exemplary with
> > respect
> > > to conflicts of interest, imo. always. errors are allowed as well as
> > > excuses of course.
> > >
> >
> > There needs to be a balance between the wishes of (some members of) the
> > logged-in community, the (otherwise silent) majority of readers, and the
> > WMF.
> >
>
> True
>
> German Wikipedia had 1.1 billion page views in June [1]. ~300 votes (~2/3
> > against MediaViewer) do not represent the readers, IMHO.
> >
>
> I think it is more relevant to look at the number of unique visitors, in
> stead of the 1.1 billion page views.
>

I agree, but I couldn't find that number on the report card, so I used the
next best thing.
Assuming 100 page views per visitor would give 10M visitors. 80M people in
Germany alone, so probably not too far off.
That would mean that 0.003% of visitors voted, and 0.002% voted against
MediaViewer, with a ~0.001% "edge".


>
> The Foundation is tasked with managing the hardware and software that runs
> > Wikipedia. On Wikimania, several remarks were made about how outdated
> > Wikipedia appears. WMF tries to improve that situation. No, MediaViewer
> is
> > not perfect. What software is? When is it "perfect" enough to go live by
> > default? WMF should have a say there.
> >
>
> I agree that WMF should have a say, but how it is done now is certainly not
> the way WMF should handle it. Also I think it would be good to define for
> future cases how such situations should be handled. If a community has a
> strong oppose in something, such situation should be considered more
> carefully and be handled with more care. A community can't represent all
> readers, but they are themselves readers too who feel to have a large
> responsibility to the readers. They usually have valid arguments and
> considerations which should be taken more seriously. We all are on the same
> ship with the same vision on the horizon, with the same goals.
>

Yes, it could have been handled better. Actually, just saying "this is
coming by default, you can turn it off individually" /before/ the "vote"
was initiated would have been much clearer, and I don't think it would have
caused as much uproar as we have now. It also could have helped to focus
the community on finding and reporting bugs, which might have lead to
earlier improvements to the software.

And yes, the community should have a say, but this is a rather technical
issue, even if it is an interface change. The community is, and always has
been, very much in charge of content and editorial policies, beyond the
pillars.

Finally, I think that an open and detailed description by the WMF about
what, exactly, happened, and why MediaViewer is pushed against the wishes
of a small but vocal group, would help a lot to smooth the waves.

Cheers,
Magnus
___
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

2014-08-12 Thread Magnus Manske
On Tue, Aug 12, 2014 at 3:19 PM, rupert THURNER 
wrote:

> magnus, a vote always has 3 options.
> * i am for it
> * i am against it
> * i can live with the outcome of the vote
>


You mean "do not particularly care about it", surely? That you can live
with the outcome of a vote, whatever outcome that is, is a fundamental
principle of democracy, not a voting option.



> so i did not vote. because i can live with both. but i do respect the vote.
> i do respect admin decisions, i even voted for some admins.
>
> at the end it is very simple. the one who produces software has a conflict
> of interest. so this person or organisation is not in a good position to
> decide when it is used.
>
> wmf, its employees and voluntary officers need to be exemplary with respect
> to conflicts of interest, imo. always. errors are allowed as well as
> excuses of course.
>

There needs to be a balance between the wishes of (some members of) the
logged-in community, the (otherwise silent) majority of readers, and the
WMF.

German Wikipedia had 1.1 billion page views in June [1]. ~300 votes (~2/3
against MediaViewer) do not represent the readers, IMHO.

The Foundation is tasked with managing the hardware and software that runs
Wikipedia. On Wikimania, several remarks were made about how outdated
Wikipedia appears. WMF tries to improve that situation. No, MediaViewer is
not perfect. What software is? When is it "perfect" enough to go live by
default? WMF should have a say there.


>
> magnus you said you are not happy with media viewer. and you always produce
> software people like. what should they improve?
>

Like many other "old hands", it seems to get in the way of my workflow. Not
an issue for me, as long as I can turn it off.

It's probably fine for "modern" viewing, although it's hard to guess that
you get to the file page via the little Commons icon for people who (in all
likelihood) have never seen that icon, or visited Commons.

Cheers,
Magnus

[1] https://stats.wikimedia.org/EN/SummaryDE.htm


>
> rupert
> Am 12.08.2014 14:45 schrieb "Magnus Manske" :
>
> > Also, 118 people (190 vs. 72 votes in the "poll" [1] on German Wikipedia)
> > are not "the community". They are a small part of the community.
> >
> > The people who would profit [2]  from the Media Viewer as a default
> feature
> > were not consulted.
> >
> > Cheers,
> > Magnus
> >
> > [1]
> > https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Medienbetrachter
> > [2] Value of ""profit" TBD
> >
> >
> >
> >
> > On Tue, Aug 12, 2014 at 1:13 PM, Peter Southwood <
> > peter.southw...@telkomsa.net> wrote:
> >
> > > As one has been there, done that, I would like to point out that there
> is
> > > an order of magnitude difference between Internet Brands and WMF.
> > > Cheers,
> > > Peter
> > >
> > > -Original Message-
> > > From: wikimedia-l-boun...@lists.wikimedia.org [mailto:
> > > wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of Yaroslav M.
> > Blanter
> > > Sent: 12 August 2014 02:00 PM
> > > To: Wikimedia Mailing List
> > > Subject: Re: [Wikimedia-l] Superprotect user right, Comming to a wiki
> > near
> > > you
> > >
> > > On 12.08.2014 02:26, svetlana wrote:
> > >
> > > > If we accept the policy in principle, I don't care who enforces such
> > > > policy, that be community or WMF. Such policy does not go against
> > > > community entirely, unless WMF shows a will to reject community
> > > > patches related to issues which community finds important. Whether or
> > > > not this is the case, I don't care; it's a website in their hands and
> > > > they're welcome to shut it off without notice, or to experiment at
> > > > leisure.
> > > >
> > >
> > > > svetlana
> > > >
> > >
> > > Whoever believes that an administration of a crowdsourcing website can
> do
> > > whatever they want just because they are running the website should
> > > recollect what recently happened to Internet Brands and Wikitravel.
> > >
> > > Cheers
> > > Yaroslav
> > >
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-requ.

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

2014-08-12 Thread Magnus Manske
Also, 118 people (190 vs. 72 votes in the "poll" [1] on German Wikipedia)
are not "the community". They are a small part of the community.

The people who would profit [2]  from the Media Viewer as a default feature
were not consulted.

Cheers,
Magnus

[1] https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Medienbetrachter
[2] Value of ""profit" TBD




On Tue, Aug 12, 2014 at 1:13 PM, Peter Southwood <
peter.southw...@telkomsa.net> wrote:

> As one has been there, done that, I would like to point out that there is
> an order of magnitude difference between Internet Brands and WMF.
> Cheers,
> Peter
>
> -Original Message-
> From: wikimedia-l-boun...@lists.wikimedia.org [mailto:
> wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of Yaroslav M. Blanter
> Sent: 12 August 2014 02:00 PM
> To: Wikimedia Mailing List
> Subject: Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near
> you
>
> On 12.08.2014 02:26, svetlana wrote:
>
> > If we accept the policy in principle, I don't care who enforces such
> > policy, that be community or WMF. Such policy does not go against
> > community entirely, unless WMF shows a will to reject community
> > patches related to issues which community finds important. Whether or
> > not this is the case, I don't care; it's a website in their hands and
> > they're welcome to shut it off without notice, or to experiment at
> > leisure.
> >
>
> > svetlana
> >
>
> Whoever believes that an administration of a crowdsourcing website can do
> whatever they want just because they are running the website should
> recollect what recently happened to Internet Brands and Wikitravel.
>
> Cheers
> Yaroslav
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4744 / Virus Database: 4007/8020 - Release Date: 08/11/14
>
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
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, 


Re: [Wikimedia-l] Options for the German Wikipedia

2014-08-11 Thread Magnus Manske
On Mon, Aug 11, 2014 at 3:12 AM, MZMcBride  wrote:

> Using the title blacklist, the AbuseFilter
> extension, site-wide JavaScript and CSS, and other techniques, it's
> possible to fully disable reading and/or editing of the German Wikipedia
> until an amicable solution can be found.
>
>
> Strange. I seem to distinctly remember that, yesterday on Wikimania, many
(most) of us agreed that Wikipedia is an incredibly valuable resource to
the world, and that it is our mission, as a community, to protect and
improve it, and to make it available to even more people.

Your suggestion to sabotage that resource, even if it's just (!) in German,
because a few long-time editors there now have to (once) click a checkbox
to *not* see the Media viewer, strikes me as somewhat incompatible with
that mission.

The discussion about how the activation of the Media viewer on German
Wikipedia came to pass should not affect the reader, no matter what.

[Disclaimer: I am an editor on German Wikipedia (user ID 12), and I don't
really like the Media viewer, as it is.]

Cheers,
Magnus
___
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, 


Re: [Wikimedia-l] Rarest records

2014-08-04 Thread Magnus Manske
You're familiar with this, I take it:

http://radio.publicdomainproject.org/


On Mon, Aug 4, 2014 at 3:11 PM, Andy Mabbett 
wrote:

> This is a good read in its own right:
>
>
> http://www.slate.com/articles/arts/books/2014/07/amanda_petrusich_s_do_not_sell_at_any_price_reviewed_by_sarah_o_holla.html
>
> but the thesis that some 78rpm records constitute the only surviving
> example of a particular recording, with no master in an archive
> somewhere, sent chills up my spine.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
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, 


Re: [Wikimedia-l] Android "Nearby" Feature (was: Re: Community RfCs about MediaViewer)

2014-07-12 Thread Magnus Manske
Until then...

http://tools.wmflabs.org/wikishootme/


On Sat, Jul 12, 2014 at 1:38 AM, Andy Mabbett 
wrote:

> "On 11 July 2014 22:34, Erik Moeller  wrote:
>
> > The new Android app isn't simply an upgrade of the last version, it's
> > a complete re-write in native code
>
> This technical nicety is of no interest to most users, whose app was
> "updated".
>
> > In determining the feature set, the team
> > looked at core functionality they really wanted to deliver in the
> > first release, and iterated on that based on user feedback during the
> > beta.
>
> I didn't participate in this round of the beta, because there was no
> suggestion in anything that I read that significant - significantly
> useful - existing functionality would be removed. (Indeed, the removal
> wasn't mentioned when the "revamped" app was announced by your WMF
> colleagues.) I did tough, spend some time testing the "nearby" feature
> in v1's beta
>
> > And a more understandable view of the current sprint in Trello:
> >
> https://trello.com/b/5DhKhjmW/mobile-app-sprint-35-article-usability-enhancements
>
> I can't find the string "near" on that page.
>
> > The "nearby" feature in the old app also relied on third
> > party infrastructure, which makes us a bit uncomfortable from a user
> > privacy and principles perspective. Our plan is to build out our own
> > OpenStreetMap infrastructure later this year which will help in
> > further developing such geo-functionality.
>
> Is this a blocker for the return of the "nearby" feature to the app?
>
>
> In splitting this thread and describing it as "off topic", you've
> overlooked that my comments were in the context of - and in response
> to - your comment about "change-aversion [tending] to correlate pretty
> strongly with impact on existing workflows and noticeable changes to
> user experience and behaviour".
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
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, 


Re: [Wikimedia-l] [Commons-l] Evacuation

2014-07-04 Thread Magnus Manske
Quick status update: So far, not a single file has been "evacuated" to
English Wikipedia [1].

Either Commons admins don't know about it, or don't care.


[1]
https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:From_Commons


On Fri, Jul 4, 2014 at 1:53 PM, Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> wrote:

> It's nice technically, but the fact that it's necessary is tragic.
> The "Evacuation" title is very apt. North Korea, Iran, Russia, Brazil and
> other countries are talking about creating their own internets. It's a
> shame that the Wikimedia community does essentially the same thing -
> dividing humanity instead of uniting it, even though it happens from
> seemingly a very different angle.
> Yes, I happen to live in a country that is affected by the mess in Commons
> more than others, but you'll have to trust me that my concern is global,
> even if probably very naive.
> I am sincerely sorry about sounding so dramatic.
>
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
>
> 2014-07-04 1:35 GMT+03:00 David Gerard :
>
> > Thank you, Magnus!
> >
> > (add wikimedia-l to cc)
> >
> >
> > - d.
> >
> > On 3 July 2014 21:47, Magnus Manske  wrote:
> > > An attempt to alleviate the tensions caused by file deletions on
> Commons:
> > >
> > > http://magnusmanske.de/wordpress/?p=218
> > >
> > > ___
> > > Commons-l mailing list
> > > common...@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/commons-l
> > >
> >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
> ___
> Wikimedia-l 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>
>



-- 
undefined
___
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] 24 TB for User:Dispenser on Tool Labs please

2014-07-03 Thread Magnus Manske
And imagine what I could do with a space rocket and a nuclear reactor!
Wikipedia Mars mission!

ANYONE can run tools on Labs for free! It's just when you ask for a huge
chunk of hardware that someone dares to ask what you plan to do with it,
once you get it for free. Calling that censorship if trolling, pure and
simple. /me not feeding anymore


On Thu, Jul 3, 2014 at 11:38 PM, James Salsman  wrote:

> >... I am glad that there is at least some sanity checking
>
> On my happy planet, sanity means taking historical progress into
> account when telling people that they have to fill out a form and wait
> for committee review when making a reasonable request for an obvious
> need.
>
> There is so much more that the Foundation could accomplish. When will
> interest in responding to the requests from those who have proven they
> are able to make good use of resources overtake "defining scope," a
> euphemism for censorship, and building hierarchical fiefdoms?
>
> ___
> 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,
> 
>



-- 
undefined
___
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, 


Re: [Wikimedia-l] 24 TB for User:Dispenser on Tool Labs please

2014-07-03 Thread Magnus Manske
On Thu, Jul 3, 2014 at 11:14 PM, James Salsman  wrote:

>
> Why does the Foundation need a proposal to do that? Where is that
> requirement documented?
>

I work in a research institute that has >20 Petabyte of spinning disk. If I
need 20TB of server-grade storage, I have to make a formal request, and
provide a rationale. And I work there.

I don't know on what happy planet you live where that much hardware grows
on trees so that it can be given out on a whim, but as someone who both has
a lot of tools running on Labs, and who gives money to WMF on a regular
basis, I am glad that there is at least some sanity checking for endeavours
of this size.

Cheers,
Magnus
___
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, 


Re: [Wikimedia-l] The tragedy of Commons

2014-06-27 Thread Magnus Manske
On Fri, Jun 27, 2014 at 1:27 AM, Pete Forsyth  wrote:

> On Wed, Jun 25, 2014 at 11:07 PM, Erik Moeller  wrote:
>
> > than aggressively purging content in the fear that a single byte of
> > potentially non-free content may infect the repository.
> >
>
> You're attacking a straw man. I hope you do not sincerely believe anybody
> acts out of such a childish fear.


Well, just yesterday I saw a (good but slightly amateurish-looking) image
that is to be deleted because the metadata embedded in the /other/ images
of the uploader indicates multiple cameras were used. Clearly, no one has
more than one camera, so it must be a copyright violation. (would post the
URL but forgot which image)

Childish fears indeed.

Magnus
___
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, 


Re: [Wikimedia-l] Wikidata // was The tragedy of Commons

2014-06-18 Thread Magnus Manske
It would just have to be ported to Commons once there's a native WIkiBase
installation. If it will be ported at all.

Is it really worth the fuss, so we can tinker for a few months? (I would
genuinely like to know!)




On Wed, Jun 18, 2014 at 4:00 PM, Pierre-Selim 
wrote:

> 2014-06-18 16:58 GMT+02:00 Magnus Manske :
>
> > The issue here seems to be "political/community" rather than technology.
> I
> > could probably set up a MediaWiki installation with WikiBase plugin on
> Tool
> > Labs within a day or so, then have a bot create/synchronize an item for
> > each file on Commons. Community could start to create properties, and
> bots
> > could fill in basic statements.
> >
> > That said, I'm not doing that. First, no time. Second, ire of the WMF for
> > making them scramble to re-create my stuff yet again ;-)
> >
>
> And if we say "please" ?
>
>
>
> > Cheers,
> > Magnus
> >
> >
> > On Wed, Jun 18, 2014 at 3:32 PM, David Cuenca  wrote:
> >
> > > On Wed, Jun 18, 2014 at 3:33 PM, Fæ  wrote:
> > > >
> > > > At the current time, I have yet to see how the Wikidata theoretical
> > > > use improves finding images on Commons today. After regularly getting
> > > > emails over the past two years raising expectations of how these
> > > > problems will be solved through Wikidata, I have yet to be involved
> or
> > > > invited to join any Commons based Wikidata project, despite being
> > > > currently the most active unpaid volunteer uploader for Commons.
> > > >
> > >
> > > There is;
> > > https://commons.wikimedia.org/wiki/Commons:Wikidata
> > > https://commons.wikimedia.org/wiki/Commons:Wikidata_for_media_info
> > > https://www.wikidata.org/wiki/Wikidata:Wikimedia_Commons
> > >
> > > I formally invite you to take a look and join the discussions if you
> feel
> > > like :-)
> > >
> > >
> > > >
> > > > One of my particular interests was sorting out the Geograph project
> > > > where I added meaningful place categories to images (around a million
> > > > images). Last year I deliberately deferred continuing improvements
> and
> > > > new uploads based on suggestions of how Wikidata was going to
> > > > revolutionise the way this worked. As far as I am aware, there is
> > > > still no published plan to help with identifying Commons categories
> > > > with places using Wikidata; indeed for projects like our Avionics
> > > > batch uploads (which rely on Airport categories and their locations)
> I
> > > > have been told the opposite, to no longer expect, nor wait, for this
> > > > to be sorted out and I am likely to revise my Geograph work without
> > > > any plans to incorporate Wikidata, or work with Wikidata.
> > > >
> > > >
> > > You would need a lua template to do a bit of triangulation:
> > > 1. From the linked Commons category to the Wikidata item you fetch the
> > > statements
> > > 2. One of those statements should be "category's main topic (P301)"
> > > 3. From the linked item, you can extract the location data
> > >
> > > This should be possible once this bug is implemented
> > > https://bugzilla.wikimedia.org/show_bug.cgi?id=47930
> > >
> > > I don't much about the Geograph project, but perhaps your work might be
> > > compatible with a future deployment of "wikidata for media info"?
> > >
> > > Micru
> > > ___
> > > 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>
> > >
> >
> >
> >
> > --
> > undefined
> > ___
> > 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>
> >
>
>
>
> --
> Pierre-Selim
> ___
> 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>
>



-- 
undefined
___
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] Wikidata // was The tragedy of Commons

2014-06-18 Thread Magnus Manske
The issue here seems to be "political/community" rather than technology. I
could probably set up a MediaWiki installation with WikiBase plugin on Tool
Labs within a day or so, then have a bot create/synchronize an item for
each file on Commons. Community could start to create properties, and bots
could fill in basic statements.

That said, I'm not doing that. First, no time. Second, ire of the WMF for
making them scramble to re-create my stuff yet again ;-)

Cheers,
Magnus


On Wed, Jun 18, 2014 at 3:32 PM, David Cuenca  wrote:

> On Wed, Jun 18, 2014 at 3:33 PM, Fæ  wrote:
> >
> > At the current time, I have yet to see how the Wikidata theoretical
> > use improves finding images on Commons today. After regularly getting
> > emails over the past two years raising expectations of how these
> > problems will be solved through Wikidata, I have yet to be involved or
> > invited to join any Commons based Wikidata project, despite being
> > currently the most active unpaid volunteer uploader for Commons.
> >
>
> There is;
> https://commons.wikimedia.org/wiki/Commons:Wikidata
> https://commons.wikimedia.org/wiki/Commons:Wikidata_for_media_info
> https://www.wikidata.org/wiki/Wikidata:Wikimedia_Commons
>
> I formally invite you to take a look and join the discussions if you feel
> like :-)
>
>
> >
> > One of my particular interests was sorting out the Geograph project
> > where I added meaningful place categories to images (around a million
> > images). Last year I deliberately deferred continuing improvements and
> > new uploads based on suggestions of how Wikidata was going to
> > revolutionise the way this worked. As far as I am aware, there is
> > still no published plan to help with identifying Commons categories
> > with places using Wikidata; indeed for projects like our Avionics
> > batch uploads (which rely on Airport categories and their locations) I
> > have been told the opposite, to no longer expect, nor wait, for this
> > to be sorted out and I am likely to revise my Geograph work without
> > any plans to incorporate Wikidata, or work with Wikidata.
> >
> >
> You would need a lua template to do a bit of triangulation:
> 1. From the linked Commons category to the Wikidata item you fetch the
> statements
> 2. One of those statements should be "category's main topic (P301)"
> 3. From the linked item, you can extract the location data
>
> This should be possible once this bug is implemented
> https://bugzilla.wikimedia.org/show_bug.cgi?id=47930
>
> I don't much about the Geograph project, but perhaps your work might be
> compatible with a future deployment of "wikidata for media info"?
>
> Micru
> ___
> 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,
> 
>



-- 
undefined
___
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, 


Re: [Wikimedia-l] Wikipedian in Residence at ORCID

2014-06-12 Thread Magnus Manske
And then, we discover tools long present:

http://tools.wmflabs.org/wikidata-todo/autolist2.php?language=en&project=wikipedia&category=Wikipedia%20articles%20with%20ORCID%20identifiers&depth=0&wdq=claim%5B496%5D&mode=cat_no_wdq&statementlist=&run=Run&label_contains=&label_contains_not=&chunk_size=1

All en.wp pages with ORCID IDs that are not yet in Wikidata.

Cheers,
Magnus


On Thu, Jun 12, 2014 at 7:01 AM, Gerard Meijssen 
wrote:

> Hoi,
> With some regularity the {{authority control}} usage is mined for data
> missing in Wikidata. Once it is, references can be taken away in
> Wikipedia... and as far as I know this happens as well.
>
> For Victor Anatolyevich Vassiliev for instance there is nothing in
> en.Wikipedia about ORCID.
> Thanks,
>  GerardM
>
>
> On 12 June 2014 00:40, phoebe ayers  wrote:
>
> > Thanks Gerard! However, I meant getting a list article subjects who have
> an
> > ORCID that we haven't already put in Wikidata, so we can update Wikidata!
> > :)
> >
> > best,
> > Phoebe
> >
> >
> >
> >
> > On Tue, Jun 10, 2014 at 11:41 PM, Gerard Meijssen <
> > gerard.meijs...@gmail.com
> > > wrote:
> >
> > > Hoi,
> > > Actually it is not that hard [1] to find who has an ORCID.
> > > Thanks,
> > >  Gerard
> > >
> > > [1]
> > >
> > >
> >
> http://tools.wmflabs.org/wikidata-todo/autolist2.php?language=en&project=wikipedia&category=&depth=12&wdq=claim%5B31%3A5%5D%20and%20claim%5B496%5D&mode=cat_and_wdq&statementlist=&run=Run&label_contains=&label_contains_not=&chunk_size=1
> > >
> > >
> > >
> > >
> > >
> > > On 11 June 2014 03:39, phoebe ayers  wrote:
> > >
> > > > On Tue, Jun 10, 2014 at 10:29 AM, Andy Mabbett <
> > > a...@pigsonthewing.org.uk>
> > > > wrote:
> > > >
> > > > > As of today, I am Wikipedian in Residence [1] at ORCID [2].
> > > > > The role is described in [3]. Please let me know if I can assist
> you,
> > > > > in that capacity.
> > > > >
> > > > > [1] https://en.wikipedia.org/wiki/Wikipedia:ORCID
> > > > >
> > > > > [2] https://en.wikipedia.org/wiki/ORCID
> > > > >
> > > > > [3]
> > > > >
> > > >
> > >
> >
> http://orcid.org/blog/2014/06/04/announcing-orcid%E2%80%99s-wikipedian-residence
> > > > >
> > > > > --
> > > > > Andy Mabbett
> > > > > @pigsonthewing
> > > > > http://pigsonthewing.org.uk
> > > >
> > > >
> > > >
> > > > Congrats, Andy!
> > > >
> > > > Coincidentally, as part of my day job, I was just looking into how we
> > > treat
> > > > ORCIDs and other author ID schemes in Wikidata. One thing I
> discovered
> > > > poking around by hand is that it is quite difficult to match up who
> has
> > > > ORCIDs (not every researcher) with who has a Wikipedia article (also
> > not
> > > > every researcher). I think it would be great to use ORCID's API to
> > search
> > > > for article subjects who might have ORCIDs (though I think that list
> > > would
> > > > have to be confirmed/matched by hand, because of lots of ambiguity
> > around
> > > > similar names in ORCID if there's no other information -- maybe a
> task
> > > for
> > > > another Wikidata game :) )
> > > >
> > > > Anyway, I'd be happy to chat offlist or somewhere else about it, but
> I
> > am
> > > > glad to see they're reaching out to Wikipedia and that you're
> involved!
> > > >
> > > > cheers,
> > > > Phoebe
> > > >
> > > > --
> > > > * I use this address for lists; send personal messages to
> phoebe.ayers
> > > 
> > > > gmail.com *
> > > > ___
> > > > 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,
> > > > 
> > > >
> > > ___
> > > 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,
> > > 
> > >
> >
> >
> >
> > --
> > * I use this address for lists; send personal messages to phoebe.ayers
> 
> > gmail.com *
> > ___
> > 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,
> > 
> >
> ___
> 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,
> 
>



-- 
undefined
___
Wikimedia-l m

Re: [Wikimedia-l] Which articles are widely shared accorss languages

2014-04-10 Thread Magnus Manske
There's a tool for that:

http://tools.wmflabs.org/wikidata-terminator/index.php

Check the third row ("Top 1000 items with missing articles").


On Thu, Apr 10, 2014 at 7:47 PM, PiRSquared17 wrote:

> On 4/10/14, Chris McKenna  wrote:
> > I'm no expert, but I would expect that finding which articles are and are
> > not present in a given set of Wikipedias would be an easy task now that
> > Wikidata handles all the interwiki links.
> >
> > Chris
>
> You are right.  There is already even a request for a special page to
> do just that .
> Here is the result of the SQL query Maarten suggested
>  (note that top results
> are main pages and templates!)
>
> It is also possible to view the pages with the most interwiki links on
> a specific wiki, e.g.
> .  This is
> nothing new, and shows more relevant "article" results than the query
> I ran.
>
> -- PiRSquared
>
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 




-- 
undefined
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Generated texts

2014-02-07 Thread Magnus Manske
Hi Andy,

that message comes up when the JavaScript is broken. I just tried the Bach
link, and it works fine for me. Probably a stale browser cache;
force-reloading the page should help.

Cheers,
Magnus


On Fri, Feb 7, 2014 at 8:27 PM, Andy Mabbett wrote:

> Your link has "gone very wrong". I would wait the suggested half hour
> before telling you this, but by then I hope to be asleep.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
> On Feb 7, 2014 4:42 PM, "Gerard Meijssen" 
> wrote:
>
> > Hoi,
> >
> > We have often had discussions about generating texts to be used in
> > Wikipedia articles. The drawback of articles that are generated in this
> way
> > is that they do not get updated as more information becomes available.
> >
> > The data in Wikidata is comparable with the kind of data often used in
> such
> > processes.
> >
> > The first kind texts that are generated bu the Reasonator are based on
> the
> > biographic information of a person. As Johann Sebastian Bach is a great
> > example of the power of both Wikidata and Reasonator, I invite you to
> have
> > a look [1].
> >
> > The text is completely generated based on the information in Wikidata and
> > Magnus is very much in the process of iterating this functionality. What
> I
> > hope you will see as a challenge is writing similar functionality for
> other
> > languages.
> >
> > What I hope for is that the Wikidata development team will appreciate
> this
> > for what its potential and support it when it is found that additional
> > technology is needed.
> > Thanks,
> >   GerardM
> >
> >
> > [1] http://tools.wmflabs.org/reasonator/?q=Q1339
> > ___
> > Wikimedia-l mailing list
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



-- 
undefined
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] [Wikitech-l] Reasonator use in Wikipedias

2014-01-24 Thread Magnus Manske
A list of female painters with no article on en.wp:
http://tools.wmflabs.org/wikidata-todo/autolist.html?q=claim%5B106%3A1028181%5D%20and%20claim%5B21%3A6581072%5D%20%20and%20nolink%5Benwiki%5D

(might take a few seconds to load)

Cheers,
Magnus


On Fri, Jan 24, 2014 at 8:24 AM, Jane Darnell  wrote:

> I am not convinced that this is useful (yet). I have been generating
> some red-link lists for the upcoming international edit-a-thon about
> Art & Feminism on February 1st, and I tried out this tool to see if I
> could come with with lists of women artists already in other projects.
> With Reasonator I see 503 female persons and 760 male persons. Not
> very helpful (yet) for generating red-link lists.
>
> 2014/1/23, Risker :
> > On 23 January 2014 15:42, Andy Mabbett 
> wrote:
> >
> >> On 23 January 2014 15:12, Magnus Manske 
> >> wrote:
> >> >
> >> > I thought about that as well. Besides the intro text, the info box
> would
> >> be
> >> > the main "attraction"; but if infoboxes were to fall back on wikidata
> >> > information, which they could technically already do, all we'd have to
> >> > do
> >> > is add a blank infobox, and it should automatically fill up with the
> >> > wikidata information. In light of that, writing code to fill an
> infobox
> >> > with values form wikidata to paste into the article seems ... low-tech
> >> ;-)
> >>
> >> Indeed - but we have to work with what we have.
> >>
> >> Perhaps we could concentrate on one very narrow subject, and its
> >> single corresponding infobox, as a pilot?
> >>
> >>
> >>
> >
> > I suggest that this discussion should be on the various projects that
> might
> > be affected, particularly as different projects have very different ideas
> > about whether the use of Wikidata for anything more than language links
> is
> > acceptable. Many projects do not permit bulk bot creation of content, and
> > this proposal is a close parallel.
> >
> > Further, content that isn't editable on the project on which it is hosted
> > is probably not a very effective way to persuade people to turn it into
> an
> > actual page.
> >
> > Trialing the process on some small projects that actively volunteer to
> > participate would be a first step.
> >
> > Risker/Anne
> > ___
> > 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 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>
>



-- 
undefined
___
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] [Wikitech-l] Reasonator use in Wikipedias

2014-01-23 Thread Magnus Manske
Hi Andy,

I thought about that as well. Besides the intro text, the info box would be
the main "attraction"; but if infoboxes were to fall back on wikidata
information, which they could technically already do, all we'd have to do
is add a blank infobox, and it should automatically fill up with the
wikidata information. In light of that, writing code to fill an infobox
with values form wikidata to paste into the article seems ... low-tech ;-)

Cheers,
Magnus


On Thu, Jan 23, 2014 at 3:05 PM, Andy Mabbett wrote:

> On 22 January 2014 08:35, Gerard Meijssen 
> wrote:
>
> > There are many ways to skin a cat. The most obvious
> > one is to add a {{Reasonator}} template as a place
> > holder in a Wikipedia. Another is to capture a not
> > found or a red link and insert Reasonator info. What
> > I am trying to do is to give a sense of direction. I am
> > not indicating how it will be done for sure.
>
> [I'm not on the devs list, so trimmed from the CC]
>
> I would like people to be able to "subst" that template (or have a big
> button that does the same thing), and have some code draft a stub
> article based on the statements in Wikidata, say:
>
>  "X was a German painter born in [[Munich]] on
>  27 May 1801. He died in [[Berlin]] on 3
>  March 1899"
>
> with formatted references, a reflist template, and a pre-populated
> infobox. It would be delivered in preview state, allowing further
> editing before publication.
>
> A suitably prominent warning would alert editors that they still bear
> responsibility for ensuring that the subject is notable, and the
> article fit for publication, according to local standards. A hidden
> category and/or an edit tag would allow tracking.
>
> Because of the complexity of this task, we could pilot it for one type
> of subject (say, buildings, or people, or even a subset of one of
> those) in one or two languages.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



-- 
undefined
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] [Wikitech-l] Reasonator use in Wikipedias

2014-01-21 Thread Magnus Manske
On a technical note, Reasonator is pure JavaScript, so should be easily
portable, even to a Wikipedia:Reasonator.js page (or several pages, with
support JS).

git here:
https://bitbucket.org/magnusmanske/reasonator


On Tue, Jan 21, 2014 at 5:13 PM, Ryan Lane  wrote:

> On Tue, Jan 21, 2014 at 7:17 AM, Gerard Meijssen
> wrote:
>
> > Hoi,
> >
> > At this moment Wikipedia "red links" provide no information whatsoever.
> > This is not cool.
> >
> > In Wikidata we often have labels for the missing (=red link) articles. We
> > can and do provide information from Wikidata in a reasonable way that is
> > informative in the "Reasonator". We also provide additional search
> > information on many Wikipedias.
> >
> > In the Reasonator we have now implemented "red lines" [1]. They indicate
> > when a label does not exist in the primary language that is in use.
> >
> > What we are considering is creating a template {{Reasonator}} that will
> > present information based on what is available in Wikidata. Such a
> template
> > would be a stand in until an article is actually written. What we would
> > provide is information that is presented in the same way as we provide it
> > as this moment in time [2]
> >
> > This may open up a box of worms; Reasonator is NOT using any caching.
> There
> > may be lots of other reasons why you might think this proposal is evil.
> All
> > the evil that is technical has some merit but, you have to consider that
> > the other side of the equation is that we are not "sharing in the sum of
> > all knowledge" even when we have much of the missing requested
> information
> > available to us.
> >
> > One saving (technical) grace, Reasonator loads round about as quickly as
> > WIkidata does.
> >
> > As this is advance warning, I hope that you can help with the issues that
> > will come about. I hope that you will consider the impact this will have
> on
> > our traffic and measure to what extend it grows our data.
> >
> > The Reasonator pages will not show up prettily on mobile phones .. so
> does
> > Wikidata by the way. It does not consider Wikipedia zero. There may be
> more
> > issues that may require attention. But again, it beats not serving the
> > information that we have to those that are requesting it.
> >
>
> I have a strong feeling you're going to bring labs to its knees.
>
> Sending editors to labs is one thing, but you're proposing sending readers
> to labs, to a service that isn't cached.
>
> If reasonator is something we want to support for something like this,
> maybe we should consider turning it into a production service?
>
> - Ryan
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



-- 
undefined
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Reasonator use in Wikipedias

2014-01-21 Thread Magnus Manske
Note: the [2] link goes to the test site. The correct link is:
tools.wmflabs.org/reasonator/?lang=oc&q=35610


On Tue, Jan 21, 2014 at 3:17 PM, Gerard Meijssen
wrote:

> Hoi,
>
> At this moment Wikipedia "red links" provide no information whatsoever.
> This is not cool.
>
> In Wikidata we often have labels for the missing (=red link) articles. We
> can and do provide information from Wikidata in a reasonable way that is
> informative in the "Reasonator". We also provide additional search
> information on many Wikipedias.
>
> In the Reasonator we have now implemented "red lines" [1]. They indicate
> when a label does not exist in the primary language that is in use.
>
> What we are considering is creating a template {{Reasonator}} that will
> present information based on what is available in Wikidata. Such a template
> would be a stand in until an article is actually written. What we would
> provide is information that is presented in the same way as we provide it
> as this moment in time [2]
>
> This may open up a box of worms; Reasonator is NOT using any caching. There
> may be lots of other reasons why you might think this proposal is evil. All
> the evil that is technical has some merit but, you have to consider that
> the other side of the equation is that we are not "sharing in the sum of
> all knowledge" even when we have much of the missing requested information
> available to us.
>
> One saving (technical) grace, Reasonator loads round about as quickly as
> WIkidata does.
>
> As this is advance warning, I hope that you can help with the issues that
> will come about. I hope that you will consider the impact this will have on
> our traffic and measure to what extend it grows our data.
>
> The Reasonator pages will not show up prettily on mobile phones .. so does
> Wikidata by the way. It does not consider Wikipedia zero. There may be more
> issues that may require attention. But again, it beats not serving the
> information that we have to those that are requesting it.
> Thanks,
>   GerardM
>
>
> [1]
>
> http://ultimategerardm.blogspot.nl/2014/01/reasonator-is-red-lining-your-data.html
> [2] http://tools.wmflabs.org/reasonator/test/?lang=oc&q=35610
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 




-- 
undefined
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] [Labs-l] Wikimedia labs-tools

2013-09-11 Thread Magnus Manske
There was a recent mail saying that Labs is not considered "production"
stability. Mainly a disagreement about how many 9s in the 99.9% that
represents.


On Wed, Sep 11, 2013 at 4:09 PM, Petr Bena  wrote:

> Hi,
>
> can you please explain to me from where is this information:
>
> "According to the people in charge of labs they dont care about
> ensuring stability and that if stuff breaks Oh well well get to it
> when we can. They say that tools is not a production service so we
> really don't give a <>, if it breaks it breaks"
>
> If I can speak for myself as a volunteer sysadmin of tool labs, I do
> care if tool labs are stable or if they break, it's just that for many
> of the outages I just can't do anything but sit and wait for someone
> with access to servers which cause troubles (which are typically
> outside of tool labs, like nfs storage or mysql replicas)
>
> I can't speak for others though, but I doubt that anyone who is really
> "in charge" told you they don't care about stability. Or at least I
> hope so :-)
>
> On Wed, Sep 11, 2013 at 4:50 PM, John  wrote:
> > tools.wmflabs.org is supposed to be the replacement for the toolserver
> which
> > the wmf is basically forcefully shutting down. I started the migration
> > several months ago but got fed up with the difficulties and stopped. In
> the
> > last month I have moved most of my tools to labs, and I have discovered
> that
> > there are some serious issues that need addressed.
> >
> > The toolserver was a fairly stable environment. I checked my primary
> host I
> > connect to and it has been up for 4 months with continuous operations.
> >
> > tools however is being treated like the red-headed step child. According
> to
> > the people in charge of labs they dont care about ensuring stability and
> > that if stuff breaks Oh well well get to it when we can. They say that
> tools
> > is not a production service so we really don't give a <>, if it breaks it
> > breaks, we will fix it when we can but since its not production its not a
> > priority.
> >
> > One good example of this is that a tool cannot connect to
> tools.wmflabs.org
> > due to a host configuration issue. This is a known bug, we have a way of
> > fixing it, but its still not implemented
> >
> > Given that tools is replacing the toolserver I would expect at worst
> labs is
> > just as good, however what I am seeing and hearing is that the wmf is
> > throwing away one of their best assets, and driving away a lot of
> developers
> > due to the management of tools.
> >
> > I do want to give Coren credit as he is doing what he can to support the
> > migration.
> >
> > My question is why has the wmf decided to degrade the environment where
> tool
> > developers design and host tools (quite a few of them are long term
> stable
> > projects)? and what can we do to remedy this?
> >
> > John
> >
> > ___
> > Labs-l mailing list
> > lab...@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/labs-l
> >
>
> ___
> Labs-l mailing list
> lab...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>



-- 
undefined
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] PRISM

2013-06-13 Thread Magnus Manske
I would like to raise the option of a more "Wikipedia-like" protest. How
about, on the English Wikipedia, picking one day to make the Main Page
topic-specific, similar to the traditional April 1 selection?

Candidates, off the top of my hat:
[[NSA]] / [[Black Chamber]]
[[PRISM (surveillance program)]]
[[Panopticon]]
[[Surveillance state]] / [[Mass surveillance]]
[[1984]]
[[Surveillance abuse]]

The articles are (of course!:-) NPOV, but the topic selection could be POV
to raise awareness of the issue.






On Thu, Jun 13, 2013 at 8:16 AM, Federico Leva (Nemo) wrote:

> Fred Bauder, 12/06/2013 22:47:
>
>  "We hack network backbones – like huge internet routers, basically – that
>> give us access to the communications of hundreds of thousands of
>> computers without having to hack every single one,"
>>
>> http://www.guardian.co.uk/**world/2013/jun/12/edward-**
>> snowden-us-extradition-fight
>>
>
> Time for some additional encryption at least between different parts of
> the infrastructure perhaps?
>
> Nemo
>
>
> __**_
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.**org 
> Unsubscribe: 
> https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l
>
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] WikiData and WikiSpecies

2013-06-03 Thread Magnus Manske
On Mon, Jun 3, 2013 at 3:12 PM, Gerard Meijssen
wrote:

>
> Really, taxonomy is tricky. FYI I have an 80 MB database with ONLY cacti
> and succulents. I learned a lot in the process.
>
> So, have you imported that to Wikidata yet?
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] WikiData and WikiSpecies

2013-06-03 Thread Magnus Manske
Or just get the entire taxonomy for a species quickly:
http://208.80.153.172/wdq/?q=tree[4504][171,273,75,76,77,70,71,74,89]

Cheers,
Magnus


On Mon, Jun 3, 2013 at 12:48 PM, Nik Everett  wrote:

> I promise I'll get to looking at wikidata's search sometime!  I sure don't
> know when that time will be but I'll get to it!
>
> Sent from my iPhone
>
> On Jun 3, 2013, at 6:01 AM, "Federico Leva (Nemo)" 
> wrote:
>
> > Nikola Smolenski, 03/06/2013 11:44:
> >> What if this interface would exist? I believe it could be made really
> >> quickly and easily.
> >
> > It's not about interface only, for instance the search backend is
> completely broken and useless for Wikidata, AFAICS.
> > From what I understand, the interface for Wikidata data is provided by
> client sites such as Wikipedia. There are no plans for inclusion of
> Wikispecies as client site, but if/when Wikispecies' needs are implemented
> this doesn't imply Wikispecies would be useless, rather that it would have
> easier access to data and could focus on its scope i.e. presenting such
> data. Currently it tries to do both and IMHO fails at both.
> >
> > Nemo
> >
> > P.s.: There are also connected problems like sv.wiki becoming a
> Wikispecies/Wikidata on its own with a million species bot-entries, but
> it's another story.
> >
> > ___
> > Wikimedia-l mailing list
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Single User Login finalisation: some accounts will be renamed

2013-04-30 Thread Magnus Manske
Will the affected users be given a one-time offer to have their accounts
renamed, or are they stuck forever with the "~" ones?


On Tue, Apr 30, 2013 at 5:01 AM, James Forrester
wrote:

> On 29 April 2013 20:59, Fae  wrote:
> > Thanks James, personally I'm comforted by your prompt reply.
>
> Happy to help. :-)
>
> > My intuition is that this would be unlikely to affect any accounts
> > with more than 5,000 edits, possibly fewer. I have no doubt that you
> > intend to take special care to help users with significant
> > contributions, such as those with a well established contribution
> > history at this level.
>
> Yes, I'll be personally reviewing the renaming list to make sure we
> can catch any particularly-major issues early.
>
> Yours,
> --
> James D. Forrester
> Product Manager, VisualEditor
> Wikimedia Foundation, Inc.
>
> jforres...@wikimedia.org | @jdforrester
>
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>
___
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

2012-12-03 Thread Magnus Manske
On Mon, Dec 3, 2012 at 9:10 AM, David Gerard  wrote:

> On 3 December 2012 09:04, Erik Moeller  wrote:
>
> > For easier comparability of the two banner behaviors -
> > Activation on hover (current behavior):
> >
> https://en.wikipedia.org/wiki/Giovanni_Lorenzo?banner=B12_5C_120216_SuperCondensed_Hover
>
>
> ... yeah, that's the sort of behaviour that inspires ad-blockers.
>
> Wouldn't be quite so bad if they shrunk again when you moved the mouse out
of the ad/form region...
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Fundraiser causing confusion

2012-11-28 Thread Magnus Manske
To be fair, this orange banner does look a little ... out-of-place, not at
all matching the rest of the page in style.

It does the job of conveying the "we are a small poor foundation" a little
too well, maybe ;-)


On Wed, Nov 28, 2012 at 2:54 PM, Thomas Dalton wrote:

> On 28 November 2012 14:41, Charles Andrès 
> wrote:
> > In fact we haven't seen the link before but we had the same in
> Switzerland, it seems that in a way people complain about the traditional
> banners that are to intrusive, but in the other hand they are more
> suspicious and have doubt about banners that are not the same than previous
> year!
>
> This happens every year - there are always people concerned that we've
> been hacked, or that they have a virus, or that there is some kind of
> phishing attack going on. I expect the only way to avoid that would be
> to have the banners up continuously 365 days a year, so people are
> used to them just being part of the site - as long as people are used
> to there being no banner ads on Wikipedia, the sudden appearance of
> them will confuse some people.
>
> As Philippe says, I would expect there to be an OTRS template from
> previous years to explain what is going on.
>
> ___
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] [Wikipedia-l] Sort it

2012-10-26 Thread Magnus Manske
As a biologist, I'd say it's the "I need to figure this out"
mentality, which leads to frustration if the system (which you had
believed you figured out!) apparently turns against you.

My advice here is: That should not happen, but there is so much more
to do on Wikipedia; let this specific issue rest, for month or years
or forever, and contribute something else. The issue will get sorted,
with or without you, eventually.

Magnus



On Fri, Oct 26, 2012 at 12:56 PM, Charles Andrès
 wrote:
> Amir is right, without judging this specific case, the pattern describe here 
> is a problem.
>
> Especially the massive revert attitude , it's really a challenge for 
> retaining new specialist editor.
>
> Charles
>
> ___
> Charles ANDRES, Chairman
> "Wikimedia CH" – Association for the advancement of free knowledge –
> www.wikimedia.ch
> Skype: charles.andres.wmch
> IRC://irc.freenode.net/wikimedia-ch
>
> Le 26 oct. 2012 à 13:43, "Amir E. Aharoni"  a 
> écrit :
>
>> Shortened, and grossly over-simplified:
>> A biologist wrote some things about biology and they were not challenged.
>> Then he wrote some things about dinosaurs, and they were reverted. If
>> I understood correctly, the reason for the reverts was that it
>> appeared to be original research (WP:NOR).
>> And now the biologist is pissed off, possibly for a good reason, and
>> wants his previous contributions removed, too.
>>
>> This is a story that repeats itself quite often, with surprisingly
>> similar details: an expert does some acceptable things, then doing
>> some things that turn out to rouse controversy, then wanting to retire
>> with a storm. I'm not implying that the expert is bad, absolutely not;
>> I'm just noting a pattern.
>>
>> Whatever the details of the story are, it's not good and it may
>> justify discussion.
>>
>> But as a meta-comment, it should be done on wikien-l or on
>> wikimedia-l, and not on this list, which is called "wikipedia-l", but
>> is not active in practice.
>>
>> --
>> Amir
>>
>> 2012/10/26 Thomas Dalton 
>>>
>>> TL;DR (Too long; didn't read.)
>>>
>>> Please provide a summary that makes clear what point you are trying to 
>>> make...
>>>
>>> On 26 October 2012 11:55, John Jackson  wrote:
 Greetings –

 I hope this is a good place to send a weighty message to Wikipedia.
 You’ll want to read all through.

 I am a scientist who has always liked the Wikipedia idea, and I like
 your implementation.  Lately I’ve started making contributions.
 Although I’m a cognitive scientist who taught biological psychology at
 degree level for several years and have done AI research since the
 ‘80’s, I’ve diverted for a decade or more to resolve a set of major
 evolutionary puzzles.

 Fairly peripheral but within the overall project was an investigation
 of bird breathing, and I decided to piece together the research into
 it, and deliver it properly to the public.  Trust me, the finer
 details were obscure.  On the way I discovered why penguins’ lungs
 don’t collapse even at 500m when whales’ lungs collapse by 100m; I
 found out what the neopulmo did (though not why) and why penguins
 don’t have it, and I changed our understanding of flow within it; I
 also resolved the old chestnut of whether birds had counter-current
 exchange in their lungs.  That is, completely discovered, not just for
 myself.  By careful editing and addition including the long overdue
 diagram the subject needed, I converted the two Wikipedia pages
 dealing with bird breathing from an incomplete mire to a place of
 revelation (though the German version needs starting afresh, and
 Duncker agrees).  But it was an honour do so.

 More central to my overall project was cladogenesis, the heart of
 palaeontology and just the thing that I, as an MSc in info. sys.
 engineering would be expected to get into.  I’ve written my own clad.
 software, invented and implemented my own heuristic version, proved
 the theorem in graph theory that resolves an issue in checking
 evolutionary trees by time and rooting them, and highlighted a serious
 statistical fallacy invalidating another major current of work in the
 time-checking of trees.

 In these activities I was almost entirely alone as regards other
 workers in the overall field, since that field, dinobird
 palaeontology, is notorious for its abuse of the lack of scientific
 and indeed academic constraint that all historical disciplines are
 prey to.  Applicants for research positions into that biological
 science, which relies heavily on computer science and statistics, are
 usually accepted with just a geology first degree.  Put succinctly but
 honestly, the standard of science amongst professional dinobird
 palaeontologists is crap, so much so that I’ve never taken the idea of
 publishing for

Re: [Wikimedia-l] Wikipedia redefined -- typography and UX and such

2012-08-17 Thread Magnus Manske
On Fri, Aug 17, 2012 at 6:43 PM, Cristian Consonni
 wrote:
> 2012/8/17 Ziko van Dijk :
>> Yes, I would like to see the skin in my Preferences. Where is a wiki
>> page for comment? :-)
>
> See the "META" link  in the upper-right corner i.e.:
> http://meta.wikimedia.org/wiki/Wikipedia_redefined

Technically, it's not a MediaWiki skin. It could become one, but that
would require changes in MediaWiki itself, and we all know how long
that takes. There are intermediary solutions, but they'd be ugly, like
loading each page in a "normal" skin, then rearranging it via
JavaScript, which causes a flickering "jump" on each page load. For
the moment, toolserver it is.

Magnus

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Wikipedia redefined -- typography and UX and such

2012-08-17 Thread Magnus Manske
On Fri, Aug 17, 2012 at 4:50 PM, Cristian Consonni
 wrote:
> 2012/8/17 Risker :
>> It looks pretty clean and less cluttered.  It also draws attention to some
>> of our internal issues, such as massive listing of references at the bottom
>> of the page, and all those templates linking groups of articles together;
>> between these two, they're taking up nearly a quarter of the 'space'.
>> They're both important issues, although separate ones.
>>
>> I'm looking at this from a fairly small screen, and I wonder how wide the
>> "text" will be when the left-side links are added in, or if your proposal
>> is to drop that entirely. As it is, the text is a bit narrow now, leading
>> to a very long article, but I think that balances out with the increased
>> white space and different font, both of which make the article easier on
>> the eyes.
>
> I think we can gather comments about Magnus proposal here:
> http://meta.wikimedia.org/wiki/Wikipedia_redefined
>
> Also, you're invited to put your name in either list if you're interested.

Thanks, I've added a META backlink from the interface.

Magnus

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Wikipedia redefined -- typography and UX and such

2012-08-17 Thread Magnus Manske
On Fri, Aug 17, 2012 at 3:08 PM, Delirium  wrote:
> On 8/17/12 12:02 PM, Magnus Manske wrote:
>>
>> http://toolserver.org/~magnus/redefined/?page=Pyramid
>
>
> This is quite nice, especially on a larger screen! Our current layout, which
> uses the full browser width for text, makes articles hard to read and
> cluttered-looking on larger screens. The text column with images and ToC in
> the sidebar is a nice change. Though on the other hand, I do like flowing
> text around images below some with threshold. When reading on a smaller
> screen, with this layout you can end up with a very narrow text column down
> the middle. But overall I like it. The only thing I'd really want is some
> way to get to more of the functionality. For example, I can't find how to
> view edit history.

Thanks! This is just a demo, most functionality is missing; no point
in implementing all of it unless there's a potential long-term user
and developer base :-)

That said, it uses only the MediaWiki API, so it can run anywhere,
even on a blank page served by Wikipedia, in the far future, when
there is no more server-side full-page rendering...

It's pretty useless on mobile devices, but then we have a nice mobile
interface; this whole auto-collapse-on-mobile thing only goes so far,
IMHO.

Upshot: Unless I get at least, say, five people who'd help debug it,
and at least one person who'd help coding, I'm not going to add more
functions to it. Also, the "redefined" people might sue me for
stealing their layout proposal ;-)


Magnus

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Wikipedia redefined -- typography and UX and such

2012-08-17 Thread Magnus Manske
On Fri, Aug 17, 2012 at 10:55 AM, Denny Vrandečić
 wrote:
> 
>
> If WMF had a Steve Jobs on staff, everyone would hate him for making
> decisions without properly consulting the community, for destroying
> the community, for reinventing Wikimedia again, for making unpopular
> decisions, for making decisions behind close doors, for being an
> egomaniac, etc.
>
> Heck, we cannot even get the branding right. We call our project
> Wikimedia Commons, Wikipedia, Wiktionary, Wikinews... we have a
> software called MediaWiki, and the whole movement is called the
> Wikimedia Movement. No surprise people think Wikileaks is one of ours.
> No surprise people cannot get these words right. There have been
> several suggestions for improving the branding, but every time met
> with strong resistance.
>
> I think Athena is a much more though-out design step for Wikipedia,
> and I am very much looking forward to it to happen. But as long as
> there is considerable backlash for something like a move from Monobook
> to Vector -- which, it seems, is not even regarded as a design update
> by most critics here -- I am wary about the social costs involved in
> such an update.
>
> 
>
> Yes, it would be nice if it was easier to change Wikipedia.

http://toolserver.org/~magnus/redefined/?page=Pyramid

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Apparently, Wikipedia is ugly

2012-07-16 Thread Magnus Manske
On Mon, Jul 16, 2012 at 6:43 PM, Andreas Kolbe  wrote:
> On Mon, Jul 16, 2012 at 2:15 PM, Magnus Manske
> wrote:
>
>> Well, you asked for volunteers... ;-)
>>
>> I started a tool that would let you change the CSS easily. Edit your
>> common.js user page and add (pardon the "Leif Ericsson" pun...) :
>>
>> importScript('MediaWiki:Live EriCSSon.js');
>>
>> Once that is done, you can use a URL parameter to use any Wikipedia
>> page with a CSS stylesheet.
>>
>> I also created a demo stylesheet called "explosion" (as in "exploded
>> view"), which, when used on top of vector on a wide (>1600px) screen,
>> uses a 900px central text column, with "floating" infoboxes,
>> thumbnails, and TOC on the side. With "Live EriCSSon", you can
>> test-drive the stylesheet, like so:
>>
>>
>> http://en.wikipedia.org/wiki/Biology?useCSS=User:Magnus_Manske/explosion.css
>>
>> And this is what it will look like:
>>
>>
>> https://commons.wikimedia.org/wiki/File:CSS_Stylesheet_explosion_demo_Biology.png
>>
>> All links to other wiki pages will automatically be extended with the
>> URL parameter, so you can browse Wikipedia with the stylesheet without
>> having to re-enter it on every page. Note that the original (vector)
>> stylesheet will initially show briefly on every page :-(
>>
>> If this is something people think useful, I'll add a way to select
>> from pre-defined stylesheet catalogs etc.
>>
>> Cheers,
>> Magnus
>
>
>
> Thanks Magnus, that looks really great. This is exactly the sort of
> alternative page design I was thinking of, and that we should enable people
> to select, especially if they have a large screen -- where the lines of
> text can end up excessively long, pictures become all bunched up, and the
> text flow gets messed up.
>
> Of course, ideally users shouldn't have to manually edit a .js file to
> obtain this result. They should just have to click a button somewhere that
> will do it for them. Editing .js files is clunky. It's like being back in
> DOS days. A programmer may take something like that in his stride, but most
> people in Wikimedia's target group will baulk at being asked to do
> something like that, and resent it.

If people generate some more CSS files to use with my little tool, it
could be loaded by default. Might need some polishing, though.

There's now a link in the toolbox where you can specify the CSS page
you want in a dialog box; you can even make it "permanent" (no need
for the URL parameter anymore).

> In fact, I had to laugh the other day, when I read a Wikimedia demographic
> survey. It literally said, "two-thirds of Wikipedia editors are not
> programmers". What an odd way of phrasing that!
>
> http://commons.wikimedia.org/w/index.php?title=File%3AEditor_Survey_Report_-_April_2011.pdf&page=19
>
> Surely, the interesting fact here that most people would have reported is
> the converse, i.e. that one-third of Wikipedia editors *are* programmers.
> That's far more than in the general population, and a huge demographic
> bias. In fact, the page says that "only" 36% can be classified as techies,
> and that 39% of male editors can program and create their own applications
> (vs. 18% of female editors).
>
> We need to be a lot friendlier to the non-programming public.

I believe we can do a lot in pure CSS/JavaScript, today, not 2015.
Backend support will, of course, always trump JS hacks in the long
run, though.

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Apparently, Wikipedia is ugly

2012-07-16 Thread Magnus Manske
Well, you asked for volunteers... ;-)

I started a tool that would let you change the CSS easily. Edit your
common.js user page and add (pardon the "Leif Ericsson" pun...) :

importScript('MediaWiki:Live EriCSSon.js');

Once that is done, you can use a URL parameter to use any Wikipedia
page with a CSS stylesheet.

I also created a demo stylesheet called "explosion" (as in "exploded
view"), which, when used on top of vector on a wide (>1600px) screen,
uses a 900px central text column, with "floating" infoboxes,
thumbnails, and TOC on the side. With "Live EriCSSon", you can
test-drive the stylesheet, like so:

http://en.wikipedia.org/wiki/Biology?useCSS=User:Magnus_Manske/explosion.css

And this is what it will look like:

https://commons.wikimedia.org/wiki/File:CSS_Stylesheet_explosion_demo_Biology.png

All links to other wiki pages will automatically be extended with the
URL parameter, so you can browse Wikipedia with the stylesheet without
having to re-enter it on every page. Note that the original (vector)
stylesheet will initially show briefly on every page :-(

If this is something people think useful, I'll add a way to select
from pre-defined stylesheet catalogs etc.

Cheers,
Magnus

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l