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
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
== 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
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
>
>
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
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
FYI,
---------- Forwarded message ----------
From: Core operations via RT <core-ops(a)rt.wikimedia.org>
Date: Thu, Oct 31, 2013 at 12:18 PM
Subject: [wikimedia #6138] etherpad.wikimedia.org downtime due to upgrade
To: akosiaris(a)wikimedia.org
Scheduling a downtime for etherpad.wikimedia.org on Wednesday 06/11/2013 in
order to upgrade it to the latest released version. The downtime is scheduled
to last one (1) hour and will start in 09:00 UTC. We will be upgrading from
1.2.11 (released 3 months ago) to 1.3 (released 10 days ago). Package will be
created and will be made available on apt.wikimedia.org during the upgrade.
This upgrade will reportedly solve some issues with pad corruption experienced
by the Language Engineering team.
--
(ticket has been created)
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
A few background notes:
* The generic external link icon is applied by virtual of existence of the
'external' class, which is a nice simple implementation. I kinda like it. :)
* In contrast, the CSS rules used to mark certain external links with the
PDF, IRC, SSL, etc "specific" icon types are relatively ugly and hard to
maintain. These use inefficient client-side attribute value matching. There
is a desire to clean these up in the style sheets, which would of course be
easiest if they're simply removed.
* If it's useful to keep those subtypes, it may be more desirable to
implement them differently (for instance by having the parser apply the
matching rules and output a class). This would simplify the CSS rules for
maintenance, since they would be able to just use the classes.
* Note that some of the rules such as PDF detection can misidentify
resource types (for instance the rules would mark a File:Blah.pdf file
*page* on Commons as "PDF" even though it's not actually a PDF download,
but an HTML web page). This would not necessarily change under the above
proposal to change implementation, as the basic problem is that you can't
really reliably determine a file type from a "file extension" on a URL (the
only real way to check is to try fetching the resource, or at least its
HTTP headers, and report back what type was received).
-- brion
On Tue, Oct 29, 2013 at 1:11 PM, Quiddity <pandiculation(a)gmail.com> wrote:
> As Bartosz says, and I think most of the communities would agree if asked
> on their respective village pumps - we value the external link icon in
> particular, and most of the other icons in general (with the possible
> exception of the https padlock). We think they are useful for both editors
> and readers.
>
> Re: Gadget - This isn't a particular workflow - this is:
> "I'm reading a random article, and I notice an external link icon, so, as
> a wikignome, I either: (if spam) remove it, (if citation) fix it, (if
> [subjective decision about its relevance/worth and adherence to [[WP:EL]]
> guideline) move it into the External links section."
> A gadget would not be a good replacement.
>
> By all means clean up the CSS, but do not consider removing the icons
> without seeking much much wider input.
>
>
>
> On 13-10-29 11:57 AM, Jared Zimmerman wrote:
>
>> Nick, good points, for the particular use case sounds like a gadget for
>> showing external links called out for workflows around fixing them would
>> be a good idea. After hearing everyone's thought i'm leaning toward no
>> icons for the average user.
>>
>> *
>> *
>> *
>> *
>> *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation
>> M : +1 415 609 4043 | : @JaredZimmerman <https://twitter.com/**
>> JaredZimmerman <https://twitter.com/JaredZimmerman>>
>>
>>
>>
>>
>> On Tue, Oct 29, 2013 at 11:41 AM, quiddity <pandiculation(a)gmail.com
>> <mailto:pandiculation@gmail.**com <pandiculation(a)gmail.com>>> wrote:
>>
>> +1 for more discussion, and onwiki discussion to find out why
>> we/they've each kept them in the individual CSS payloads for so many
>> years...
>>
>>
>> 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.
>>>
>>>
>> Wikis are special, in relation to most sites, because of the density
>> of internal links (many per paragraph), and the expectation that
>> most links are internal and will lead to a similar quality/style of
>> information. That applies from Wikisource, to Wookiepedia.
>>
>> In wikis that don't mix external links in the main content (eg most
>> Wikipedias), the icons are also useful /for editors/ as they can
>>
>> easily notice that something needs to be moved/fixed.
>>
>> See https://en.wikipedia.org/wiki/**Help:External_link_icons<https://en.wikipedia.org/wiki/Help:External_link_icons>for a
>> good list of what the English Wikipedia has.
>>
>> See also recent discussion at
>> https://bugzilla.wikimedia.**org/show_bug.cgi?id=54604<https://bugzilla.wikimedia.org/show_bug.cgi?id=54604>("Ridiculous
>> amount of CSS rules for external links")
>>
>>
>> The only icon that seems (afaik) completely unnecessary, and
>> bright/distracting, is the https padlock, which possibly
>> could/should be replaced with the standard external link icon.
>> (Unless there's a rationale for it that I'm forgetting/unaware of.)
>>
>> See this 2009 discussion where Davidgothberg created a blue (less
>> distracting) replacement, if we need to keep a padlock for some
>> reason.
>> https://en.wikipedia.org/wiki/**MediaWiki_talk:Common.css/**
>> Archive_11#Secure_links_**padlock<https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_11#Secure_l…>
>> https://www.mediawiki.org/**wiki/Special:Code/MediaWiki/**60320<https://www.mediawiki.org/wiki/Special:Code/MediaWiki/60320>
>>
>> HTH. Quiddity
>>
>> ______________________________**_________________
>> Design mailing list
>> Design(a)lists.wikimedia.org <mailto:Design@lists.**wikimedia.org<Design(a)lists.wikimedia.org>
>> >
>> https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design>
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> Design mailing list
>> Design(a)lists.wikimedia.org
>> https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design>
>>
>>
>
> ______________________________**_________________
> Design mailing list
> Design(a)lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design>
>