Wikitech-l March 2014

wikitech-l@lists.wikimedia.org

188 participants
231 discussions

Welcome Chase Pettet to the Wikimedia Operations Team
by Mark Bergsma 11 Mar '14

11 Mar '14

I'm very pleased to announce that Chase Pettet is joining the Wikimedia Foundation as Operations Engineer. Chase comes to us from DeviantArt, where he was responsible for their general server management infrastructure, monitoring and networking, as well as supporting the development team(s). Within Wikimedia Operations he will have similar responsibilities, working on Operations infrastructure projects and supporting other Engineering teams with their Operations needs. Chase will be working remotely from his home in Missouri. He started with us yesterday. Please join me in welcoming Chase! — Mark Bergsma <mark(a)wikimedia.org> Lead Operations Architect Director of Technical Operations Wikimedia Foundation

2 1

GSoC and FOSS OPW gates open + IRC meeting
by Quim Gil 11 Mar '14

11 Mar '14

Hi, Starting today, candidates of Google Summer of Code and FOSS Outreach for Women can submit their proposals officially. See https://www.mediawiki.org/wiki/Summer_of_Code_2014 https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_8 We are hosting an IRC meeting to answer the questions of candidates and mentors tomorrow Tuesday, March 11, at 15:00 UTC (New Delhi 20:30, Amsterdam 16:00, San Francisco 8:00 AM). http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140311T08&p1=224… As Wikimedia did in previous rounds, we are extending the rules of these projects with a requirement on transparency. All candidates must draft their proposals in mediawiki.org pages, and they must list themselves in the tables of candidates at the pages linked above. This allows the whole community to watch and get involved in discussions at the related wiki pages, Bugzilla reports, and this list. Please keep an eye to new submissions. Whoever you are, your feedback is welcome. Candidates must submit their proposals directly to GSoC and OPW as well, but thanks to our application template this shouldn't imply more work that copy & paste: https://www.mediawiki.org/wiki/Mentorship_programs/Application_template This time we also have many new mentors. Please get familiar with the timeline of the programs. Your most important task now is to assess your candidates, based on their proposal but also on practical assignments like fixing real bugs related to their projects. By April 7 we will communicate to Google how many slots we want, based on the projects proposed that we believe that can succeed. This year the definition of success will be based on measurable outcome: new feature functional, merged, and deployed in Wikimedia Labs at least. Candidates and mentors willing to pass the cut must work with this goal in mind. Cmpared with last year, we will focus more on the quality of the projects, not worrying about the quantity of projects we get. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 2

GSoC Proposal : Simultaneous Modification of Multiple Pages with Semantic Forms
by Pawan 10 Mar '14

10 Mar '14

Hi, I am Pawan Kumar D. I am a final year Computer Sciene student from IIT Roorkee, India. More info on me can be found my user page<https://www.mediawiki.org/wiki/User:Pawanseerwani_1> . I intend to work on a GSoC project under this organization. I have made a proposal for the following project : Simultaneous Modification of Multiple Pages with Semantic Forms<https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014#Simultaneous_Modi…> Do go through the project . I would be happy to answer any queries or suggestion on the project here but I would appreciate if it could be done at the corresponding discussion page<https://www.mediawiki.org/wiki/User_talk:Pawanseerwani_1/GSoC_proposal> so that its all at one place and can be easily accessible. Thanks, Pawan kumar D IIT Roorkee ᐧ

2 2

[GSoC 2014] Proposal for page migration project under the Translate Extension
by Pratik Lahoti 10 Mar '14

10 Mar '14

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 content<https://www.mediawiki.org/wiki/Summer_of_Code_2014#Tools_for_mass_migration…> ". My mentors for this project would be Niklas Laxström<https://wikimediafoundation.org/wiki/User:Nlaxstrom>and 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 extension<https://www.mediawiki.org/wiki/Extension:Translate>makes 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 markups<https://www.mediawiki.org/wiki/Help:Extension:Translate/Page_translation_ad…>which 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 page<https://www.mediawiki.org/wiki/Extension_talk:Translate/Mass_migration_tools>of 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>

