Wikitech-l October 2013

wikitech-l@lists.wikimedia.org

148 participants
149 discussions

Re: [Wikitech-l] [Design] Are external link icons useful
by Jon Robson 04 Nov '13

04 Nov '13

+ wikitech On Tue, Oct 29, 2013 at 8:54 AM, Siebrand Mazeland (WMF) < smazeland(a)wikimedia.org> wrote: > Also see https://gerrit.wikimedia.org/r/#/c/23424/ > > In my opinion, external link icons add a lot of visual noise and not that > much relevant information. > > > On Mon, Oct 28, 2013 at 11:22 PM, Jon Robson <jrobson(a)wikimedia.org>wrote: > >> Changed subject to reflect this change in topic. Also cc'ing design >> mailing list. >> >> In terms of external links to me I don't care about whether I'm leaving >> the site or not. If I clicked on something and it wasn't what I expected >> that's a badly labeled link. A link saying there is more information on the >> [white house official website] and a link to the word [house] should be >> enough information to tell which I'd external and which isn't. >> >> I actually think the only place an icon next to a link really makes sense >> is for downloads. Clicking something that downloads a PDF when I thought it >> was a web page is a little confusing (on mobile at least). >> >> That said if all the external links are in the external links / >> references section wouldn't encouraging that organisation of links be >> better....? >> >> Also I agree with Juliusz that we shouldn't force behaviour of where >> links open. It should be up to the user if they want the same tab or new >> one and it should be configurable within the browser preferences. >> On 24 Oct 2013 16:07, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote: >> >>> No, we should definitely not warn people, that's just weird ;) It's >>> not like something bad is about to happen. >>> I'm also not saying that users have the expectation that links point to >>> local URLs, I'm only saying that it might be a useful piece of information >>> to some. >>> >>> >>> On 10/24/2013 02:48 PM, Jared Zimmerman wrote: >>> >>> Its definitely a less heavy handed way of doing the thing many >>> (annoying) sites do when they warn you that you're leaving their site. I >>> just wonder is the signal to noise it worth it. I don't know that modern >>> web users have any expectations that link within a site always point to >>> local site urls. >>> >>> * >>> * >>> * >>> * >>> *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia >>> Foundation >>> M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman> >>> >>> >>> >>> >> _______________________________________________ >> Design mailing list >> Design(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/design >> >> > > > -- > Siebrand Mazeland > Product Manager Language Engineering > Wikimedia Foundation > > M: +31 6 50 69 1239 > Skype: siebrand > > Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design > > -- Jon Robson http://jonrobson.me.uk @rakugojon

2 1

H.264
by Magnus Manske 02 Nov '13

02 Nov '13

http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-mak… So, should we support this format now? (not advocating, just curious)

8 11

Secure and split
by MZMcBride 01 Nov '13

01 Nov '13

Happy Tim Starling Day! :-) It seems this year is the tenth anniversary: <https://en.wikipedia.org/wiki/Wikipedia:Tim_Starling_Day>. MZMcBride

5 5

FOSS OPW status update
by Quim Gil 31 Oct '13

31 Oct '13

Hi, we are still late but catching up at FOSS Outreach Program for Women: https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7 We have several project ideas listed, most of them coming from Wikimedia Foundation teams. We are still counting on more proposals, from the Flow, Mobile, Labs, and Language teams. Thank you very much! We still encourage other potential mentors (especially non-WMF) to push proposals from https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Raw_pr… We have 10 candidates listed at the wiki page. 9 applicants are from India and 1 from Brazil, which shows that more geographical diversity would be welcome. They are at the early stages of their proposals, but at this point this is mostly our (my) fault for starting late. Anyway, nothing that can't be fixed in the following days. The deadline for applications is November 11. Your help promoting this program in your circles is very important! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Re: [Wikitech-l] [Engineering] [WikimediaMobile] Fwd: Deployment postmortem
by Brad Jorsch (Anomie) 31 Oct '13

31 Oct '13

On Thu, Oct 31, 2013 at 2:48 PM, Max Semenik <msemenik(a)wikimedia.org> wrote: > > 1) Move them at least 1 hour earlier so that we never end in the situation > when someone deploys a change and goes home. With people in all different timezones, I don't think "never having someone deploy then go home" is going to be possible. For myself, for example, even if we move the LD an hour earlier I'll still normally have been "home" for an hour before LD starts. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

1 0

Fwd: Deployment postmortem
by Yuri Astrakhan 31 Oct '13

31 Oct '13

