Wikitech-l April 2015

wikitech-l@lists.wikimedia.org

98 participants
78 discussions

Designing a MediaWiki Skin
by Nasir Khan 27 Apr '15

27 Apr '15

Hi, I was trying to develop a MediaWiki skin based on Bootstrap3. I am facing several type of issues at the time of doing this. MediaWiki is forcing me to use the default vector styles and for may of the pages it is "very hard" to use own CSS classes, for example Special:Allpages[1]. I am lucky that my skin/bootstrap default is similar with the MediaWiki UI and i enabled it in everywhere. But even this could not cover the page " Special:Allpages ". I found it very complex to develop a new skin for MediaWiki and it forces everyway to use the default vector skin. About a year ago i headed a project on "Separating skins from core MediaWiki", could anyone please let me know the progress and current status of that project. [1] - http://en.banglapedia.org/index.php?title=Special:AllPages -- *Nasir Khan Saikat* www.nasirkhn.com

5 7

Wikimedia Foundation quarterly reviews
by Tilman Bayer 27 Apr '15

27 Apr '15

Hi all, the quarterly reviews for the past quarter (January-March 2015) took place last week. Minutes and slides are now available for the following meetings: Community Engagement, Advancement (Fundraising and Fundraising Tech): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Mobile Web, Mobile Apps, Wikipedia Zero: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Parsoid, Services, MediaWiki Core, Tech Ops, Release Engineering, Multimedia, Labs, Engineering Community: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Editing (covering VisualEditor), Collaboration (covering Flow), Language Engineering: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… As mentioned in February [1], the quarterly review process has been extended to basically all groups in the Foundation since Lila took the helm last year, and it was further refined this quarter, reducing the number of meetings to six overall, each combining several areas. Minutes and slides from the remaining two meetings should come out soon, too. (And naturally, all the engineering team names above refer to the structure before the reorganization that has just been announced.) [1] https://lists.wikimedia.org/pipermail/wikimedia-l/2015-February/076835.html On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)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_r… > > 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 > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB

1 1

Serious unfixed wikidata bug
by John 26 Apr '15

26 Apr '15

T43345 <https://phabricator.wikimedia.org/T43345>is classified as a high priority, and hasn't been fixed for three years. Getting a column added to indicate that a language link is stored in a foreign repo shouldn't be this hard. I can think of quite a few cases where this data could be leveraged in one way or another. Wikidata is extremely widely used, and we still dont have this basic feature implemented, who needs pressured to get progress made on this? this should be a fairly straight up and trivial feature to get going.

2 2

[Hackathon] Reminder : Registration
by Alex Cella 24 Apr '15

24 Apr '15

Hey all, This email to remind you to register if you want to attend the European Hackathon. We already have many people registered and we'll soon be full. Registration ends on the 8th of March. If you want to join this great week-end, you can register here: https://dons.wikimedia.fr/civicrm/event/register?reset=1&id=8 You can't apply for a Scholarship anymore! A page is dedicated to give you more information: http://www.mediawiki.org/wiki/Wikimedia_Hackathon_2015 The Phabricator listing considered tasks is : https://phabricator.wikimedia.org/tag/wikimedia-hackathon-2015/ In any case, if you have some more questions, I'll be glad to help you! :) Best, *Alexandre Cella* ASSISTANT LEVÉE DE FOND ET MÉCÉNAT FUNDRAISING AND SPONSORSHIP ASSISTANT *WIKIMEDIA FRANCE* +33 6 18 16 16 19 www.wikimedia.fr 40 rue de Cléry, 75002 Paris *Vos dons réguliers aident à faire fonctionner Wikipédia ! Soutenez Wikimédia France aujourd'hui* : https://dons.wikimedia.fr

2 2

OOjs UI 0.10.0 Release
by Trevor Parscal 23 Apr '15

23 Apr '15

