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).
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
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
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
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
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
+ 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