== Background == ZeroRatedMobileAccess has always depended on MobileFrontend and used it liberally, including calls to its classes. However, it was done in hooks called by MF so Zero simply stopped working in absence of MF. This, however, changed in [1] where Zero started using a ResourceLoader module from MF. == What happened == At 23:02pm UTC, after deploying Zero extension updates, fatal monitor was flooded with: -- Fatal error: Class 'MFResourceLoaderModule' not found in /usr/local/ apache/common-local/php-1.23wmf1/includes/resourceloader/ResourceLoader.phpon line 408 The issue was tracked down to Wikidata having MobileFrontend disabled, while ZeroRatedMobileAccess was enabled. It didn't impact page views directly, however all load.php calls that requested the startup module caused fatals because it attempted to instantiate MFResourceLoader class and couldn't find it. As a consequence, people might have seen pages without styles or scripts. A number of people (MaxSem, Reedy, Roan, and Greg, and possibly others) gave great assistance to track down the issue and rapidly disable the ZeroRatedMobileAccess extension in Wikidata. Furthermore, mobile configuration [2] will add an additional guard against calling ZeroRatedMobileAccess.php unless it's explicitly within the context of MF. Thank you to everyone!!! == Timeline == All times in UTC * 22:48 Zero 1.22wmf22 deployed, no errors * 23:02 Zero 1.23wmf1 deployed, first errors appear - initially unnoticed * 23:08 A small MobileFrontend change deployed * 23:09 Errors noticed, initially linked with MobileFrontend push * 23:17 Max reverts his MobileFrontend changes, errors don't go away * 23:22 Problem narrowed down * 23:27 Fix deployed == Recomendations == * Allow a bit more time between deployments and observe fatalmonitor before and after * Ensure Zero extension checks if Mobile extension is loaded before enabling itself if it relies on MFResourceLoader. ------ [1] https://gerrit.wikimedia.org/r/#/c/83133 [2] https://gerrit.wikimedia.org/r/#/c/92811

5 4

Re: [Wikitech-l] [Engineering] Deployment postmortem
by Chris McMahon 31 Oct '13

31 Oct '13

One thing that impressed me when I started working with WMF is that reverting in production is as safe as I have ever seen any production environment. In the 20 months or so I've been here, I think I only remember one change that left behind corrupt data in prod, and that change was made by a volunteer, the bug was manifested in beta labs but we failed to recognize the importance of the bug, and then the change to the code was merged on Thanksgiving Day by someone not on the team affected by the change-- one of those perfect storm sort of problems. We're good at reverting. On Thu, Oct 31, 2013 at 12:26 PM, Toby Negrin <tnegrin(a)wikimedia.org> wrote: > How easy is it to rollback production changes? Is this something that can > be consistently done easily with our current tools. At other high traffic > sites I've worked at this has been an important component of production > engineering. > > -Toby > > > On Wed, Oct 30, 2013 at 6:12 PM, Greg Grossmeier <greg(a)wikimedia.org>wrote: > >> First: Thanks for responding to this and writing it up. >> >> <quote name="Yuri Astrakhan" date="2013-10-31" time="04:53:44 +0400"> >> > == Recomendations == >> > * Allow a bit more time between deployments and observe fatalmonitor >> before >> > and after >> >> Agreed. >> >> I put a ton of blame on myself for not slowing down the cadence of LD >> slots when a bunch of people are trying to get in on the same day. >> >> For future LDs I am going to explicitly ask everyone to do what Yuri >> suggests (monitor fatals after your deploy) before saying that you're >> done. 5 minutes post-deploy of watching the fatalmonitor isn't >> unreasonable, I don't think. >> >> Relatedly, I think we should reassess the Lightning Deploys :) >> >> Not necessarily to get rid of them (probably not), but: >> 1) how many deploys can go in one LD? How many do we *want* to go? >> >> 2) from 1, is the length of the LD long enough/too long? >> >> 3) LD management is still pretty high-communication ("Alright, who's in >> line? Who's up next? Are you done yet?") There are basic tools that can >> help with this (Etsy has an IRC "pushbot" that manages the queue mostly >> automatically, for instance); I'll look into those/test them. >> >> 4) probably more, aka: your thoughts? >> >> >> Greg >> >> PS: graph of the fatals attached, just for completenesses sake. >> >> -- >> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | >> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | >> >> _______________________________________________ >> Engineering mailing list >> Engineering(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/engineering >> >> > > _______________________________________________ > Engineering mailing list > Engineering(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/engineering > >

1 0

RFC: Refactoring the Title object
by Rob Lanphier 31 Oct '13

31 Oct '13