2 3

Bugzilla Weekly Report
by reporter＠zirconium.wikimedia.org 09 Mar '14

09 Mar '14

MediaWiki Bugzilla Report for March 03, 2014 - March 10, 2014 Status changes this week Reports changed/set to UNCONFIRMED: 5 Reports changed/set to NEW : 13 Reports changed/set to ASSIGNED : 41 Reports changed/set to REOPENED : 5 Reports changed/set to PATCH_TO_RE: 72 Reports changed/set to RESOLVED : 244 Reports changed/set to VERIFIED : 23 Total reports still open : 14072 Total bugs still open : 8280 Total non-lowest prio. bugs still open: 8075 Total enhancements still open : 5792 Reports created this week: 330 Resolutions for the week: Reports marked FIXED : 177 Reports marked DUPLICATE : 25 Reports marked INVALID : 14 Reports marked WORKSFORME: 12 Reports marked WONTFIX : 14 Specific Product/Component Resolutions & User Metrics Created reports per component MediaWiki extensions WikidataRepo 26 MediaWiki extensions Flow 18 VisualEditor Editing Tools 16 Wikimedia Site requests 12 MediaWiki General/Unknown 10 Created reports per product MediaWiki extensions 117 Wikimedia 54 MediaWiki 53 VisualEditor 34 Wikimedia Labs 28 Top 5 bug report closers jforrester [AT] wikimedia.org 48 mpinchuk [AT] wikimedia.org 20 jrobson [AT] wikimedia.org 16 neverett+bugzilla [AT] wikimed13 aklapper [AT] wikimedia.org 11 Most urgent open issues Product | Component | BugID | Priority | LastChange | Assignee | Summary -------------------------------------------------------------- MediaWiki | Database | 32551 | Highest | 2014-03-07 | wikibugs-l[AT]lists. | Descriptionless files MediaWiki ext | CirrusSearch | 62077 | Highest | 2014-02-28 | wikibugs-l[AT]lists. | CirrusSearch: Add monitoring for slo MediaWiki ext | Echo | 53569 | Highest | 2014-02-26 | wikibugs-l[AT]lists. | [Regression] Echo: Sending 2 e-mails MediaWiki ext | OAuth | 57336 | Highest | 2014-02-06 | wikibugs-l[AT]lists. | Make metawiki the central OAuth wiki MediaWiki ext | WikidataClien | 62149 | Highest | 2014-03-07 | wikidata-bugs[AT]lis | Wikidata changes don't show up in wat MediaWiki ext | WikidataRepo | 57918 | Highest | 2014-01-13 | wikidata-bugs[AT]lis | show diffs for sorting changes MediaWiki ext | WikidataRepo | 60127 | Highest | 2014-01-17 | wikidata-bugs[AT]lis | Implement DB schema for query indexes MediaWiki ext | WikidataRepo | 58166 | Highest | 2014-02-26 | wikidata-bugs[AT]lis | label/description uniqueness constrai MediaWiki ext | WikidataRepo | 52385 | Highest | 2014-03-05 | wikidata-bugs[AT]lis | Query by one property and one value ( MediaWiki ext | WikidataRepo | 62425 | Immediate | 2014-03-09 | wikidata-bugs[AT]lis | wbeditentity permits claim property t VisualEditor | Editing Tools | 50768 | Highest | 2014-03-05 | tparscal[AT]wikimedi | VisualEditor: Implement a better vers Wikimedia | Continuous in | 46723 | Highest | 2014-03-05 | hashar[AT]free.fr | Jenkins merged a faulty change Wikimedia | Deployment sy | 62262 | Highest | 2014-03-06 | bdavis[AT]wikimedia. | mw-update-l10n fail on beta because m Wikimedia | Deployment sy | 61970 | Highest | 2014-03-07 | wikibugs-l[AT]lists. | Directory permissions in /src/scap in Wikimedia Lab | Infrastructur | 48501 | Highest | 2014-02-21 | greg[AT]wikimedia.or | beta: Get SSL certificates for *.{pro

1 0

(no subject)
by Maduranga Siriwardena 09 Mar '14