Hey all, OOjs UI 0.10.0 was released on Wednesday. It will be in MW from 1.26wmf4+. As there are several breaking changes, please look carefully over them to determine if they affect your code. Breaking changes since last release: - [BREAKING CHANGE] ButtonWidget: remove deprecated nofollow option alias (C. Scott Ananian) This was deprecated in v0.8.0, at which point it was already unused as far as we are aware. The real config option, "noFollow" (with a capital 'F') continues to work as before. - [BREAKING CHANGE] Convert ToggleWidget from a mixin to an abstract class (Bartosz Dziewoński) This is only technically a breaking change; the interface and behaviour of the widgets built on top of ToggleWidget are unchanged. - [BREAKING CHANGE] MenuLayout: Reimplement without inline styles (Bartosz Dziewoński) Menu size can be set using CSS now. MenuLayout's CSS will override the appropriate values with 'auto' or '0' to display the menu correctly. If `menuPosition` is known beforehand, CSS rules corresponding to other positions may be omitted. This was a bit of a mess (and only used by one consumer, already fixed). The behaviour of the 'showMenu' and 'menuPosition' configuration options is unchanged. Additional details are in the full change log. If you have any further questions or need help dealing with deprecations, please let me know. As always, general library documentation is available at mediawiki.org and generated code-level documentation at doc.mediawiki.org. - Trevor

1 0

RFC meeting this week
by Tim Starling 23 Apr '15

23 Apr '15

In the next RFC meeting, we will discuss the following RFC: * Business Layer Architecture on budget <https://www.mediawiki.org/wiki/Requests_for_comment/Business_Layer_Architec…> The meeting will be on the IRC channel #wikimedia-office on chat.freenode.net at the following time: * UTC: Wednesday 21:00 * US PDT: Wednesday 14:00 * Europe CEST: Wednesday 23:00 * Australia AEST: Thursday 07:00 -- Tim Starling

2 1

"For the Sake of Simplicity"
by Ori Livneh 23 Apr '15

23 Apr '15

>From http://www.artima.com/weblogs/viewpost.jsp?thread=362327 : That software systems are getting bigger and more pervasive is testament that we can at times muster the wherewithal to manage the inherent complexity of constructing large systems. At other times, however, it simply supports the view that creating complexity is far easier than hiding it — the creeping featurism, physical size, and bugginess of certain operating systems and wordprocessing packages is tantamount to a public admission of software engineering failure. To paraphrase Blaise Pascal, "The software to solve your problem is larger and more complex than necessary, because we did not have the ability or resources to make it smaller and simpler." [...] In other words, leaving or taking things out by constantly examining the difference between inherent and actual complexity, questioning and reducing the number of features, and questioning and reducing the amount of code. For benighted management that still measures productivity in terms of KLOCs, this is scary: it appears to represent negative productivity. But... less code, fewer bugs... fewer features, greater ease of use... and so on. This leads to an interesting marketing possibility, and one that I have seen in action only a few times: the idea that a subsequent release of a product might be smaller or have fewer features than the previous version, and that this property should be considered a selling point. Perhaps the market is not mature enough to accept it yet, but it remains a promising and classic ideal — less is more.

7 7

Last chance to reboot precise installs in Labs
by Marc A. Pelletier 22 Apr '15

22 Apr '15

Hello Labs project maintainers, Today is your last chance to reboot any instances you may be running that have Ubuntu Precise and have not been rebooted since my notification last week! All instances how have a /usr/local/sbin/reboot-if-idmap script installed which, if run by root or with sudo, will reboot any instance iff it still needs to be rebooted. (Specifically, it does the exact feature test and does nothing if it passes). == What happens if you don't reboot == At some point tomorrow (Apr 23, around 14h UTC) idmap[1] will be turned off on the labs storage servers. Instances that are still trying to use idmap will loose the ability to access files in /home and /data/project that are not globally readable (or writable, as the case may be). This may impact processes running on those instances in various ways. Again, only instances that are running Ubuntu Precise and that have not been rebooted (for any reason) since Apr 13, 2015 12h UTC are affected. If in doubt, you can safely run the reboot-if-idmap script - it will have no effect on instances that do not neet reboot or have already been rebooted. Thank you, -- Marc

