Wikitech-l November 2012

wikitech-l@lists.wikimedia.org

130 participants
132 discussions

Re: [Wikitech-l] Fixing wikivoyage.com
by Erik Moeller 27 Nov '12

27 Nov '12

On Tue, Nov 27, 2012 at 4:37 AM, Roland Unger <roland.unger(a)soziologie.uni-halle.de> wrote: > we bought wikivoyage.com in September to transfer it to > the WMF. Since October 7, 2012 it is hosted at Hetzner > and shows to our association's servers. Hi Roland, yes, I'm aware - but it'd be good to point wikivoyage.com to the new site, or to update the nameservers to ns[0-2].wikimedia.org so we can do so, while we're waiting for the lock to expire. Having it point to the read-only old site is highly confusing. If nothing else, you could just disable it until it's transferred. Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

1 0

Re: [Wikitech-l] [Wikimediauk-l] AdBlock Plus wants to protect you from a malicious website, namely Wikimedia UK
by David Gerard 27 Nov '12

27 Nov '12

On 27 November 2012 21:58, rexx <rexx(a)blueyonder.co.uk> wrote: > The ability to turn this on or off for your browser is unfortunately hidden > away in a tab in the 'Filter preferences ...' of ABP. There's also an > individual whitelist there. It's probably worth reading the developer's blog > at http://adblockplus.org/blog/typo-correction-feature-in-adblock-plus for a > good overview of how it all works. It looks like this feature is rather too enthusiastic. metlife.com->fetlife.com ... - d.

1 0

Proposed new WMF browser support framework for MediaWiki
by James Forrester 27 Nov '12

27 Nov '12

All, *TL;DR: We're proposing a more formal, but more limited, statement of browser 'support' for the cluster; thoughts appreciated.* In WMF Engineering, we've been struggling with what we mean by 'supporting' browsers, and how we can match limited developer time to our natural desire to make everyone happy. Right now our 'support' for user agents varies between existing features and in particular between different developing products, but we lack a single framework in which to consistently express what works and - more importantly - what our users should expect to work. We have a chronically-misleading page on MWwiki<https://www.mediawiki.org/wiki/Compatibility#Browser> that currently claims we will support any browser which gives us more than 0.01% of users (an extremely-expensive claim) - this was changed in August<https://www.mediawiki.org/w/index.php?title=Compatibility&diff=571245&oldid…> from the 0.1% threshold you see around more often, or the 1% one that we started with. So, the new proposal: There would be a "top level" outline policy - a small number of browsers are supported (i.e., WMF will keep spending money until they work): * Desktop: Current and immediately-previous versions of Chrome, Firefox, MSIE and Safari * Tablet: Current versions of iOS/Safari; Current and immediately-previous ones of Android * Mobile: Current versions of iOS/Safari; Current and the five previous ones of Android[*] Anything not in this list may "happen to work" but WMF Engineering will not spend resources (read, developer time) on it. If a volunteer is willing to work like hell to make, say, the VisualEditor work in Opera we would try to support them by reviewing/accepting patches, but nothing more than that. It doesn't mean we would go out of our way to break previous browsers as they leave support, but we would not hold ourselves back from useful development solely because it might break browsers that we've actively decided not to support. Each piece of feature development and platform work would explicitly say whether it was to inherit this top-level policy or chose its own. This would be based on what technical needs the product has and the user goals/break-down. These product support policies would be reviewed by the team every now and then and can go further or less far than the main policy depending on circumstances - that's the decision of the team involved. For example, the Mobile team's work might want to go further and support mobile Opera, but might not care about breaking desktop support (as it's not a target for them). As another example, for "basic" functionality in Platform - I'm thinking specifically about just article-namespace reading, history viewing and diffing - we might well want to be very broad in our support, down even below the historic "0.1%" level. I have created a browser matrix<https://www.mediawiki.org/wiki/VisualEditor/2012-13_Q2_forward-look#Browser…> for VisualEditor to identify the browser support that our team will be able to provide. This is a table with ticks or crosses for support of grouped browsers, gated at the 0.1% threshold (so browsers used by fewer than 0.1% of our readers like IE 5.0 don't show up). This is now actually a template which is as not-ugly as you can make it in wikitext[+]; I'm happy to commit to updating its data every month as it's released so teams can create their own, though finding a way to get this created automatically would be nice too. So, to turn this mass of text into an 'ask', I would love the thoughts of this list about this. Do you think this might work? Is "making sure all the different parts of MediaWiki keep working with <browser I love>" something you'd see yourself volunteering to do? I'd be happy to talk through the individual browser-level decisions but it might be easier to agree that we want to focus browser support before we decide the exact focus of this. :-) That said, do you think we should support fewer browsers than those I've proposed (and if so, which and why)? Different ones (again, why)? More (and if so, what do you propose we stop doing instead)? Feedback would be very helpful. [*] - This is what is meant when people bemoan "Android fragmentation". [+] - Ironically for a page about the VisualEditor, creating wikitext that it will likely forever struggle to edit. J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