09 Mar '14

Hi all, I'm Maduranga Siriwardena, 3rd year computer Science and Engineering Undergraduate at University of Moratuwa, Sri Lanka. Currently I'm in my internship at WSO2, which a opensource middleware company. While going through the project ideas, the idea of "A system for reviewing funding requests" impressed me. But as I'm new to the wikimedia project, I don't have much idea how to proceed. Please describe the requirements of the project and other requirements needed to proceed with this project. Thank you -- Maduranga Siriwardena Undergraduate University of Moratuwa, Faculty of Engineering Department of Computer Science and Engineering

1 0

Re: [Wikitech-l] Gerrit Commit Wars
by Jon Robson 09 Mar '14

09 Mar '14

I don't even know what the purpose of this thread is now. Seems to be discussion about development practices, badgering and various other things. I started two other threads to try and break out these important conversations but looks like conversation is still happening here so I guess that failed. I figure a lot of people have muted this thread now (myself included now). It would be great if we could turn all this anger and frustrations into solutions to fix some of the root issues here. My personal opinion is I doubt any of this will happen on this thread. On 8 Mar 2014 22:04, "Ryan Lane" <rlane32(a)gmail.com> wrote: > On Sat, Mar 8, 2014 at 9:34 PM, MZMcBride <z(a)mzmcbride.com> wrote: > > > Chad wrote: > > > On Mar 8, 2014 1:42 PM, "Brandon Harris" <bharris(a)wikimedia.org> > wrote: > > >>https://en.wikipedia.org/wiki/Badger > > > > > >New rule: calling badger is synonymous with asking for the moderation > bit > > >for yourself. > > > > Fine, but first we have to ban the people who top-post and don't trim > > unnecessary parts of their e-mails. :-) > > > > I personally read the badger link as a politer(?) version of calling > > someone a troll. > > > > > It's actually something used on WMF staffer lists and it's supposed to be a > cute way of telling people a thread is getting out of hand. Some people use > it that way, and I feel Brandon was in this case, but it's most often used > to shut down conversations that people find unpleasant or controversial and > its actual effect is usually to enrage those it's used against. > > I'd wager it has an overwhelmingly negative effect on communication (and > WMF's internal politics likely prove that) and I'm with Chad in saying > anyone that uses it here should be moderated. This is of course off topic, > so I'll leave this at that. > > - Ryan > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Multimedia team architecture update
by Gergo Tisza 09 Mar '14

09 Mar '14