1 0

Fwd: [Foundation-l] Single login - decision 2004
by Keegan Peterzell 22 Apr '15

22 Apr '15

---------- Forwarded message ---------- From: Keegan Peterzell <kpeterzell(a)wikimedia.org> Date: Wed, Apr 22, 2015 at 1:34 AM Subject: Re: [Foundation-l] Single login - decision 2004 To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> On Nov 11, 2004, at 03:27:00 UTC , Erik Moeller <erik_moeller(a)gmx.de> wrote [1]: > Hi, > there's been some movement forward on the Single User Login (SUL) issue. I > > ask the Board to review this mail carefully as this has significant long- > term implications and we need Board input to go ahead. I also ask other > developers to correct me if I misrepresent anything. > There are currently three competing strategies. Before I describe these > strategies, let me point out that one important consideration for any > system is scalability. That is, single login will be used on all existing > and future Wikimedia projects, and potentially even on non-Wikimedia sites > > which we allow to participate in our system. > The three strategies are: > 1) GLOBAL NAMESPACE, IMMEDIATE CONFLICT RESOLUTION > We try to move towards a single global user namespace for all Wikimedia > wikis. If a name is already taken in the global namespace, you have to > find one which isn't. > For the migration, any names which clearly belong to the same user are > combined into one. If passwords and email addresses are different, the > user can manually link together any accounts which belong to him by > providing the passwords. > For cases of true name conflicts between the existing wikis, there is a > resolution phase, where factors like seniority, use on multiple wikis vs. > a single one, etc., are weighed in - the "loser" has to choose a new > account name. > After the manual resolution phase, any remaining accounts are converted to > > the new system automatically by making them unique, e.g. by adding a > number to the username. The transition is now complete. The old system no > longer exists. --- > 1) is very complex, and we may not find someone willing to deal with the > name conflict resolution issue and take the blame from annoyed users at > the same time. Naming conflicts will always be an issue in this scheme, as > > e.g. all common first names will be taken, and any small wiki hooking up > with our SUL system would feel this impact. People can mutate these > usernames relatively easily to make them unique - Erik333 - and the system > > can offer such mutations, but it's still a bit annoying. This is now complete [2]. That wasn't too bad. 1. https://lists.wikimedia.org/pipermail/wikimedia-l/2004-November/061327.html 2. https://lists.wikimedia.org/pipermail/wikimedia-l/2015-April/077576.html -- Keegan Peterzell Community Liaison, Product Wikimedia Foundation -- Keegan Peterzell Community Liaison, Product Wikimedia Foundation

3 2

Jenkins slaves now use tmpfs for MySQL storage
by Krinkle 21 Apr '15

21 Apr '15

Hey all, Over the past months our main MediaWiki PHPUnit run slowed down a lot. Some of that is attributed to our unit tests using too much database integration [1]. Another significant portion is attributed to the switch to MySQL. The overhead was especially significant for Precise instances and PHP Zend. While MySQL is heavier than SQLite, it generally does perform better at scale, caching, and with concurrent requests from the web. However we lost a lot compared to SQLite because our SQLite wasn't on disk but in a tmpfs mount. Last week we worked on adding a tmpfs mount to our Jenkins slaves and configuring MySQL to store its data there instead. Our average build time went from 20 minutes (zend) and 8 minutes (hhvm) to 9 minutes and 4 minutes! For the impact on the average build time trend graphs, see https://phabricator.wikimedia.org/T96230#1215473 <https://phabricator.wikimedia.org/T96230#1215473> There's still room for more optimisations, which are tracked at https://phabricator.wikimedia.org/T96249 <https://phabricator.wikimedia.org/T96249>. — Krinkle [1] https://phabricator.wikimedia.org/T93556 <https://phabricator.wikimedia.org/T93556>

3 2

2026

2025

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 April 2015