Quim Gil | 16 Sep 15:34 2014

Phabricator update

Hi, if you were wondering what is going on in Phabricator land...

Summary: You can see https://phabricator.wikimedia.org , you can touch
https://phab-01.wmflabs.org/ , you will have a chance to provide feedback
about the Bugzilla migration before the migration, based on a test instance
with a sample of bugs imported.

In detail:

* https://phabricator.wikimedia.org exists as a read-only instance and it
contains the tasks that were migrated from the now decommissioned
fab.wmflabs.org. Registration is disabled while we fix some tasks --
details at https://www.mediawiki.org/wiki/Phabricator/Plan#Migration_plan .
We will post here when the issues have been fixed.

* We have a test instance at https://phab-01.wmflabs.org/ where you can
play as much as you want. This instance is for testing and experimenting
only. Anything in there can disappear in a whim.

* When we open phabricator.wikimedia.org, the creation of new projects will
be still disabled. Existing projects will be able to continue their work,
but we are asking new projects to wait a few weeks, until we complete the
Bugzilla migration. It's going to be still a bumpy road before Day 1, and
we want to control the impact of these disruptions as much as possible.

* RT migration will follow. Details will be shared in advance.

* Bugzilla migration will follow. Details will be shared in advance as
well, but we have a rough idea of the sequence of steps. Details available
in the migration plan linked above, pasted here for convenience:
(Continue reading)

Markus Glaser | 16 Sep 01:11 2014

User Group Proposal: MediaWiki Cooperation

Dear Wikitech-l Readers,

spreading open knowledge is not just about content, but also about tools. That's the reason we provide
MediaWiki as an open source product. Fortunately, MediaWiki is used widely outside the Wikimedia world,
so the mission is fulfilled, right? Well, not quite... Third party users of MediaWiki do have very
specific needs that are naturally not in the primary focus when running Wikimedia sites. 

Over the past few weeks, a group of people has been working on a proposal for a User Group that tackles exactly
these issues: "We will advocate the needs of all users of MediaWiki. Our primary focus will be those who use
MediaWiki outside the Wikimedia Foundation (WMF). We are a group of MediaWiki enthusiasts who care about
the development and evolution of the  MediaWiki as a tool for everyone." [1]

We have gathered quite a number of supporters and members. There were some meetings where we discussed the
mission of this group and its purpose. Now we are ready to take the next step and apply for official
recognition. Before we actually start, we are seeking your feedback. Any comments are welcome, here on
the list and on the discussion page of the group [2].

Markus (mglaser) and Mark (hexmode)

[1] https://www.mediawiki.org/wiki/Groups/Proposals/MediaWiki_Cooperation
[2] https://www.mediawiki.org/wiki/Talk:Groups/Proposals/MediaWiki_Cooperation

Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Tomasz Finc | 16 Sep 00:40 2014

Jeff Hobson joins the Wikipedia Zero Engineering Team

Greetings All,

I'm very happy to welcome Jeff Hobson to the Wikimedia Foundation and
the Wikipedia Zero Engineering team. He'll be joining Yuri, Adam, and
Dan Foy to continue the great work that the Zero team has been working
on and focusing on building our carrier portal first. Today will be
his first day.

Jeff will be working remotely from Blacksburg, VA, but hopes to
eventually venture out to the west coast to join us locally. Jeff has
been building websites for over 12 of his 22 years and practically
weeped tears of joy when HTML5 was first released. Aside from web
development, he's dabbled in Parallel Computing, AI, and even some
robotics. But the ever-changing nature of web development has kept him
coming back and he's excited to join WMF to work with all the
challenges mobile brings. In his free time Jeff enjoys skiing, riding
roller coasters, speed running, and playing the drums.

Please join me in welcoming Jeff


Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Jaime Schatz | 15 Sep 21:52 2014

Re: want to pair program more often?

Sumana, this is awesome!


In case you're keeping track, I'm at the n00b end of the experience
spectrum. :D
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Sumana Harihareswara | 15 Sep 15:24 2014

want to pair program more often?

You should probably pair program more often. Here's why.

1) learning

Every single time I've pair programmed with someone, one of us has learned
stuff. About our tools, about a new way to look at a problem, about a
language feature, or something. Sometimes I've paired explicitly as a
teaching or learning technique, sometimes on more equal footing ("I'm the
domain expert for the problem but you're better at $framework than I am"),
or just to brainstorm or troubleshoot. At least one of us always comes out

2) the tools are better than ever

has some resources; don't dismiss pair programming just because you don't
live near other programmers.

3) pairing makes better code

"Pair Programming" by Laurie Williams (Ch. 17 in _Making Software: What
Really Works, and Why We Believe It_, ed. Andy Oram & Greg Wilson, O'Reilly
2011) reviews recent studies and finds that pair programming leads to
higher-quality code, and "reduced product risk due to improved knowledge
management". Some teams even tried pair programming as a replacement for
code review.