20 34

outreach program for women
by Navdeep Bagga 27 Nov '12

27 Nov '12

Hello I am new in wikimedia. I want to participate in opw Please assign me some project so that I can send application before 3 dec. Thanking you -- Navdeep Bagga Happy Bird [W] http://navdeepbagga.com [T] http://www.navdeepbagga.com/category/daily-diary-3/

3 5

Quick "show of hands": Adam Hyde guest talk
by Erik Moeller 27 Nov '12

27 Nov '12

Adam Hyde from the booktype project will be in San Francisco in the week of 12/10-12/14, so could potentially do an in-person brown bag with remote participation on Thursday 12/13 in our usual weekly chat time slot. booktype is doing some interesting open source work to create book quality rendering in the browser using open web technologies like CSS regions, see BookJS: http://bookjs.net/ Some of this could be relevant to the future of MediaWiki technologies that serve the same purpose (e.g. an alternative to the current PediaPress mwlib library). I'll ask him to do this in our weekly time slot if I can get at least 5 additional sign-ups here by the end of the week: https://www.mediawiki.org/wiki/Meetings/Guest_speakers Cheers, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

1 0

Help identifying false new contributors
by Quim Gil 26 Nov '12

26 Nov '12

Hi, I'm planning to release the November community metrics report [1] next week. In order to have more accurate stats on new contributors, can you help checking these names? It would be great if you are/know the false new contributor and you would claim the new commits to your Ohloh username. Note that an old contributor (e.g. in MediaWiki) is still a new contributor if sends a patch for the first time to e.g. Visual Editor. The problem comes when "old" editors in a project change the email address or name, because then Ohloh plays safe and considers them a new contributor. Thank you for your help. MediaWiki https://www.ohloh.net/p/mediawiki/contributors?highlight_key=first_checkin&… S Page, Amire80, Anomie, MarkAHershberger, Asher, Tpt, burthsceh, Stephan Gambke. MediaWiki extensions supported by WMF https://www.ohloh.net/p/mediawiki-extensions-wmf/contributors?highlight_key… jeblad, lwelling, Matthew Walker, Inez, Bharat Kumar Jonnalagadda, Anomia, Merlijn van Deen. MediaWiki extensions hosted by WMF https://www.ohloh.net/p/mediawiki-extensions-wmf-hosted/contributors?highli… Jérémie Roquet, Hydriz. Wikimedia Puppet https://www.ohloh.net/p/wikimedia-puppet/contributors?highlight_key=first_c… Silke Meyer Wikibase https://www.ohloh.net/p/wikibase/contributors?highlight_key=first_checkin&t… Jérémie Roquet, Liangent, Tpt, Hashar. Parsoid https://www.ohloh.net/p/Parsoid/contributors?highlight_key=first_checkin&ti… Iweilling VisualEditor https://www.ohloh.net/p/VisualEditor/contributors?highlight_key=first_check… raymond, Inez. Education Program https://www.ohloh.net/p/educationprogram/contributors?highlight_key=first_c… Eloquence -- Quim Gil Technical Contributor Coordinator Wikimedia Foundation

4 4

Please take this survey about new contributors
by Quim Gil 26 Nov '12

26 Nov '12

