Wikitech-l October 2013

wikitech-l@lists.wikimedia.org

148 participants
148 discussions

!ask
by Ori Livneh 24 Jan '14

24 Jan '14

Can we deprecate usage of '!ask' on IRC? > ori-l: !ask > wm-bot: Hi, how can we help you? Just ask your question. It's annoying when people ask to ask, but the people who do so do it out of insecurity or lack of experience, and so they're the last people we should be siccing our bots on. I've used '!ask' a lot before but I'm going to stop. I hope others do the same.

9 10

Call for participation: Wikis devroom at FOSDEM
by Quim Gil 02 Dec '13

02 Dec '13

Spread the news! https://lists.fosdem.org/pipermail/wikis-devroom/2013-October/000000.html Wikis devroom - FOSDEM, Brussels, 1 & 2 February 2014 CALL FOR PARTICIPATION IN SHORT We accept proposals for wiki related submissions. The formats accepted are 25min sessions or 5min lighting sessions. All proposals must be submitted via https://penta.fosdem.org/submission/ Deadline: 30 November 2013 Questions? Feedback? Willing to help? https://lists.fosdem.org/listinfo/wikis-devroom BACKGROUND Wikis are essential tools for online collaboration, open knowledge and free software. They are everywhere: from the mainstream Wikipedia to a myriad of public, academic and corporate knowledge bases and personal sites. And most of them are open source software. Wikis became popular thanks to the edit button allowing users to create and modify text-based web pages easily. Over the years wikis have become more powerful, handling more content types, allowing better look & feel, championing localization and integrating (sometimes) with other tools. The development continues, with hundreds of professional and volunteer contributors specializing in this area. There are also challenges: the competition from (mainly proprietary and corporate) social media and online office tools, keeping up with UX expectations from users, editors and sysadmins, compatibility across different wiki engines and other publishing tools, collaboration between wiki projects... SCOPE Wikis devroom is a place to showcase and discuss * new features, especially exploring areas beyond plain text editing * compatibility and integration with other tools and services * lessons learned from deployments, surveys, research... * cross-project collaboration We want to focus on sessions for a technical audience including savvy editors. Basic introductions for end users and long tutorials are out of scope. FORMAT One day, one room. Most of the schedule will be filled with sessions of about 25 minutes that have gone through a call for participation. We will have a WikiWiki Hour of lightning presentations (5 minutes each). We will organize a panel session with representation of key wiki projects - the specific topic to be decided as we confirm the participants. ORGANIZATION Quim Gil (MediaWiki), Vincent Massol (XWiki) and Jean-Marc Libs (Tiki).

3 4

Bugzilla Weekly Report
by reporter 14 Nov '13

14 Nov '13

8 11

jQuery UI may not be loaded by default on your wiki
by Matthew Flaschen 14 Nov '13

14 Nov '13

We have merged a couple changes so that jQuery UI is not loaded by code that doesn't need it. See https://bugzilla.wikimedia.org/show_bug.cgi?id=55550 for details. That means gadgets and user scripts that use jQuery UI should explicitly load the appropriate module. https://www.mediawiki.org/wiki/Extension:Gadgets has info on adding gadget dependencies. User scripts can use mw.loader.using (https://www.mediawiki.org/wiki/RL/DM#mw.loader.using). A list of jquery.ui modules is at https://www.mediawiki.org/wiki/RL/DM#jQuery_UI . There is one remaining issue that may affect a few wikis. If your wiki uses jquery.ui buttons in wikitext, the styles will not be loaded unless something explicitly loads or depends on jquery.ui. If you notice styles missing from your wiki, you can add: // Load jquery.ui.button so button styles work in wikitext mw.loader.using( 'jquery.ui.button' ); to the site Common.js Don't do this unless it's actually needed, since this does have a performance impact (although it is not loading all of jquery.ui). If you do add it, please include the comment so people know why it's being loaded. This will roll out to the test wikis, plus MW.org, 2013-10-31, the remaining non-Wikipedia wikis the 4th, and the Wikipedias, the 7th. Matt Flaschen

1 1

migrating hooks doc to doxygen?
by Antoine Musso 12 Nov '13

12 Nov '13

Hello, Since we introduced hooks in MediaWiki, the documentation has been maintained in a flat file /docs/hooks.txt . Over the week-end I have converted the content of that file to let Doxygen recognize it. The patchset is: https://gerrit.wikimedia.org/r/#/c/66128/ I have used that patch to generate a temporary documentation. That lets everyone browse the result easily. The produced result is: A landing page: https://doc.wikimedia.org/mw-hooks/hooks_mainpage.html The doc overview: https://doc.wikimedia.org/mw-hooks/page_hooks_documentation.html A list of hooks with their documentation: https://doc.wikimedia.org/mw-hooks/page_hooks_list.html I think that makes it a bit more accessible to everyone and Doxygen autolink to referenced classes. Some issues I have: - the hooks are listed alphabetically when they could be regrouped by theme (like API, SpecialPages, HTML Forms ...). - The hooks are documented in a separate file (still docs/hooks.txt), when we might want to have the doc near the wfRunHooks() call. Thoughts ? -- Antoine "hashar" Musso

13 17

$wgRedactedFunctionArguments
by Ori Livneh 12 Nov '13

12 Nov '13