4) it's more egalitarian

As this list of status play behaviors points out
(Continue reading)

Federico Leva (Nemo | 15 Sep 10:00 2014

Upstream gerrit fixed: Bug 35534 - Free-form tagging



Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
reporter | 15 Sep 05:00 2014

Bugzilla Weekly Report

MediaWiki Bugzilla Report for September 08, 2014 - September 15, 2014

Status changes this week

Reports changed/set to UNCONFIRMED:  8                             
Reports changed/set to NEW        :  23                            
Reports changed/set to ASSIGNED   :  37                            
Reports changed/set to REOPENED   :  13                            
Reports changed/set to PATCH_TO_RE:  81                            
Reports changed/set to RESOLVED   :  271                           
Reports changed/set to VERIFIED   :  12                            

Total reports still open              : 15679                         
Total bugs still open                 : 9499                          
Total non-lowest prio. bugs still open: 9169                          
Total enhancements still open         : 6180                          

Reports created this week: 294                           

Resolutions for the week:

Reports marked FIXED     :  191                           
Reports marked DUPLICATE :  25                            
Reports marked INVALID   :  17                            
Reports marked WORKSFORME:  18                            
Reports marked WONTFIX   :  16                            

Specific Product/Component Resolutions & User Metrics 

Created reports per component
(Continue reading)

Gergo Tisza | 15 Sep 02:19 2014

Best method to flag wiki pages based on rendered HTML


I would like to flag a large number of wiki pages based on whether their
HTML passes a certain test, so that failing pages can be easily listed and
counted. The flags should adapt when pages are created or modified. (The
specific use case is collecting file pages which do not have
machine-readable author and license information embedded.)

I have been thinking of adding such pages to a maintenance category from a
parser hook (the test logic is already part of the imageinfo/extmetadata
API and would be easy to reuse), is that a good way to do this? If so,
what's the best way to achieve it? Is it OK to just add categories as
needed via $parser->getOutput()->addCategory() or can that mess up internal
state such as the categorylinks table?

Alternatively, the Cite extension just parses and appends a message to the
end of the text on ParserBeforeTidy when it encounters an error, and the
message contains wikitext to include a category. That seems like a clever
way of maintaining flexibility so it is easy to change the category name or
add extra text for a call to action without any need for a code change. Is
that approach safe/cheap?

Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Florian Schmidt | 14 Sep 15:21 2014

Who maintains ConfirmEdit core part?

Hello together!

I have a short question: There is a changeset in gerrit[1] for ConfirmEdit,
which enables to show a Captcha directly after the „Edit“ click, instead of
a first „Save“ click (see Commit Msg and the Bug report[2] for more
details). This change was uploaded on May 30, 2014, unhappily without any
review until now. The list of maintainers for Wikimedia extensions [3] lists
only „Emufarmers“ as a maintainer. Unhappily he/she only maintains the
FancyCaptcha module of ConfirmEdit (iirc the irc talk). So, my question: Ist
here anyone who maintains the core part of ConfirmEdit? Is there anyone who
can/want give the change a review?

Thanks in advance!

[1] https://gerrit.wikimedia.org/r/136323 

[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=19648 

[3] https://www.mediawiki.org/wiki/Developers/Maintainers 

Freundliche Grüße / Kind regards


Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Stephan Gambke | 12 Sep 21:04 2014

Howto get a patch merged?

Ok, last attempt.

This needs merge: https://gerrit.wikimedia.org/r/#/c/151370/

Somebody shat on it (-2), so it looks ugly, sorry for that.
Didn't come back to clean up their mess, either, instead told me to
advertise it here.

Sorry for putting it like this, in particular with the Sumana's thread
right next to it, but really, I am fed up. The way this went lets all
that clamoring for contributors sound rather hollow, to my ears at
least - they are quite obviously not welcome. I mean being ignored
because everybody is apparently super busy is one thing. But being
made to jump through hoop after hoop for weeks and then being ignored
does feel less like being ignored and more like being made fun of. It
will be a long time until I waste my time again on trying to get some
patch merged.


Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Sumana Harihareswara | 12 Sep 18:09 2014

I'm leaving the Wikimedia Foundation

I write this email with regret to let you know that I've decided to leave
the Wikimedia Foundation after nearly four years working here, and that my
last day will be 30 September.

I go into my reasoning and plans in this personal blog post:

I'm grateful for what I've learned here and will take these lessons
wherever I go. And I've made many friends here; thank you. I'll remain
[[User:Sumanah]] in any volunteer work I do onwiki. Quim Gil will be the
person to contact for any loose threads I leave behind; still, if you have
questions for me, the next two weeks would be a good time to ask them.

Sumana Harihareswara
​was Volunteer Development Coordinator, then Engineering Community Manager,
now Senior Technical Writer
Wikimedia Foundation
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org