Hi folks, I think Daniel buried the lede here (see his mail below), so I'm mailing this out with a subject line that will hopefully provoke more discussion. :-) This is an RFC we originally conceived at the Hong Kong Wikimania architecture discussion. The notes from that are here: https://www.mediawiki.org/wiki/Architecture_guidelines/Meetings/Wikimania_2… There has been discussion on this RFC here, so far only between Tim and Daniel: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/TitleValue It would be good to get some other voices in that conversation. Rob ---------- Forwarded message ---------- From: Daniel Kinzler <daniel(a)brightbyte.de> Date: Tue, Oct 1, 2013 at 10:18 AM Subject: [Wikitech-l] RFC: TitleValue To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> [Re-posting, since my original post apparently never got through. Maybe I posted from the wrong email account.] Hi all! As discussed at the MediaWiki Architecture session at Wikimania, I have created an RFC for the TitleValue class, which could be used to replace the heavy-weight Title class in many places. The idea is to show case the advantages (and difficulties) of using true "value objects" as opposed to "active records". The idea being that hair should not know how to cut itself. You can find the proposal here: <https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue> Any feedback would be greatly appreciated. -- daniel PS: I have included the some parts of the proposal below, to give a quick impression. ------------------------------------------------------------------------------ == Motivation == The old Title class is huge and has many dependencies. It relies on global state for things like namespace resolution and permission checks. It requires a database connection for caching. This makes it hard to use Title objects in a different context, such as unit tests. Which in turn makes it quite difficult to write any clean unit tests (not using any global state) for MediaWiki since Title objects are required as parameters by many classes. In a more fundamental sense, the fact that Title has so many dependencies, and everything that uses a Title object inherits all of these dependencies, means that the MediaWiki codebase as a whole has highly "tangled" dependencies, and it is very hard to use individual classes separately. Instead of trying to refactor and redefine the Title class, this proposal suggest to introduce an alternative class that can be used instead of Title object to represent the title of a wiki page. The implementation of the old Title class should be changed to rely on the new code where possible, but its interface and behavior should not change. == Architecture == The proposed architecture consists of three parts, initially: # The TitleValue class itself. As a value object, this has no knowledge about namespaces, permissions, etc. It does not support normalization either, since that would require knowledge about the local configuration. # A TitleParser service that has configuration knowledge about namespaces and normalization rules. Any class that needs to turn a string into a TitleValue should require a TitleParser service as a constructor argument (dependency injection). Should that not be possible, a TitleParser can be obtained from a global registry. # A TitleFormatter service that has configuration knowledge about namespaces and normalization rules. Any class that needs to turn a TitleValue into a string should require a TitleFormatter service as a constructor argument (dependency injection). Should that not be possible, a TitleFormatter can be obtained from a global registry. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

11 20

Wikimedia Bugzilla Guided Bug Entry Form available
by Andre Klapper 31 Oct '13

31 Oct '13

Since last Friday, Bugzilla has a guided bug entry form. Together with documentation at https://www.mediawiki.org/wiki/How_to_report_a_bug (which needs an update now) this should make it easier for users to create better bug reports. You can link to and access the guided form by attaching ?format=guided to the enter_bug.cgi URL, like e.g. https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia&component=Bu… If you don't pass product/component parameters in the URL & link to https://bugzilla.wikimedia.org/enter_bug.cgi?format=guided the first page (where a bug reporter has to choose a product) still looks the same as usual. I would like to thank the WMF design team and community liaisons for reviews and early feedback. Happy bug reporting, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

Page title length
by Élie Roux 31 Oct '13

31 Oct '13

Dear MediaWiki developers, I'm responsible for the development of a new Wiki that will contain many Tibetan resources. Traditionnaly, Tibetan titles of books or even parts of books are extremely long, as you can see for instance here : http://www.tbrc.org/#!rid=W23922, and sometimes too long for Mediawiki, for instance the title of http://www.tbrc.org/?locale=bo#library_work_ViewByOutline-O01DG1049094951|W… , which is ཤངས་པ་བཀའ་བརྒྱུད་ཀྱི་གཞུང་བཀའ་ཕྱི་མ་རྣམས་ཕྱོགས་གཅིག་ཏུ་བསྒྲིལ་བའི་ཕྱག་ལེན་བདེ་ཆེན་སྙེ་མའི་ཆུན་པོ་ . This title is around 90 Tibetan characters, but each caracter being 3 bytes, it exceeds the limit for title length of 256 bytes that MediaWiki has. So I have two questions: 1. If I change this limit to 1023 in the structure of the database ('page_title' field of the 'page' base), will other things (such as search engine) break? Is there a way to change it more cleanly? 2. Could I propose you to make this limit 1023 instead of 255 (or to make it configurable easily)? This would allow at least 256 characters (even for asian languages) instead of 256 bytes, which seems more consistant with the fact that MediaWiki is well internationalized. Thank you in advance, -- Elie

6 10

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 October 2013