Hi all, the multimedia team [1] had a chat about some architectural issues with MultimediaViewer [2] today, and Robla has pointed out that we should publish such discussions on wikitech-l to make sure we do no reinvent to many wheels, so here goes. Comments pointing out all the obvious solutions we have missed are very welcome. == Use of OOjs-UI == Mark experimentally implemented a panel showing share/embed links [3][4] in OOjs-UI [5]; we discussed some concerns about that. We want to avoid having to roll our own UI toolkit, and also don't want to introduce yet another third-party toolkit as the list of libraries loaded by some Wikipedia extension or other is already too long, and the look-and-feel already too fractured, so we would be happy to free-ride on another team's efforts :) On the other hand, OOjs-UI is still under development, does not have tests and has very little documentation, and the browser support is less than we would prefer. We could contribute back in those areas, but it would slow us down significantly. In the end we felt that's not something we should decide on our own as it involves redefining the goals of the team somewhat (it was a developer-only meeting), so we left it open. (The next MultimediaViewer features which would depend heavily on a UI toolkit are a few months away, so it is not an urgent decision for us.) == The state of unit tests == MultimediaViewer used to have a messy codebase; we felt at the time that it is better to have ugly tests than no tests, so we ended up with some large and convoluted tests which are hard to maintain. Since then we did a lot of refactoring but kept most of the tests, so now we have some tests which are harder to understand and more effort to maintain than the code they are testing. Also, we fixed failing tests after the refactorings, but did not check the working ones, we cannot be sure they are still testing what they are supposed to. We discussed these issues, and decided that writing the tests was still a good decision at the time, but once we are done with the major code refactorings, we should take some time to refactor the tests as well. Many of our current tests test the implementation of a class; we should replace them with ones that test the specification. == Plugin architecture == We had plans to create some sort of plugin system so that gadgets can extend the functionality of MultimediaViewer [6]; we discussed whether that should be an open model where it is possible to alter the behavior of any component (think Symfony2 or Firefox) and plugins are not limited in their functionality, or a closed model where there are a limited number of junction points where gadgets can influence behavior (think MediaWiki hook system, just much more limited). The open model seems more in line with Wikimedia philosophy, and might actually be easier to implement (most of it is just good architecture like services or dependency injection which would make sense even if we did not want plugins); on the other hand it would mean a lot of gadgets break every time we change things, and some possibly do even if we don't. Also, many the community seems to have much lower tolerance for breakage in WMF-maintained tools breaking than in community-maintained tools, and most people probably wouldn't make the distinction between MultimediaViewer breaking because it is buggy and it breaking because a gadget interacting with it is buggy, so giving plugins enough freedom to break it might be inviting conflict. Some sort of hook system (with try-catch blocks, strict validation etc) would be much more stable, and it would probably require less technical expertise to use, but it could prevent many potential uses, and forces us to make more assumptions about what kind of plugins people would write. Decision: go with the closed model; reach out for potential plugin writers and collect requirements; do not guess, only add plugin functionality where it is actually requested by someone. In general try not to spend too much effort on it, having a useful plugin system by the time MultimediaViewer is deployed publicly is probably too ambitious a goal. [1] https://www.mediawiki.org/wiki/Multimedia [2] https://www.mediawiki.org/wiki/Extension:MultimediaViewer [3] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/147 [4] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/148 [5] https://www.mediawiki.org/wiki/OOjs_UI [6] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/168

9 13

Re: [Wikitech-l] Gerrit Commit Wars
by Lee Worden 08 Mar '14

08 Mar '14

On 03/08/2014 02:10 PM, Isarra Yos <zhorishna(a)gmail.com> wrote: > On 08/03/14 09:15, Niklas Laxström wrote: >> Please do not forget the contributors who want to improve MediaWiki >> for their own needs. We also have to balance how much we inconvenience >> them to meet the requirements of WMF. In my opinion, the balance is >> already in favor of WMF. >> >> -Niklas > > This. > > MediaWiki serves many interests, and it's already hard enough for > third-party users to contribute their features/improvements upstream > that most simply don't even try. We should be trying to improve this, > not make it even worse for them, because these are often things that > would prove widely useful even if they are not /currently/ WMF > priorities (it is not uncommon for them later become such and then have > to be completely reimplemented). +1. BTW, anyone care to have a look at https://gerrit.wikimedia.org/r/#/c/67173/3 ? :) (It's been sitting around for a good while, and it would make my life tons easier if it could get into the 1.23 LTS.) LW

1 0

Re: [Wikitech-l] [Offline-l] The Whole Wikipedia in English with pictures in one 40GB big file
by Emmanuel Engelhart 08 Mar '14

08 Mar '14

Le 07/03/2014 19:25, Asaf Bartov a écrit : > btw, are these new improved tools documented anywhere? > http://kiwix.org/wiki/Development does not seem to point in the right > direction. The usage is pretty straightforward (for IT people) and IMO everything necessary is explained in the READMEs: * mwoffliner: https://sourceforge.net/p/kiwix/other/ci/master/tree/mwoffliner/ * zimwriterfs: https://sourceforge.net/p/kiwix/other/ci/master/tree/zimwriterfs/ NB: The goal is not that everybody creates its own full wikipedia ZIM file. The goal is that we (Wikimedia) provide these files, often enough to always have up2date ZIM information (so at least one time per month). Thus, the challenge is now to setup an infrastructure similar to the one which creates the XML dumps. Emmanuel PS: We really want to make a post @blog.wikimedia.org (so in English). If someone is volunteer to write this, I would really appreciate his help. -- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication

2 1

← Newer
1
...
15
16
17
18
19
20
21
...
24
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 March 2014