Hi, if you joined the MediaWiki / Wikimedia tech community in 2010 or later please consider taking this survey: Newcomer experience and contributor behavior in FOSS communities https://limesurvey.sim.vuw.ac.nz/index.php?sid=65151&lang=en The survey is open for sporadic contributors or full time Wikimedia employees, developers or any other profile. Anybody is welcome to leave their feedback as long as you have started contributing to this community in the past 3 years. 11 mature and well established open source projects are taking part in this survey: Debian, FreeBSD, GNOME, Gentoo, KDE, Mozilla, NetBSD, OpenSUSE, Python, Ubuntu and Wikimedia. Some of them started some days ago and have more than hundred responses by now. The data of this survey is anonymous and will be released under a ‘share-alike’ Open Data Commons Open Database License (ODbL). Some background: >From Kevin Carillo, the researcher: http://kevincarillo.org/survey-invitation/ >From OpenHatch, a non-profit working on the bridge between free software projects and new contributors: https://openhatch.org/blog/2012/a-research-project-to-understand-what-does-… PLEA If you, like me, became a bit tired of survey requests like this please consider filling this one anyway. It focuses in a specific area where we don't have much data. As fresh technical contributor coordinator at the WMF I'm looking forward to the results of this research and the lessons it will bring. Thank you. :) -- Quim Gil Technical Contributor Coordinator Wikimedia Foundation

2 3

Extensions to include in the 1.21 tarball/installer
by Federico Leva (Nemo) 26 Nov '12

26 Nov '12

TL;DR: Please add feedback to <https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated> Since MediaWiki 1.20 has been released, a discussion (opened by hexmode) is ongoing on how to make our release notes better so that users understand what improvements there are and why they should update: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/65080 (please join if you didn't yet). Another problem, however, is making the tarball, which is what most sites use, actually useful. After the first in 1.18, no more extensions have been bundled: Wikimedia projects use no less than 140 extension (most of them functioning) but the tarball ships only 7. A problem that many MediaWiki users have is that they don't understand how vital many extension are, at least for any wiki open to the web. I'd like 1.21 to include some more, so I ask you to join the brainstorming on our good old <https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated> There are already a few suggestions on it; my personal pet peeve is that MediaWiki is perhaps the software with the best localisation existing but very few use it well because we don't ship LocalisationUpdate. Topic for another discussion would be to solve some problems with the installer/upgrader like "set up cron for TorBlock" (?) or "check the compatibility of extensions"... Nemo

1 0

Re: [Wikitech-l] [Wikimediauk-l] AdBlock Plus wants to protect you from a malicious website, namely Wikimedia UK
by John Vandenberg 26 Nov '12

26 Nov '12

I received the same error when I visited http://incubator.wikimedia.org/ , suggesting that I wanted to go to incubator.wikipedia.org , and asking if I wanted to block wikimedia.org On Sat, Nov 24, 2012 at 11:46 PM, Andy Mabbett <andy(a)pigsonthewing.org.uk> wrote: > On 24 November 2012 16:41, Tom Morris <tom(a)tommorris.org> wrote: > >> AdBlock Plus has a facility to protect users from typosquatting >> (as in, typing "poopal.com" rather than "paypal.com") >> >> http://cl.ly/image/0M1l1D0K1x0g > > Ouch. > >> Does someone want to work out how to complain to the relevant parties? > > Is there no facility to report false positives on their website? > > -- > Andy Mabbett > @pigsonthewing > http://pigsonthewing.org.uk > > _______________________________________________ > Wikimedia UK mailing list > wikimediauk-l(a)wikimedia.org > http://mail.wikimedia.org/mailman/listinfo/wikimediauk-l > WMUK: http://uk.wikimedia.org -- John Vandenberg

2 1

Question about 2-phase dump
by vitalif＠yourcmc.ru 25 Nov '12

25 Nov '12

Hello! While working on my improvements to MediaWiki Import&Export, I've discovered a feature that is totally new for me: 2-phase backup dump. I.e. the first pass dumper creates XML file without page texts, and the second pass dumper adds page texts. I have several questions about it - what it is intended for? Is it a sort of optimisation for large databases and why such method of optimisation was chosen? Also, does anyone use it? (does Wikimedia use it?)

4 7

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l November 2012