Re: [Wikitech-l] captcha idea: proposal for gnome outreach for women 14
On 28 February 2014 18:29, Brad Jorsch (Anomie) bjor...@wikimedia.orgwrote: On Fri, Feb 28, 2014 at 12:07 PM, Mansi Gokhale gokhalemans...@gmail.com wrote: Then there's the issue of different interpretation. Take for example https://www.mediawiki.org/wiki/File:Find-all-captcha-idea.png. Is the second image wearing glasses? Or is that a lorgnette or something like opera glasses, both of which are held in front of the eyes rather than worn? https://www.mediawiki.org/wiki/File:Find-the-different-captcha-idea.pnghas a similar problem. The first image is the only one with a cigarette, and the only one with non-realistic coloring. The second is the only bald one, and the only one with something resembling a lorgnette, and the only one not looking in the general direction of the camera, and the only one with a book. The fourth is the only child. The sixth is the only obvious female (I'm not sure about the cat). The eighth is the only one smiling, and the only one with visible teeth. I think this is oversimplifying. Of course some people can interpret a picture puzzle in slightly different ways - the whole *point* of a captcha is to distinguish between the intuitive reasoning of a human and the formulaic reasoning of a computer; if there was absolutely no ambiguity, it would be a very poor captcha. In exactly the same way that the letters on a captcha will sometimes be distorted in such a way that humans genuinely make a mistake, sometimes the questions in a picture puzzle can be sufficiently distorted to the point that they are answered incorrectly. The 'difficulty' of *any* captcha obviously needs to be carefully calibrated to hit the sweet spot between mundanity and ambiguity. But putting out nine pictures of humans and one picture of a cat and asking for the odd one out is no easier to misinterpret than a squiggle that might be a G or might be a 6. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC-2014 aspirant
https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page#10._Can_a_group_apply_for_and_work_on_a Can a group apply for and work on a single proposal? No, only an individual may work on a given project. Some Google Summer of Code mentoring organizations are fine with accepting multiple duplicate proposals (Student A and Student B separately implement the same functionality). Wikimedia is not fine with that and will only accept one proposal for a particular project idea. So if you and another student are interested in the same topic, I suggest that you TALK with the other student, talk with the mentor, and figure out which student done more preparation and is more interested in that idea. The student with less preparation and interest should choose a different topic. Sumana Harihareswara Engineering Community Manager Wikimedia Foundation On Mon, Mar 3, 2014 at 12:41 AM, Mark A. Hershberger m...@everybody.orgwrote: On 03/02/2014 10:03 AM, Karan Dev wrote: I was going through idea page and found interest in Catalogue for MediaWiki extensions. Please someone guide me where to start ? There is currently someone working on this project. I'm new to GSOC, so I don't know if you can pair up or not. If you can, would you be interested in that? Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] captcha idea: proposal for gnome outreach for women 14
On Fri, Feb 28, 2014 at 6:29 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: If you display 8 images and the user has to pick one, then even by random guessing the attacker has a 12.5% chance of passing the captcha. That's not good at all. Finding all matching is slightly better since it reduces the guessability (1/256 for 8 images), but still not very good. A traditional captcha using only A-Z is 1/308915776. To do as well with image picking, you'd need to ask the user to choose the matches from a set of about 28. Adding in numbers 2-9 is 1/1544804416, needing a set of about 31 images. The set of possible images also needs to be very large and the categorization private. https://www.mediawiki.org/wiki/Talk:Requests_for_comment/CAPTCHA#Issue:_image_classification_CAPTCHAs_need_a_secret_corpusgoes into much more detail on this issue. A recent example that springs to mind with image-based CAPTCHAs (instead of text) is Snapchat's Find the Ghost, which is very fun for users and apparently was broken very quickly.[1] A lot of times I hear people also suggest we try a honeypot on login/signup instead of text-based CAPTCHAs, and like the Snapchat example, one of the weaknesses here is just not accounting for that fact that people will target popular sites/apps directly. They'll inspect the DOM to find honeypots, they'll notice you use the same logo shape and use computer vision to find that shape, etc. However, it is not overstating it to say that the text-based CAPTCHA we use now is the single most frustrating part of creating an account or logging in (if you misremember your password, which users do all the time). To quote one of our usability tests during the last login/signup redesign: This is ridiculous. I can't even see this..[2] One simpler thing we might try and do right now is regenerate our current pool of CAPTCHAs to make them a bit less hard to read. We've done this kind of tweaking before without too much trouble I think?[3] 1. techcrunch.com/2014/01/21/snaptcha/ 2. https://www.mediawiki.org/wiki/Account_creation_user_experience/User_testing 3. See bug 43546 which Aaron Schulz kindly took care of. He may be able to elaborate more. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fw: Captcha Idea Proposal for GSOC 2014
From: Aalekh Nigamlt;aalekh1...@rediffmail.comgt; Sent: Sun, 02 Mar 2014 15:37:42 To: wikitech-l@lists.wikimedia.orglt;wikitech-l@lists.wikimedia.orggt; Cc: mediawiki-i...@lists.wikimedia.orglt;mediawiki-i...@lists.wikimedia.orggt; Subject: Captcha Idea Proposal for GSOC 2014 Hello, From last response on proosal for Multilingual, usable and effective captchas; i figured out following few solutions to the points raised by the mailing list members: 1)Captcha on the basis of selection of particular object:In this type of captcha the questions will be shown as shown here: https://commons.wikimedia.org/wiki/File:Proposal6correction.png ;other possible questions can be:Select the images in which man is wearing sunglasses,now problem i encountered while making such captcha request is that a bot could easily use Google images or third eye to find the look for images of man wearing sunglasses from the Wikimedia Commons .so to encounter this problem we can use a random numbering over the images and then ask user to to select the images in order of numbering for example the only answer to the sample question i provided above is :https://commons.wikimedia.org/wiki/File:Proposal7correction.png ;one of the wrong answer to the given question is:https://commons.wikimedia.org/wiki/File:Proposal8correction.png ; because it is not arranged in correct order which is 1,4,12 (in increasing numeric order).ps:i did forgot to specify increasing numeric order in the question i provided but the plan is to provide the question as Select human among the given photograph's and select it in increasing numeric order?. Providing increasing numeric order might make bot guess wrong answer 90% of time,which is quite comparable to the current captcha system that uses OCR as provided in the given algorithm: http://www.gizmag.com/captcha-beating-ai/29559/ . 2)Ask User to click on the same image as provided:The question for this type of captcha looks like this:https://commons.wikimedia.org/wiki/File:Proposal5correction.png we can ask user to click on the options showing equivalent image to that provided in the question.For the question provided the answer is :https://commons.wikimedia.org/wiki/File:Proposal9correction.png .Ps:we ca use more than four options probably eight options since it would be harder of bot to make a guess. 3)For blind and visually impaired users:We can use and audio captcha system which ask user to select the number as it is asked in the audio .For example the visual equivalent of the audio asked by the user will be : https://commons.wikimedia.org/wiki/File:Proposal11correction.png .Now when audio asked user to select number 0 our user will use arrow key to move across different blocks like a slide showwith different voice speaking out the options and pressing enter will select the word spokenhence verifying that the user is human.although the above shown image is visual equivalent the actual image visible will be: https://commons.wikimedia.org/wiki/File%3AProposal4correction.png ;to make the captcha reload we can user to by pressing key r which will be instructed in the audio while the captcha starts playing. Please give your response to idea provided and also the idea is listed here:https://www.mediawiki.org/wiki/Talk:CAPTCHA Thank You Aalekh Nigam aalekhN https://www.mediawiki.org/wiki/User:AalekhN -- Get your own FREE website, FREE domain amp; FREE mobile app with Company email. nbsp;Know More gt; ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Adding new property value in WIKIDATA (Lydia Pintscher)
Hi Thanks for the help. I want to create a new property only, and am quite clear that the existing properties can be edited with new values. The procedure is clear to me now. Thanks Lydia and GerardM for that ! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] captcha idea: proposal for gnome outreach for women 14
On Mon, Mar 3, 2014 at 6:05 AM, Happy Melon happy.melon.w...@gmail.comwrote: But putting out nine pictures of humans and one picture of a cat and asking for the odd one out is no easier to misinterpret than a squiggle that might be a G or might be a 6. It seems to me that putting nine pictures of humans and one picture of a cat is probably not much harder of a computer vision task than trying to determine which letter a particular squiggle corresponds to, either. (And that's leaving aside the fact that an 10% success rate for random guessing seems pretty bad for a captcha.) So naturally I thought that the real captchas would have a subtler level of intended oddness, so that the possibility for unintended oddness to confuse people would be greater. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drop support for PHP 5.3
Le 25/02/2014 23:02, Matthew Flaschen a écrit : A good number of SPL classes are available now (https://github.com/facebook/hhvm/tree/master/hphp/system/php/spl). I don't know if they all are. Tyler Romeo worked on some of this (https://github.com/facebook/hhvm/pull/807). Wonderful! I love how it is implementable using plain PHP. Another very important point is whether we want to actually use 5.4 new features. Reviewing the list of 5.3 new features: * namespaces : we did not see a good use case for them It's useful for extensions. That way, an extension doesn't have to worry about the names of core classes, or future extensions, and it doesn't have to have prefixes in the class name itself. I fully agree, it is definitely useful for extensions. For core there is less use though, we can always use Name_Spacing_Class class names. * Constants declared with 'const' : we use define() I've been using const. It's nicer syntax. It seems the two differences is that const can only be used at compile time and that define() let you create case insensitive constants. I guess we could migrate to const though there is no added value beside being 'const' being nicer. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drop support for PHP 5.3
Le 26/02/2014 04:05, Brad Jorsch (Anomie) a écrit : Is there a difference between Extension\ClassName and Extension_ClassName, collision-wise? i.e. if two extensions both use Extension as a namespace and define ClassName, what happens? I guess when in the namespace 'Extension' you can refer to 'ClassName' directly which saves a few keystrokes. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] python bot/script with javascript as frontend
*Hi* *How do I build a python bot/script with JavaScript for the frontend (ideally as Wikisouorce gadget https://www.mediawiki.org/wiki/Gadget).* *Project is for gsoc2014. So it should be something which can be live on wikisource gadgets.* *Thanks* *---* *Rohit Dua* *8ohit.dua* ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drop support for PHP 5.3
2014-02-18 19:14 GMT+01:00 Bryan Davis bd...@wikimedia.org: On Tue, Feb 18, 2014 at 10:54 AM, Tyler Romeo tylerro...@gmail.com wrote: On Tue, Feb 18, 2014 at 12:48 PM, Trevor Parscal tpars...@wikimedia.orgwrote: I propose we drop support for PHP 5.3 soon, if possible. Agreed, but right now both Debian oldstable and Ubuntu LTS are running on PHP 5.3. I'm pretty sure (last time I checked) that both reach their EOL sometime this summer, like in July or something. Once that happens we can safely stop supporting 5.3 with the next MediaWiki release. Ubuntu Server LTS versions have 5 years of support, so 12.04 will not be EOL until April of 2017. PHP 5.3 will be EOL in July of 2014. I'm sure that 3 year difference will be a major pain point for the Ubuntu security team. Also Ubuntu Server LTS 10.04 (aka Lucid Lynx) will EOF in April 2015. They have PHP 5.3.2 now (see also: https://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Version_timeline) Cristian (who had recently an issue with this since the latest CiviCRM versions require PHP = 5.3.3) -__-'' ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The Whole Wikipedia in English with pictures in one 40GB big file
Emmanuel, On 03/01/2014 09:01 AM, Emmanuel Engelhart wrote: Hi For the first time, we have achieved to release a complete dump of all encyclopedic articles of the Wikipedia in English, *with thumbnails*. this is great news. Congratulations! Gabriel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fw: Captcha Idea Proposal for GSOC 2014
From: Aalekh Nigamlt;aalekh1...@rediffmail.comgt; Sent: Mon, 03 Mar 2014 20:35:51 To: wikitech-l lt;wikitech-l@lists.wikimedia.orggt; Subject: Fw: Captcha Idea Proposal for GSOC 2014 From: Aalekh Nigamlt;aalekh1...@rediffmail.comgt; Sent: Sun, 02 Mar 2014 15:37:42 To: wikitech-l@lists.wikimedia.orglt;wikitech-l@lists.wikimedia.orggt; Cc: mediawiki-i...@lists.wikimedia.orglt;mediawiki-i...@lists.wikimedia.orggt; Subject: Captcha Idea Proposal for GSOC 2014 Hello, I have been posting my proposal for as many as nbsp;3 time within 24 hours on mailing list but there seems to be no reply from any members.please take few minutes out of your busy schedule and give your response to the projectthe points i raised here it could be interesing for community to discuss and also includes solution to the points which community is raising its concernin few previous mails.i sincerely request you all to please have a look at it. From last response on proosal for Multilingual, usable and effective captchas; i figured out following few solutions to the points raised by the mailing list members: 1)Captcha on the basis of selection of particular object:In this type of captcha the questions will be shown as shown here: https://commons.wikimedia.org/wiki/File:Proposal6correction.png ;other possible questions can be:Select the images in which man is wearing sunglasses,now problem i encountered while making such captcha request is that a bot could easily use Google images or third eye to find the look for images of man wearing sunglasses from the Wikimedia Commons .so to encounter this problem we can use a random numbering over the images and then ask user to to select the images in order of numbering for example the only answer to the sample question i provided above is :https://commons.wikimedia.org/wiki/File:Proposal7correction.png ;one of the wrong answer to the given question is:https://commons.wikimedia.org/wiki/File:Proposal8correction.png ; because it is not arranged in correct order which is 1,4,12 (in increasing numeric order).ps:i did forgot to specify increasing numeric order in the question i provided but the plan is to provide the question as Select human among the given photograph's and select it in increasing numeric order?. Providing increasing numeric order might make bot guess wrong answer 90% of time,which is quite comparable to the current captcha system that uses OCR as provided in the given algorithm: http://www.gizmag.com/captcha-beating-ai/29559/ . 2)Ask User to click on the same image as provided:The question for this type of captcha looks like this:https://commons.wikimedia.org/wiki/File:Proposal5correction.png we can ask user to click on the options showing equivalent image to that provided in the question.For the question provided the answer is :https://commons.wikimedia.org/wiki/File:Proposal9correction.png .Ps:we ca use more than four options probably eight options since it would be harder of bot to make a guess. 3)For blind and visually impaired users:We can use and audio captcha system which ask user to select the number as it is asked in the audio .For example the visual equivalent of the audio asked by the user will be : https://commons.wikimedia.org/wiki/File:Proposal11correction.png .Now when audio asked user to select number 0 our user will use arrow key to move across different blocks like a slide showwith different voice speaking out the options and pressing enter will select the word spokenhence verifying that the user is human.although the above shown image is visual equivalent the actual image visible will be: https://commons.wikimedia.org/wiki/File%3AProposal4correction.png ;to make the captcha reload we can user to by pressing key r which will be instructed in the audio while the captcha starts playing. Please give your response to idea provided and also the idea is listed here:https://www.mediawiki.org/wiki/Talk:CAPTCHA Thank You Aalekh Nigam aalekhN https://www.mediawiki.org/wiki/User:AalekhN -- Get your own FREE website, FREE domain amp; FREE mobile app with Company email. nbsp;Know More gt; Get your own FREE website, FREE domain amp; FREE mobile app with Company email. nbsp;Know More gt; ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fw: Captcha Idea Proposal for GSOC 2014
From: Aalekh Nigamlt;aalekh1...@rediffmail.comgt; Sent: Mon, 03 Mar 2014 23:39:19 To: wikitech-l@lists.wikimedia.orglt;wikitech-l@lists.wikimedia.orggt; Cc: mediawiki-i...@lists.wikimedia.orglt;mediawiki-i...@lists.wikimedia.orggt; Subject: Fw: Captcha Idea Proposal for GSOC 2014 From: Aalekh Nigamlt;aalekh1...@rediffmail.comgt; Sent: Mon, 03 Mar 2014 20:35:51 To: wikitech-l lt;wikitech-l@lists.wikimedia.orggt; Subject: Fw: Captcha Idea Proposal for GSOC 2014 From: Aalekh Nigamlt;aalekh1...@rediffmail.comgt; Sent: Sun, 02 Mar 2014 15:37:42 To: wikitech-l@lists.wikimedia.orglt;wikitech-l@lists.wikimedia.orggt; Cc: mediawiki-i...@lists.wikimedia.orglt;mediawiki-i...@lists.wikimedia.orggt; Subject: Captcha Idea Proposal for GSOC 2014 Hello, I have been posting my proposal for as many as nbsp;3 time within 24 hours on mailing list but there seems to be no reply from any members.please take few minutes out of your busy schedule and give your response to the projectthe points i raised here it could be interesing for community to discuss and also includes solution to the points which community is raising its concernin few previous mails.i sincerely request you all to please have a look at it. From last response on proosal for Multilingual, usable and effective captchas; i figured out following few solutions to the points raised by the mailing list members: 1)Captcha on the basis of selection of particular object:In this type of captcha the questions will be shown as shown here: https://commons.wikimedia.org/wiki/File:Proposal6correction.png ;other possible questions can be:Select the images in which man is wearing sunglasses,now problem i encountered while making such captcha request is that a bot could easily use Google images or third eye to find the look for images of man wearing sunglasses from the Wikimedia Commons .so to encounter this problem we can use a random numbering over the images and then ask user to to select the images in order of numbering for example the only answer to the sample question i provided above is :https://commons.wikimedia.org/wiki/File:Proposal7correction.png ;one of the wrong answer to the given question is:https://commons.wikimedia.org/wiki/File:Proposal8correction.png ; because it is not arranged in correct order which is 1,4,12 (in increasing numeric order).ps:i did forgot to specify increasing numeric order in the question i provided but the plan is to provide the question as Select human among the given photograph's and select it in increasing numeric order?. Providing increasing numeric order might make bot guess wrong answer 90% of time,which is quite comparable to the current captcha system that uses OCR as provided in the given algorithm: http://www.gizmag.com/captcha-beating-ai/29559/ . 2)Ask User to click on the same image as provided:The question for this type of captcha looks like this:https://commons.wikimedia.org/wiki/File:Proposal5correction.png we can ask user to click on the options showing equivalent image to that provided in the question.For the question provided the answer is :https://commons.wikimedia.org/wiki/File:Proposal9correction.png .Ps:we ca use more than four options probably eight options since it would be harder of bot to make a guess. 3)For blind and visually impaired users:We can use and audio captcha system which ask user to select the number as it is asked in the audio .For example the visual equivalent of the audio asked by the user will be : https://commons.wikimedia.org/wiki/File:Proposal11correction.png .Now when audio asked user to select number 0 our user will use arrow key to move across different blocks like a slide showwith different voice speaking out the options and pressing enter will select the word spokenhence verifying that the user is human.although the above shown image is visual equivalent the actual image visible will be: https://commons.wikimedia.org/wiki/File%3AProposal4correction.png ;to make the captcha reload we can user to by pressing key r which will be instructed in the audio while the captcha starts playing. Please give your response to idea provided and also the idea is listed here:https://www.mediawiki.org/wiki/Talk:CAPTCHA Thank You Aalekh Nigam aalekhN https://www.mediawiki.org/wiki/User:AalekhN -- Get your own FREE website, FREE domain amp; FREE mobile app with Company email. nbsp;Know More gt; Get your own FREE website, FREE domain amp; FREE mobile app with Company email. nbsp;Know More gt; Get your own FREE website, FREE domain amp; FREE mobile app with Company email. nbsp;Know More gt; ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fw: Captcha Idea Proposal for GSOC 2014
From: Aalekh Nigamlt;aalekh1...@rediffmail.comgt; Sent: Mon, 03 Mar 2014 20:35:51 To: wikitech-l lt;wikitech-l@lists.wikimedia.orggt; Subject: Fw: Captcha Idea Proposal for GSOC 2014 From: Aalekh Nigamlt;aalekh1...@rediffmail.comgt; Sent: Sun, 02 Mar 2014 15:37:42 To: wikitech-l@lists.wikimedia.orglt;wikitech-l@lists.wikimedia.orggt; Cc: mediawiki-i...@lists.wikimedia.orglt;mediawiki-i...@lists.wikimedia.orggt; Subject: Captcha Idea Proposal for GSOC 2014 Hello, From last response on proosal for Multilingual, usable and effective captchas; i figured out following few solutions to the points raised by the mailing list members: 1)Captcha on the basis of selection of particular object:In this type of captcha the questions will be shown as shown here: https://commons.wikimedia.org/wiki/File:Proposal6correction.png ;other possible questions can be:Select the images in which man is wearing sunglasses,now problem i encountered while making such captcha request is that a bot could easily use Google images or third eye to find the look for images of man wearing sunglasses from the Wikimedia Commons .so to encounter this problem we can use a random numbering over the images and then ask user to to select the images in order of numbering for example the only answer to the sample question i provided above is :https://commons.wikimedia.org/wiki/File:Proposal7correction.png ;one of the wrong answer to the given question is:https://commons.wikimedia.org/wiki/File:Proposal8correction.png ; because it is not arranged in correct order which is 1,4,12 (in increasing numeric order).ps:i did forgot to specify increasing numeric order in the question i provided but the plan is to provide the question as Select human among the given photograph's and select it in increasing numeric order?. Providing increasing numeric order might make bot guess wrong answer 90% of time,which is quite comparable to the current captcha system that uses OCR as provided in the given algorithm: http://www.gizmag.com/captcha-beating-ai/29559/ . 2)Ask User to click on the same image as provided:The question for this type of captcha looks like this:https://commons.wikimedia.org/wiki/File:Proposal5correction.png we can ask user to click on the options showing equivalent image to that provided in the question.For the question provided the answer is :https://commons.wikimedia.org/wiki/File:Proposal9correction.png .Ps:we ca use more than four options probably eight options since it would be harder of bot to make a guess. 3)For blind and visually impaired users:We can use and audio captcha system which ask user to select the number as it is asked in the audio .For example the visual equivalent of the audio asked by the user will be : https://commons.wikimedia.org/wiki/File:Proposal11correction.png .Now when audio asked user to select number 0 our user will use arrow key to move across different blocks like a slide showwith different voice speaking out the options and pressing enter will select the word spokenhence verifying that the user is human.although the above shown image is visual equivalent the actual image visible will be: https://commons.wikimedia.org/wiki/File%3AProposal4correction.png ;to make the captcha reload we can user to by pressing key r which will be instructed in the audio while the captcha starts playing. Please give your response to idea provided and also the idea is listed here:https://www.mediawiki.org/wiki/Talk:CAPTCHA Thank You Aalekh Nigam aalekhN https://www.mediawiki.org/wiki/User:AalekhN -- Get your own FREE website, FREE domain amp; FREE mobile app with Company email. nbsp;Know More gt; Get your own FREE website, FREE domain amp; FREE mobile app with Company email. nbsp;Know More gt; ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Drop support for PHP 5.3
On Mon, Mar 3, 2014 at 8:57 AM, Antoine Musso hashar+...@free.fr wrote: * Constants declared with 'const' : we use define() I've been using const. It's nicer syntax. It seems the two differences is that const can only be used at compile time and that define() let you create case insensitive constants. I guess we could migrate to const though there is no added value beside being 'const' being nicer. Another difference here is that HHVM performs additional optimizations, like replacing constants with their value at compile time rather than looking up at runtime, when run with production settings (RepoAuthoritative mode). IIUC hhvm only performs these optimizations on const's and not dynamically define()'d values. Its likely a small difference, but useful. Erik B. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [GSoC 2014] Proposal for page migration project under the Translate Extension
Hello everyone! I am Pratik Lahoti (User:BPositive) from Pune, India. I am willing to participate in the Google Summer of Code this year. I am interested in the project titled - Tools for mass migration of legacy translated wiki contenthttps://www.mediawiki.org/wiki/Summer_of_Code_2014#Tools_for_mass_migration_of_legacy_translated_wiki_content . My mentors for this project would be Niklas Laxströmhttps://wikimediafoundation.org/wiki/User:Nlaxstromand Federico Leva https://meta.wikimedia.org/wiki/User:Nemo_bis. With their help, I have drafted the first version of my proposal page. You can find it here: https://www.mediawiki.org/wiki/Extension:Translate/Mass_migration_tools Brief overview of the project: The MediaWiki Translate extensionhttps://www.mediawiki.org/wiki/Extension:Translatemakes the task of translation easier by providing a user-friendly interface that consists of text strings splitted into translation units. Non-translatable content like images are excluded from the process of translation. Though that makes the job easy with a rich editor supporting various languages, a lot of effort is required to prepare the page for translation, i.e, the page under question first needs to be converted into a format that would be recognized by the Translate extension. The process of preparing the page for translation needs to take into consideration various markupshttps://www.mediawiki.org/wiki/Help:Extension:Translate/Page_translation_administration#markupwhich becomes a tedious task when done manually. Plus, wikis have a lot of legacy content that still needs to be made translatable. Thus, with this motivation, the project aims to facilitate this conversion and thereby save manual time and effort. The tool developed would thus make the page translatable, and once that is done, it would import the translations (which were present before the page was made translatable) into the Translate extension. Thus, the entire process of importing translations which involved a significant amount of manual task gets automated by this project. The proposal page mentions the Project Outline and the approach/solution towards the problem statement. I am done with most of the sections and left with the Project Schedule (which I will finish off when everything is finalized). Please have a look at the proposal and give your valuable feedback/suggestions. While I have no problems in replying to the suggestions put forth over here, I would appreciate if you can do the same on the discussion pagehttps://www.mediawiki.org/wiki/Extension_talk:Translate/Mass_migration_toolsof the proposal, so that all the feedback is at one single place. Looking forward to the inputs from the community. -- Warm Regards, *Pratik Lahoti* User:BPositive https://www.mediawiki.org/wiki/User:BPositive ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] SpecialPage::getTitle deprecated?!
On 1 Mar 2014, at 22:35, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, Regarding https://github.com/wikimedia/mediawiki-core/blob/793f17481ea937275898c91b9ba3c92c5a3e908b/includes/specialpage/SpecialPage.php#L467-488 So now all extensions that want to retain compatibility with MediaWiki 1.22 and at the same time not have deprecation notices on 1.23 need to do an if-else for all calls to this method? That sucks big time. And for what? The old method is just forwarding to the new one. All this hassle for a rename? How about removing the wfDeprecated call and not annoying all extension maintainers? Cheers You can also use the MediaWiki release version number branches in the extension repositories. By default the extension distributor on mediawiki.org uses this already. Those branches are automatically cut when MediaWiki core is cut, so they should work fine with the MediaWiki core release they are associated with and you can move on in the master branch to react to changes in latest master. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
I spent most of Friday working on font evaluation with the designers. First
I presented them with a blind taste test of 10 potential body fonts. 7 of
them were FOSS fonts, 3 were commercial. Each one was used to render an
identical section of Lorem Ipsum text in a MedaWiki page. Each font was
given a style score based on readability, neutrality, and authority
(does the font look like it conveys reliable information). Interestingly,
of the 4 fonts that they preferred, 3 of them were the commercial fonts.
The only FOSS font that scored highly was Liberation Sans.
Next, I did a blind technical evaluation. For this, I used each of the 10
fonts to render combining diacritics, ties, and other obscure Unicode
features. Then I gave each font a score based on how many problems it had
rendering the characters.
Finally, I researched the installation base of each font, i.e. what
operating systems it is installed on by default and also gave scores for
this.
The results can be seen at
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
.
The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and
Liberation Sans, so I'm going to suggest that all of these fonts be
included in the body stack, with the preference order based on the style
scores. Although Liberation Sans and Helvetica Neue tied on the style
score, I'm going to suggest that Liberation Sans go first since it is a
FOSS font:
div#content {
font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial,
sans-serif;
}
Additional feedback is welcome.
Ryan Kaldari
On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
I came across Gerrit change 79948[1] today, which makes VectorBeta
use a pile of non-free fonts (with one free font thrown in at the end
as a sop). Is this really the direction we want to go, considering
that in many other areas we prefer to use free software whenever we
can?
Looking around a bit, I see this has been discussed in some back
corners[2][3] (no offense intended), but not on this list and I don't
see any place where free versus non-free was actually discussed rather
than being brought up and then seemingly ignored.
In case it helps, I did some searching through mediawiki/core and
WMF-deployed extensions for font-family directives containing non-free
fonts. The results are at
https://www.mediawiki.org/wiki/User:Anomie/font-family (use of
non-staff account intentional).
[1]: https://gerrit.wikimedia.org/r/#/c/79948
[2]:
https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#Arial.3F_18136
[3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=44394
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
Thanks for doing this research!
I notice that while Liberation Sans got a high score for appearance, it got
a very low technical score... Since it is a FOSS project
https://fedorahosted.org/liberation-fonts/ we should attempt to file bug
reports with Red Hat about any problems we discover, and/or post our
findings on the fedora-fonts mailing list.
-- brion
On Mon, Mar 3, 2014 at 11:57 AM, Ryan Kaldari rkald...@wikimedia.orgwrote:
I spent most of Friday working on font evaluation with the designers. First
I presented them with a blind taste test of 10 potential body fonts. 7 of
them were FOSS fonts, 3 were commercial. Each one was used to render an
identical section of Lorem Ipsum text in a MedaWiki page. Each font was
given a style score based on readability, neutrality, and authority
(does the font look like it conveys reliable information). Interestingly,
of the 4 fonts that they preferred, 3 of them were the commercial fonts.
The only FOSS font that scored highly was Liberation Sans.
Next, I did a blind technical evaluation. For this, I used each of the 10
fonts to render combining diacritics, ties, and other obscure Unicode
features. Then I gave each font a score based on how many problems it had
rendering the characters.
Finally, I researched the installation base of each font, i.e. what
operating systems it is installed on by default and also gave scores for
this.
The results can be seen at
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
.
The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and
Liberation Sans, so I'm going to suggest that all of these fonts be
included in the body stack, with the preference order based on the style
scores. Although Liberation Sans and Helvetica Neue tied on the style
score, I'm going to suggest that Liberation Sans go first since it is a
FOSS font:
div#content {
font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial,
sans-serif;
}
Additional feedback is welcome.
Ryan Kaldari
On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org
wrote:
I came across Gerrit change 79948[1] today, which makes VectorBeta
use a pile of non-free fonts (with one free font thrown in at the end
as a sop). Is this really the direction we want to go, considering
that in many other areas we prefer to use free software whenever we
can?
Looking around a bit, I see this has been discussed in some back
corners[2][3] (no offense intended), but not on this list and I don't
see any place where free versus non-free was actually discussed rather
than being brought up and then seemingly ignored.
In case it helps, I did some searching through mediawiki/core and
WMF-deployed extensions for font-family directives containing non-free
fonts. The results are at
https://www.mediawiki.org/wiki/User:Anomie/font-family (use of
non-staff account intentional).
[1]: https://gerrit.wikimedia.org/r/#/c/79948
[2]:
https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#Arial.3F_18136
[3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=44394
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
Ryan,
This is useful. Am I assuming accurately that you looked only at Latin
language fonts focused on English. Did you consider Google webfonts too.
I would be interested in reusing your test criteria for other language
fonts too. Thanks for your efforts so far.
Best
Alolita
On Mar 3, 2014 11:57 AM, Ryan Kaldari rkald...@wikimedia.org wrote:
I spent most of Friday working on font evaluation with the designers. First
I presented them with a blind taste test of 10 potential body fonts. 7 of
them were FOSS fonts, 3 were commercial. Each one was used to render an
identical section of Lorem Ipsum text in a MedaWiki page. Each font was
given a style score based on readability, neutrality, and authority
(does the font look like it conveys reliable information). Interestingly,
of the 4 fonts that they preferred, 3 of them were the commercial fonts.
The only FOSS font that scored highly was Liberation Sans.
Next, I did a blind technical evaluation. For this, I used each of the 10
fonts to render combining diacritics, ties, and other obscure Unicode
features. Then I gave each font a score based on how many problems it had
rendering the characters.
Finally, I researched the installation base of each font, i.e. what
operating systems it is installed on by default and also gave scores for
this.
The results can be seen at
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
.
The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and
Liberation Sans, so I'm going to suggest that all of these fonts be
included in the body stack, with the preference order based on the style
scores. Although Liberation Sans and Helvetica Neue tied on the style
score, I'm going to suggest that Liberation Sans go first since it is a
FOSS font:
div#content {
font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial,
sans-serif;
}
Additional feedback is welcome.
Ryan Kaldari
On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org
wrote:
I came across Gerrit change 79948[1] today, which makes VectorBeta
use a pile of non-free fonts (with one free font thrown in at the end
as a sop). Is this really the direction we want to go, considering
that in many other areas we prefer to use free software whenever we
can?
Looking around a bit, I see this has been discussed in some back
corners[2][3] (no offense intended), but not on this list and I don't
see any place where free versus non-free was actually discussed rather
than being brought up and then seemingly ignored.
In case it helps, I did some searching through mediawiki/core and
WMF-deployed extensions for font-family directives containing non-free
fonts. The results are at
https://www.mediawiki.org/wiki/User:Anomie/font-family (use of
non-staff account intentional).
[1]: https://gerrit.wikimedia.org/r/#/c/79948
[2]:
https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#Arial.3F_18136
[3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=44394
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
Brion,
Happy to ping the Fedora team on this bug. They participate in our Language
Summits which we organize with Red Hat India.
Best,
Alolita
On Mar 3, 2014 12:22 PM, Brion Vibber bvib...@wikimedia.org wrote:
Thanks for doing this research!
I notice that while Liberation Sans got a high score for appearance, it got
a very low technical score... Since it is a FOSS project
https://fedorahosted.org/liberation-fonts/ we should attempt to file bug
reports with Red Hat about any problems we discover, and/or post our
findings on the fedora-fonts mailing list.
-- brion
On Mon, Mar 3, 2014 at 11:57 AM, Ryan Kaldari rkald...@wikimedia.org
wrote:
I spent most of Friday working on font evaluation with the designers.
First
I presented them with a blind taste test of 10 potential body fonts. 7
of
them were FOSS fonts, 3 were commercial. Each one was used to render an
identical section of Lorem Ipsum text in a MedaWiki page. Each font was
given a style score based on readability, neutrality, and authority
(does the font look like it conveys reliable information). Interestingly,
of the 4 fonts that they preferred, 3 of them were the commercial fonts.
The only FOSS font that scored highly was Liberation Sans.
Next, I did a blind technical evaluation. For this, I used each of the 10
fonts to render combining diacritics, ties, and other obscure Unicode
features. Then I gave each font a score based on how many problems it had
rendering the characters.
Finally, I researched the installation base of each font, i.e. what
operating systems it is installed on by default and also gave scores for
this.
The results can be seen at
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
.
The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and
Liberation Sans, so I'm going to suggest that all of these fonts be
included in the body stack, with the preference order based on the
style
scores. Although Liberation Sans and Helvetica Neue tied on the style
score, I'm going to suggest that Liberation Sans go first since it is a
FOSS font:
div#content {
font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial,
sans-serif;
}
Additional feedback is welcome.
Ryan Kaldari
On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org
wrote:
I came across Gerrit change 79948[1] today, which makes VectorBeta
use a pile of non-free fonts (with one free font thrown in at the end
as a sop). Is this really the direction we want to go, considering
that in many other areas we prefer to use free software whenever we
can?
Looking around a bit, I see this has been discussed in some back
corners[2][3] (no offense intended), but not on this list and I don't
see any place where free versus non-free was actually discussed rather
than being brought up and then seemingly ignored.
In case it helps, I did some searching through mediawiki/core and
WMF-deployed extensions for font-family directives containing non-free
fonts. The results are at
https://www.mediawiki.org/wiki/User:Anomie/font-family (use of
non-staff account intentional).
[1]: https://gerrit.wikimedia.org/r/#/c/79948
[2]:
https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#Arial.3F_18136
[3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=44394
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
Ryan, thank you superlatively for doing and documenting this research. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
Yes, we only looked at Latin fonts. We are working on an FAQ, however, that
explains how wikis that use non-Latin scripts can specify their own font
stack using MediaWiki:Vector.css.
Ryan Kaldari
On Mon, Mar 3, 2014 at 12:26 PM, Alolita Sharma asha...@wikimedia.orgwrote:
Ryan,
This is useful. Am I assuming accurately that you looked only at Latin
language fonts focused on English. Did you consider Google webfonts too.
I would be interested in reusing your test criteria for other language
fonts too. Thanks for your efforts so far.
Best
Alolita
On Mar 3, 2014 11:57 AM, Ryan Kaldari rkald...@wikimedia.org wrote:
I spent most of Friday working on font evaluation with the designers.
First
I presented them with a blind taste test of 10 potential body fonts. 7
of
them were FOSS fonts, 3 were commercial. Each one was used to render an
identical section of Lorem Ipsum text in a MedaWiki page. Each font was
given a style score based on readability, neutrality, and authority
(does the font look like it conveys reliable information). Interestingly,
of the 4 fonts that they preferred, 3 of them were the commercial fonts.
The only FOSS font that scored highly was Liberation Sans.
Next, I did a blind technical evaluation. For this, I used each of the 10
fonts to render combining diacritics, ties, and other obscure Unicode
features. Then I gave each font a score based on how many problems it had
rendering the characters.
Finally, I researched the installation base of each font, i.e. what
operating systems it is installed on by default and also gave scores for
this.
The results can be seen at
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
.
The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and
Liberation Sans, so I'm going to suggest that all of these fonts be
included in the body stack, with the preference order based on the
style
scores. Although Liberation Sans and Helvetica Neue tied on the style
score, I'm going to suggest that Liberation Sans go first since it is a
FOSS font:
div#content {
font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial,
sans-serif;
}
Additional feedback is welcome.
Ryan Kaldari
On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org
wrote:
I came across Gerrit change 79948[1] today, which makes VectorBeta
use a pile of non-free fonts (with one free font thrown in at the end
as a sop). Is this really the direction we want to go, considering
that in many other areas we prefer to use free software whenever we
can?
Looking around a bit, I see this has been discussed in some back
corners[2][3] (no offense intended), but not on this list and I don't
see any place where free versus non-free was actually discussed rather
than being brought up and then seemingly ignored.
In case it helps, I did some searching through mediawiki/core and
WMF-deployed extensions for font-family directives containing non-free
fonts. The results are at
https://www.mediawiki.org/wiki/User:Anomie/font-family (use of
non-staff account intentional).
[1]: https://gerrit.wikimedia.org/r/#/c/79948
[2]:
https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#Arial.3F_18136
[3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=44394
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
Am 03.03.2014 21:38, schrieb Sumana Harihareswara: Ryan, thank you superlatively for doing and documenting this research. +1 -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
Thanks for the update Ryan and for investing your effort in this
considering the typography refresh it is a spare time project! I'm
excited to see the results.
What about headings? Are you going to run similar tests?
On Mon, Mar 3, 2014 at 11:57 AM, Ryan Kaldari rkald...@wikimedia.org wrote:
I spent most of Friday working on font evaluation with the designers. First
I presented them with a blind taste test of 10 potential body fonts. 7 of
them were FOSS fonts, 3 were commercial. Each one was used to render an
identical section of Lorem Ipsum text in a MedaWiki page. Each font was
given a style score based on readability, neutrality, and authority
(does the font look like it conveys reliable information). Interestingly,
of the 4 fonts that they preferred, 3 of them were the commercial fonts.
The only FOSS font that scored highly was Liberation Sans.
Next, I did a blind technical evaluation. For this, I used each of the 10
fonts to render combining diacritics, ties, and other obscure Unicode
features. Then I gave each font a score based on how many problems it had
rendering the characters.
Finally, I researched the installation base of each font, i.e. what
operating systems it is installed on by default and also gave scores for
this.
The results can be seen at
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
.
The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and
Liberation Sans, so I'm going to suggest that all of these fonts be
included in the body stack, with the preference order based on the style
scores. Although Liberation Sans and Helvetica Neue tied on the style
score, I'm going to suggest that Liberation Sans go first since it is a
FOSS font:
div#content {
font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial,
sans-serif;
}
Additional feedback is welcome.
Ryan Kaldari
On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
I came across Gerrit change 79948[1] today, which makes VectorBeta
use a pile of non-free fonts (with one free font thrown in at the end
as a sop). Is this really the direction we want to go, considering
that in many other areas we prefer to use free software whenever we
can?
Looking around a bit, I see this has been discussed in some back
corners[2][3] (no offense intended), but not on this list and I don't
see any place where free versus non-free was actually discussed rather
than being brought up and then seemingly ignored.
In case it helps, I did some searching through mediawiki/core and
WMF-deployed extensions for font-family directives containing non-free
fonts. The results are at
https://www.mediawiki.org/wiki/User:Anomie/font-family (use of
non-staff account intentional).
[1]: https://gerrit.wikimedia.org/r/#/c/79948
[2]:
https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#Arial.3F_18136
[3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=44394
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
On Mon, Mar 3, 2014 at 2:57 PM, Ryan Kaldari rkald...@wikimedia.org wrote: I spent most of Friday working on font evaluation with the designers. [...] given a style score based on readability, neutrality, and authority (does the font look like it conveys reliable information). What does neutrality mean in the context of a font? I'm having trouble figuring out what authority might actually mean besides Does this seem familiar to me from sites I use for reference?. Did they actually rate these separately, or was it just one number covering all three? Something this subjective could probably do with a much more diverse sample. Next, I did a blind technical evaluation. For this, I used each of the 10 fonts to render combining diacritics, ties, and other obscure Unicode features. Then I gave each font a score based on how many problems it had rendering the characters. It seems to me that the technical evaluation doesn't need to be blind, you just look at is the diacritic/tie/etc correctly positioned?. Are there any details on this technical evaluation? What exactly was tested, and in what ways did the fonts fail? Ideal IMO would be a table of images (or a big image laid out as a table). Were the technical results consistent across backends? -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
Hi everyone,
I wanted to give everyone an update from an in-person conversation I had
with Ryan (see...see...I do talk to people in person!) :-) Ryan and crew,
I'm really glad you all are following through with documentation and doing
all of the testing you are. Thank you!
If we're going to bias toward Liberation Sans based on the install base, we
need to make sure we're testing with the version of Liberation Sans which
is actually in widespread distribution in the context it'll be used
(Linux). I believe that is the 1.07.* for Ubuntu at least, and I think
that's true for the other Linux distros as well, due to some still
unresolved(?) hinting problems with Liberation Sans 2.00. This is made
tougher by the fact that I think Red Hat is distributing a font billed as
1.07 on their website, but I think is in fact 2.00 when you open up the
tarball. I'm not positive about this...I spent a lot of time on this a
couple weekends ago, and haven't touched it since, so I could be a bit
rusty on it and may have been misreading things. It may also be that
Liberation Sans 1.07.x has better diacritic support than Liberation Sans
2.00. Based on what Ryan showed me with 2.00, it's got a number of
technical issues.
In lieu of finding a reliable source to download Liberation Sans 1.07.x, I
sent Ryan a copy of 1.07.3 from my machine, which I believe he's in the
process of working with now.
Rob
On Mon, Mar 3, 2014 at 12:58 PM, Ryan Kaldari rkald...@wikimedia.orgwrote:
Yes, we only looked at Latin fonts. We are working on an FAQ, however, that
explains how wikis that use non-Latin scripts can specify their own font
stack using MediaWiki:Vector.css.
Ryan Kaldari
On Mon, Mar 3, 2014 at 12:26 PM, Alolita Sharma asha...@wikimedia.org
wrote:
Ryan,
This is useful. Am I assuming accurately that you looked only at Latin
language fonts focused on English. Did you consider Google webfonts too.
I would be interested in reusing your test criteria for other language
fonts too. Thanks for your efforts so far.
Best
Alolita
On Mar 3, 2014 11:57 AM, Ryan Kaldari rkald...@wikimedia.org wrote:
I spent most of Friday working on font evaluation with the designers.
First
I presented them with a blind taste test of 10 potential body fonts.
7
of
them were FOSS fonts, 3 were commercial. Each one was used to render an
identical section of Lorem Ipsum text in a MedaWiki page. Each font was
given a style score based on readability, neutrality, and authority
(does the font look like it conveys reliable information).
Interestingly,
of the 4 fonts that they preferred, 3 of them were the commercial
fonts.
The only FOSS font that scored highly was Liberation Sans.
Next, I did a blind technical evaluation. For this, I used each of the
10
fonts to render combining diacritics, ties, and other obscure Unicode
features. Then I gave each font a score based on how many problems it
had
rendering the characters.
Finally, I researched the installation base of each font, i.e. what
operating systems it is installed on by default and also gave scores
for
this.
The results can be seen at
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
.
The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and
Liberation Sans, so I'm going to suggest that all of these fonts be
included in the body stack, with the preference order based on the
style
scores. Although Liberation Sans and Helvetica Neue tied on the style
score, I'm going to suggest that Liberation Sans go first since it is a
FOSS font:
div#content {
font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial,
sans-serif;
}
Additional feedback is welcome.
Ryan Kaldari
On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org
wrote:
I came across Gerrit change 79948[1] today, which makes VectorBeta
use a pile of non-free fonts (with one free font thrown in at the end
as a sop). Is this really the direction we want to go, considering
that in many other areas we prefer to use free software whenever we
can?
Looking around a bit, I see this has been discussed in some back
corners[2][3] (no offense intended), but not on this list and I
don't
see any place where free versus non-free was actually discussed
rather
than being brought up and then seemingly ignored.
In case it helps, I did some searching through mediawiki/core and
WMF-deployed extensions for font-family directives containing
non-free
fonts. The results are at
https://www.mediawiki.org/wiki/User:Anomie/font-family (use of
non-staff account intentional).
[1]: https://gerrit.wikimedia.org/r/#/c/79948
[2]:
https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#Arial.3F_18136
[3]:
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
On Mar 3, 2014 4:58 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Yes, we only looked at Latin fonts. We are working on an FAQ, however, that explains how wikis that use non-Latin scripts can specify their own font stack using MediaWiki:Vector.css. Ryan Kaldari I dont think users should be responsible for that sort of thing. Could we do per-language css and only do this on en/other known good languages if we know that its going to be a bad choice for some languages? -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
On Mon, Mar 3, 2014 at 2:19 PM, Brian Wolff bawo...@gmail.com wrote: On Mar 3, 2014 4:58 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Yes, we only looked at Latin fonts. We are working on an FAQ, however, that explains how wikis that use non-Latin scripts can specify their own font stack using MediaWiki:Vector.css. Ryan Kaldari I dont think users should be responsible for that sort of thing. Could we do per-language css and only do this on en/other known good languages if we know that its going to be a bad choice for some languages? There are only a couple of languages in which we know this stack will be a bad choice (so far, Navajo and Vietnamese). In most languages that use non-Latin scripts, the font-family declaration will have little or no effect, but the readability will be improved by increasing the leading and font-size. Specifically the existing small leading is often a problem for Indic scripts and the existing small font-size is often a problem for logographic scripts. Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
Also with LESS we would be able to substitute the font variables on a per language basis with a little tweaking. This is pretty trivial to do and I'd suggest a reactionary approach. On Mon, Mar 3, 2014 at 2:33 PM, Ryan Kaldari rkald...@wikimedia.org wrote: On Mon, Mar 3, 2014 at 2:19 PM, Brian Wolff bawo...@gmail.com wrote: On Mar 3, 2014 4:58 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Yes, we only looked at Latin fonts. We are working on an FAQ, however, that explains how wikis that use non-Latin scripts can specify their own font stack using MediaWiki:Vector.css. Ryan Kaldari I dont think users should be responsible for that sort of thing. Could we do per-language css and only do this on en/other known good languages if we know that its going to be a bad choice for some languages? There are only a couple of languages in which we know this stack will be a bad choice (so far, Navajo and Vietnamese). In most languages that use non-Latin scripts, the font-family declaration will have little or no effect, but the readability will be improved by increasing the leading and font-size. Specifically the existing small leading is often a problem for Indic scripts and the existing small font-size is often a problem for logographic scripts. Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
On Mon, Mar 3, 2014 at 1:22 PM, Brad Jorsch (Anomie) bjor...@wikimedia.orgwrote: What does neutrality mean in the context of a font? I'm sure the designers could give a better explanation, but basically it means that the font doesn't have any noticeable tone, i.e. it isn't whimsical, cool, futuristic, timid, loud, pretentious, etc. In other words, is the font basically invisible, i.e. not distracting? This is an entirely subjective assessment, but apparently that's what designers are good at. I'm having trouble figuring out what authority might actually mean besides Does this seem familiar to me from sites I use for reference?. I think your description is probably entirely accurate. Did they actually rate these separately, or was it just one number covering all three? One number covering all three. Something this subjective could probably do with a much more diverse sample. Do you mean a more diverse sample of fonts, a more diverse sample of text, or a more diverse sample of evaluators? Next, I did a blind technical evaluation. For this, I used each of the 10 fonts to render combining diacritics, ties, and other obscure Unicode features. Then I gave each font a score based on how many problems it had rendering the characters. It seems to me that the technical evaluation doesn't need to be blind, you just look at is the diacritic/tie/etc correctly positioned?. True, I just made them blind for good measure :) Are there any details on this technical evaluation? What exactly was tested, and in what ways did the fonts fail? Ideal IMO would be a table of images (or a big image laid out as a table). You can see a sample from the technical tests in the file attached to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1072095 Sorry I don't have more documentation for that. Were the technical results consistent across backends? I haven't tested on different backends yet, but that's what part of what I was talking with Rob about today. Apparently the font hinting can cause significantly different rendering quality on different operating systems. Any help assessing this would be appreciated. Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mentors with two or more candidates interested (was GSOC-2014 aspirant)
On 03/03/2014 05:27 AM, Sumana Harihareswara wrote: https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page#10._Can_a_group_apply_for_and_work_on_a Can a group apply for and work on a single proposal? No, only an individual may work on a given project. Some Google Summer of Code mentoring organizations are fine with accepting multiple duplicate proposals (Student A and Student B separately implement the same functionality). Wikimedia is not fine with that and will only accept one proposal for a particular project idea. So if you and another student are interested in the same topic, I suggest that you TALK with the other student, talk with the mentor, and figure out which student done more preparation and is more interested in that idea. The student with less preparation and interest should choose a different topic. This is the rational approach, indeed recommended. Then some students opt for another approach, which is to run after the same project in pure competitive spirit. This is also allowed by the GSoC rules, although it is a risky game (you get all or nothing). Also a note to mentors: don't assume that the first student knocking your door is going to be the best one, or the one that deserves a priority. The advantage of early birds is to have more time to speak with mentors and prepare the project, which is indeed an advantage. However, considering your first student as selected while the deadline for submissions is still open might not be the best idea. Also note that even when a mentor consider a student selected, none of them should assume that the project will happen. Even in the best case scenario we will get a limited amount of slots, and other projects might end up filling all the seats. Therefore, mentors should treat all candidates as... candidates. Work with them and help them finding the best venue for them and for Wikimedia. Having two great students fighting for the same spot while there are other projects waiting for someone is a situation we should avoid. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
On Mon, Mar 3, 2014 at 1:22 PM, Brad Jorsch (Anomie) bjor...@wikimedia.orgwrote: What does neutrality mean in the context of a font? I'm having trouble figuring out what authority might actually mean besides Does this seem familiar to me from sites I use for reference?. These are not terms with a purely objective measurement Brad, even if they have a dictionary definition. It's a qualitative, subjective assessment. As a secondary part of the design goals (behind readability) is to convey these subjective qualities, you have to use a subjective measurement system. Something this subjective could probably do with a much more diverse sample. Agreed, it would be awesome if we could make a little Surveymonkey to let anyone do this blind test. Though I wouldn't necessarily trust Wikitech readers not to use browser devtools to cheat. ;-) A fun example of how similar qualities can be measured is the following experiment in trustworthiness of fonts: http://opinionator.blogs.nytimes.com/2012/08/08/hear-all-ye-people-hearken-o-earth/ I actually consulted our research and data team (Dario Taraborelli and Aaron Halfaker) about whether we should A/B test the beta with readers. Their reply was that a split test was not likely to produce statistically significant results in reader-related metrics like time on site, pageviews per unique visitor, etc. and that we have a great deal of trouble measuring these things with precision anyway. Producing a muddled and potentially flawed A/B test is much much worse than producing a small qualitative assessment that we know to take with a large grain of salt. :-) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
On Mon, Mar 3, 2014 at 6:14 PM, Ryan Kaldari rkald...@wikimedia.org wrote: One number covering all three. One thing I wonder about is the difference in style score for Arimo (5) and Liberation Sans (10). Apparently the only difference between the two is the hinting. Something this subjective could probably do with a much more diverse sample. Do you mean a more diverse sample of fonts, a more diverse sample of text, or a more diverse sample of evaluators? Evaluators. You can see a sample from the technical tests in the file attached to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1072095 Sorry I don't have more documentation for that. Interesting. In some local testing, it seems that Liberation Sans (1.07.3) isn't actually being used for any of the diacritics on [[en:User:Kaldari/Font_test]]. If I change the font-family to 'Liberation Sans', 'Unicode BMP Fallback SIL', 'sans-serif' and preview I get fallback characters on top of all the 'g's. OTOH, Liberation Sans with DejaVu Sans as a fallback (default sans-serif on my system) does better than your screenshot. Oddly, using Arimo as a fallback doesn't work very well. I haven't tested on different backends yet, but that's what part of what I was talking with Rob about today. Apparently the font hinting can cause significantly different rendering quality on different operating systems. Any help assessing this would be appreciated. If you tell me what exactly you want screenshots of, I can make screenshots for all the fonts on your list except Helvetica and Helvetica Neue with Debian's font renderer, in Firefox (really Iceweasel) and Chromium. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?
There are two very different versions of Liberation Sans, which makes testing somewhat complicated. Liberation Sans 1.0 has bad kerning and little support for extended Unicode. Liberation Sans 2.0 has great kerning and implements support for a lot more glyphs, but not always correctly. The version I used for the tests was 2.0, but according to robla, a lot of Linux distros have 1.0 (which might be a problem due to the bad kerning). I agree that Arimo should probably have the same style score as Liberation Sans. It has a very small installation base, but might still be worth considering for inclusion. Ryan Kaldari On Mon, Mar 3, 2014 at 4:54 PM, Brad Jorsch (Anomie) bjor...@wikimedia.orgwrote: On Mon, Mar 3, 2014 at 6:14 PM, Ryan Kaldari rkald...@wikimedia.org wrote: One number covering all three. One thing I wonder about is the difference in style score for Arimo (5) and Liberation Sans (10). Apparently the only difference between the two is the hinting. Something this subjective could probably do with a much more diverse sample. Do you mean a more diverse sample of fonts, a more diverse sample of text, or a more diverse sample of evaluators? Evaluators. You can see a sample from the technical tests in the file attached to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1072095 Sorry I don't have more documentation for that. Interesting. In some local testing, it seems that Liberation Sans (1.07.3) isn't actually being used for any of the diacritics on [[en:User:Kaldari/Font_test]]. If I change the font-family to 'Liberation Sans', 'Unicode BMP Fallback SIL', 'sans-serif' and preview I get fallback characters on top of all the 'g's. OTOH, Liberation Sans with DejaVu Sans as a fallback (default sans-serif on my system) does better than your screenshot. Oddly, using Arimo as a fallback doesn't work very well. I haven't tested on different backends yet, but that's what part of what I was talking with Rob about today. Apparently the font hinting can cause significantly different rendering quality on different operating systems. Any help assessing this would be appreciated. If you tell me what exactly you want screenshots of, I can make screenshots for all the fonts on your list except Helvetica and Helvetica Neue with Debian's font renderer, in Firefox (really Iceweasel) and Chromium. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: [Bug 7148] Requesting watchlist for changes to category content.
It would seem to me that the Collection extension, which provides 'books' for various sister projects, could be adapted for favorites: 'Book:Username' where a user can stick favorite articles and group by sections. https://www.mediawiki.org/wiki/Extension:Collection Thoughts? - Original message - From: bugzilla-dae...@wikimedia.org To: gryll...@fastmail.fm Subject: [Bug 7148] Requesting watchlist for changes to category content. Date: Sun, 02 Mar 2014 11:43:14 + https://bugzilla.wikimedia.org/show_bug.cgi?id=7148 --- Comment #32 from Subfader --- I hacked me around this by using favorites and filtering new pages by faved categories. Favorites is another thing MW misses... -- You are receiving this mail because: You voted for the bug. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Favorites for MW
OK, this was actually meant to have a more descriptive message subject. Ignore the previous message... - Original message - From: Gryllida To: wikitech-l Subject: Fwd: [Bug 7148] Requesting watchlist for changes to category content. Date: Tue, 04 Mar 2014 13:27:11 +1100 It would seem to me that the Collection extension, which provides 'books' for various sister projects, could be adapted for favorites: 'Book:Username' where a user can stick favorite articles and group by sections. https://www.mediawiki.org/wiki/Extension:Collection Thoughts? - Original message - From: bugzilla-dae...@wikimedia.org To: gryll...@fastmail.fm Subject: [Bug 7148] Requesting watchlist for changes to category content. Date: Sun, 02 Mar 2014 11:43:14 + https://bugzilla.wikimedia.org/show_bug.cgi?id=7148 --- Comment #32 from Subfader --- I hacked me around this by using favorites and filtering new pages by faved categories. Favorites is another thing MW misses... -- You are receiving this mail because: You voted for the bug. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Friday's quarterly review of the Foundation's Growth team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Growth/February_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@wikimedia.org wrote: Hi folks, to increase accountability and create more opportunities for course corrections and resourcing adjustments as necessary, Sue's asked me and Howie Fung to set up a quarterly project evaluation process, starting with our highest priority initiatives. These are, according to Sue's narrowing focus recommendations which were approved by the Board [1]: - Visual Editor - Mobile (mobile contributions + Wikipedia Zero) - Editor Engagement (also known as the E2 and E3 teams) - Funds Dissemination Committe and expanded grant-making capacity I'm proposing the following initial schedule: January: - Editor Engagement Experiments February: - Visual Editor - Mobile (Contribs + Zero) March: - Editor Engagement Features (Echo, Flow projects) - Funds Dissemination Committee We'll try doing this on the same day or adjacent to the monthly metrics meetings [2], since the team(s) will give a presentation on their recent progress, which will help set some context that would otherwise need to be covered in the quarterly review itself. This will also create open opportunities for feedback and questions. My goal is to do this in a manner where even though the quarterly review meetings themselves are internal, the outcomes are captured as meeting minutes and shared publicly, which is why I'm starting this discussion on a public list as well. I've created a wiki page here which we can use to discuss the concept further: https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We're slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