The 1.22 release adds a new configuration variable, $wgRedactedFunctionArguments, that allows administrators of MediaWiki installations to designate function arguments that should be redacted from stack traces. For example: $wgRedactedFunctionArguments[] = array('User::comparePasswords' => array( 0, 1 ) ) This value specifies that whenever the method User::comparePasswords appears in an exception stack trace, the value of the first and second arguments are to be redacted, meaning the string 'REDACTED' is inserted where the argument value would otherwise appear. The case for this feature was made in <https://bugzilla.wikimedia.org/show_bug.cgi?id=30714>. I think that it is a design blunder, and that we should remove it from MediaWiki. The task of making $wgRedactedFunctionArguments comprehensive is hopelessly gargantuan. It would require something like a full trace of the flow of data throughout all of MediaWiki and its extensions. The best case scenario is that the feature is not used. The worst case -- which seems to be materializing, judging by the default value assigned to it in DefaultSettings.php -- is that it is used with a short and chronically out-of-date list of obvious suspects, and that the resultant traces leak private data. This is actually worse than making no attempt at all to sanitize traces, because it is liable to mislead and inspire false feelings of confidence. I think that the proper way to handle low-level operational data like stack traces is to make it clear that it is liable to contain sensitive information, and to make no pretense at all of sanitizing it. If there is a credible need for outputting redacted traces, the output should exclude *all* values, not just the ones that someone remembered to configure. --- "Base access decisions on permission rather than exclusion. This principle...means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. A conservative design must be based on arguments why objects should be accessible, rather than why they should not. In a large system some objects will be inadequately considered, so a default of lack of permission is safer. A design or implementation mistake in a mechanism that gives explicit permission tends to fail by refusing permission, a safe situation, since it will be quickly detected. On the other hand, a design or implementation mistake in a mechanism that explicitly excludes access tends to fail by allowing access, a failure which may go unnoticed in normal use. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation." ("The Protection of Information in Computer Systems", http://web.mit.edu/Saltzer/www/publications/protection/Basic.html) --- Ori Livneh ori(a)wikimedia.org

8 8

Architecture Summit: participants confirmed
by Quim Gil 08 Nov '13

08 Nov '13

Hi, https://www.mediawiki.org/wiki/Architecture_Summit_2014#Participants has been updated in order to reflect the current list of participants confirmed. We are in touch with a few contributors from areas currently underrepresented, and it is possible that some people are still added to the list. Volunteer contributors requiring sponsorship will be contacted via email. The Wikimedia Foundation will cover their flights and accommodation. Please email me if you don't hear from us this week. Wikimedia Foundation employees not based in San Francisco must contact their managers for travel arrangements. The first MediaWiki Architecture Summit 2014 is looking great at least in terms of participation. Next: content. Now it's time to focus in the discussions prior to the event, and the schedule. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 2

Optimizing the deployment train schedule
by Erik Moeller 08 Nov '13

08 Nov '13

Hi folks, after speaking to a few folks, I'd like to check in on the WMF deployment train schedule overall, and see if there are ways to optimize it. (Note: In the below I refer to "test wikis" vs. "production wikis", generously including mediawiki.org as a test wiki. I realize that our "test wikis", with the exception of Labs wikis, run on the production cluster.) == Current practice == * On Thursdays we increase the release counter, and deploy the latest release to test wikis and the previous one to Wikipedias. * On Mondays we deploy the latest release to non-Wikipedias. == Problems with this approach == * We only have bits of Thursday and all of Friday to resolve issues that are surfaced in the test wikis prior to the Monday rollout to the first production wikis. * Having two stages of release also increases the cognitive load on developers in understanding when their code hits production wikis, which arguably increases the risk of negative impact of a deploy going unnoticed. == Advantages of this approach == * Commons serves just about enough traffic to sometimes act as a useful canary for performance/scaling issues that will later appear in production. * Developers have some post-deployment time to fix issues highly specific to the non-Wikipedia wikis (e.g. extensions & gadgets only deployed there) rather than being distracted by firefighting on Wikipedia == Some options == Option A: Change nothing. I've not heard from enough folks to see if the problems above are widely perceived to _be_ problems. If the consensus is that current practice, for now, is the best possible approach, obviously we should stick with it. Option B: No Monday deploy. This would mean we'd have to improve our testing process to catch issues affecting the non-Wikipedia wikis before they hit production. I personally think getting rid of the Monday deploy could create some _desirable_ pain that would act as a forcing function to improve pre-release test practices, rather than using production wikis to test. At the same time, we'd have a full week to work out the kinks we find in testing before they hit any production wiki, and could have a more systematic process of backing out changes if needed prior to deployment. Option C: Shift Monday deploys to Tuesday. This would at least give us an additional work day to fix issues that have occurred in testing before they hit prod. I personally don't think this goes far enough, but might be a useful tweak to make if option B seems too problematic. Are there other ways to optimize / issues I'm missing or misrepresenting above? Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

13 20

Possible topics for the next RFC review
by Rob Lanphier 05 Nov '13

05 Nov '13

Hi folks, Here's the RFCs that have the most interest expressed on the Architecture Summit invite page[1]: https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database https://www.mediawiki.org/wiki/Requests_for_comment/Deprecating_inline_styl… https://www.mediawiki.org/wiki/Requests_for_comment/Password_requirements It's conceivable that Tim and/or Brion could hold an IRC meeting next week, if there's sufficient interest in doing so and they get a little help organizing it. There's perhaps a little pre-meeting setup, some notetaking, and post-meeting wiki gnoming to do. You can check out the meeting from September 24[2] to get an idea of what's needed. Also, there's now a meeting hub[3] for these meetings so that you can see what's coming up and dig up notes from previous meetings a little easier. The more we can get done online prior to the meeting, the more useful our in-person meeting will be in January. Unless we get everything done before the meeting and have nothing to do. I somehow don't think that'll be a problem. :-) Rob [1] https://www.mediawiki.org/wiki/Architecture_Summit_2014 [2] https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-09-24 [3] https://www.mediawiki.org/wiki/Architecture_meetings

5 5

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

03 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

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