There is currently a patch in gerrit,
https://gerrit.wikimedia.org/r/#/c/130094/ , that has been hanging around
for a few months. To me it seems like an easy patch with some obvious
benefits.
JackMcbarn suggested this might need wider discussion/notice so putting it
up here to get a little more visibility.
Erik B.
The DumpHTML extension looks like it's in a pretty bad state, it doesn't
work at all in the current version of MediaWiki.
This seems to be an unfortunate symptom of how it's used and how it's
treated by core developers.
DumpHTML is most useful when someone is shutting down and archiving
their wiki, so it doesn't get tested regularly.
The act of creating a version of wiki pages suitable for offline use
from static files is something which inherently requires different
behaviour from things deep within core.
Because DumpHTML has been segregated into an extension and core doesn't
support an offline/dump mode internally DumpHTML has to use a bunch of
hacks to make core behave properly during the dump.
Then, because they are completely unaware of DumpHTML's needs, core
developers make improvements to core that then break DumpHTML without
providing it an alternative interface to get what it needs out of core.
For one DumpHTML needs to proxy and mess with file repo behaviours. To
do that it messed with properties like thumbScriptUrl, but then those
properties were protected leaving DumpHTML unsupported.
This was reported as a bug a month ago, which has gone relatively unnoticed:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69824
It also subclassed RepoGroup and since it proxied existing repo
instances instead of working with repo info it had to bypass the
__constructor. But then a $repoGroup->cache was added to the
__constructor in core, breaking DumpHTML in another way.
There are probably more issues that I haven't found yet while trying to
workaround the other issues.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
This is my last email to wikitech-l as a Wikimedia Foundation staffer; at
some point in the future, after a long break, I may re-join as a volunteer.
Thanks for the kind goodbyes you've sent me, publicly and privately, over
the past few weeks. And thanks for the work you've done and continue to do,
to help enable every human being to freely share in the sum of all human
knowledge. I'll leave you with one of my favorite songs, "Somebody Will."
http://www.sassafrassmusic.com/songs/sci-fi-fantasy-fandom/somebody-will/
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
On Fri, Sep 12, 2014 at 12:09 PM, Sumana Harihareswara <
sumanah(a)wikimedia.org> wrote:
> 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:
> http://www.harihareswara.net/sumana/2014/09/12/0
>
> 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.
>
> best,
> Sumana Harihareswara
> was Volunteer Development Coordinator, then Engineering Community
> Manager, now Senior Technical Writer
> Wikimedia Foundation
>
TL;DR: ask specific newish people to review specific changesets; pair
program; nominate maintainers.
I did a little poking-around in http://korma.wmflabs.org/ , especially
http://korma.wmflabs.org/browser/gerrit_review_queue.html , and on Gerrit
to check out our code review situation, although of course more people's
spot analysis or systematic assessments would be welcome.
It seems we have somewhat more committers and commits than a year ago
(yay!) but not more than, say, 10% more.
Some hypotheses that I was unable to prove or disprove:
* that there's been a freak spike in backlogged work
* that HHVM or some other project is soaking up the review times of people
who used to do a lot of general MediaWiki code review
But I will note that the group of people with +2 access in MediaWiki core
https://gerrit.wikimedia.org/r/#/admin/groups/11,members has fewer people
outside WMF/WMDE than it used to. (I remember when there were ~13 and now
there are ~8.) And, although we have many praiseworthy exceptions, there's
a tendency for WMF staff and contractors to -- legitimately -- concentrate
on writing and reviewing the code they're paid to work on (I presume it's
the same for WMDE), and thus to make less time for reviewing code outside
of those projects.
On the interiority of becoming a reviewer:
Here is a bit of a digression on capacity-building. Back when I was
volunteer development coordinator, I thought my two biggest jobs were: 1)
creating processes that scale, and 2) inculcating empathy in others. Both
of these come into play in increasing code review capacity. An open process
like https://www.mediawiki.org/wiki/Gerrit/Project_ownership scales better
than a cliquey "oh hey maybe you should have merge rights" does. But we
also have to grow new contributors into habitual reviewers, which means we
have to get inside the heads of developers who currently aren't in the
habit of offering reviews. One useful approach is the pathway to inclusion
http://infotrope.net/2014/08/12/the-pathway-to-inclusion/ :
1) Awareness: “I’ve heard of this thing.”
2) Understanding: "I understand what this is about."
3) Identification: “I can see myself doing this.”
4) Access: "I can physically, logistically, and financially do this."
5) Belonging: "I feel like I fit in here."
6) Ownership: "I care enough to take responsibility for this."
During my time at WMF I saw that many people needed help with all six of
those steps in order to start reviewing code, to broaden the scope of what
they reviewed, and to ask for maintainership rights. Informative email
blasts and wiki pages could only do so much; to cross some chasms, people
need personal invitation, one-on-one reassurance and encouragement, and
private misconception-clearing.
Recommendations:
* If you review code, you can help by poking through Gerrit with
imaginative searches
https://gerrit.wikimedia.org/r/Documentation/user-search.html and adding
reviewers to changesets, focusing on people who don't review as much as
they write. And follow up with email to them pointing them to
https://www.mediawiki.org/wiki/Gerrit/Code_review and reminding them that
all reviews help, that this is totally something they could do.
* Pair programming, pairing a newer developer with a reviewer, will also
help with the backlog (the person you pair with can review you pretty
fast!), and with awareness, understanding, and identification. For more see
my 15 September email
https://lists.wikimedia.org/pipermail/wikitech-l/2014-September/078627.html
.
* Nominate people to maintain repositories. Including yourself.
https://www.mediawiki.org/wiki/Gerrit/Project_ownership
Hope this helps.
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
Scribunto has an option to allow code to be saved even if it contains
syntax errors that prevent it from ever working. The original reason for
this feature was to make it more convenient to save incomplete code.
However, in practice, this has never been used for its intended purpose,
and users who don't know any Lua are breaking otherwise-functional modules
with it. Because of this, and because it's easy enough to save incomplete
code by simply wrapping it all in a multiline comment, I plan to remove the
option unless objections are raised.
Jackmcbarn
Hi, all FOSS Outreach Program for Women participants need to sign in as
candidates or mentors at https://opw.gnome.org/
Mentors can find specific documentation at
https://wiki.gnome.org/OutreachProgramForWomen/Admin/System
The deadline for submissions is Oct 22 2014, 07:00 pm UTC
Selection decisions will be posted on Nov 12 2014, 07:00 pm UTC
As a novelty in Round 9, all Ascend Project participants, regardless of
gender, are welcome to apply. Ascent is a mentorship and barrier-removing
accelerator program designed to explicitly invite, include, and support
adult learners in making a first technical contribution to Open Source
software.
http://ascendproject.org/participants/portland/index.html
After some discussions, this is a first step expanding this outreach
program to other groups under-represented in the free software community.
I'm personally very happy to see actual progress! Kudos to the GNOME
Foundation and the FOSS OPW supporters.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi Roxana,
On Mon, Sep 29, 2014 at 11:39 PM, Roxana Necula <necula.roxana91(a)gmail.com>
wrote:
> But before diving into the code and do the suggested micro-task, I first
> wanted to fix some annoying little bugs, starting with bug #25163
> <https://bugzilla.wikimedia.org/show_bug.cgi?id=25163>.
Feel free to comment on this bug report that you are working on it. The
reporter and at least six users CCed will be happy seeing some movement
there.
> So far everything
> is working fine in my local development environment, but I am still trying
> to familiarize myself with the code review / patching part.
>
Just in case: https://www.mediawiki.org/wiki/Gerrit/Tutorial
So, to wrap things up, my question is if I am heading towards the right
> direction, and if not, what advice do you have.
>
I agree with Brian, you seem to be heading to the right direction, and the
fact that you are communicating your intentions in wikitech-l is also a
good symptom. I just took the liberty of editing the subject of the thread
to make it more clear.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi, about FOSDEM -- Europe's biggest free software conference:
31 January & 1 February 2015 in Brussels
https://fosdem.org/2015/
The first deadline actually passed: devrooms. Last year we had a Wikis
devroom organized together with XWiki and TikiWiki. It was not bad at all
but I'm not sure whether we should put our effort there. Rather, we could
try to get more Wikimedia / MediaWiki sessions in the main track and other
devrooms, where we have more chances to interact with other communities we
rely on.
The deadline to present main track proposals is October 1. If you have a
topic wide interest, don't miss this one.
https://fosdem.org/2015/news/2014-07-01-call-for-participation/
The deadline for lightning talks and stands is November 20. You can work on
your lightning talk proposals, I will try to help Wikimedia Belgium and the
Wikimedia Shop in a joint venture that should bring a great Wikimedia stand
to an event with thousands of free culture & free software merchandise
lovers.
https://fosdem.org/2015/news/2014-09-19-call-for-participation-part-two/
Who is planning to attend? Anybody willing to create the wiki page?
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Jackmcbarn wrote:
>Scribunto has an option to allow code to be saved even if it contains
>syntax errors that prevent it from ever working. The original reason for
>this feature was to make it more convenient to save incomplete code.
>However, in practice, this has never been used for its intended purpose,
>and users who don't know any Lua are breaking otherwise-functional modules
>with it. Because of this, and because it's easy enough to save incomplete
>code by simply wrapping it all in a multiline comment, I plan to remove
>the option unless objections are raised.
As long as false positives are low, this is probably fine. It'd be nice to
get rid of the checkbox as it's user interface clutter.
That said, a hard block is still pretty potent... I wonder whether simply
warning the user and auto-categorizing the pages as likely broken on page
save would be adequate.
MZMcBride
Hello,
My name is Roxana and I am an engineering student at the Polytechnic
University of Bucharest, Romania.
I would like to be part of MediaWiki open-source community and participate
in the Outreach Program for Women round 9.
The project that interests me is Wikipedia article translation metrics
<https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wiki…>
But before diving into the code and do the suggested micro-task, I first
wanted to fix some annoying little bugs, starting with bug #25163
<https://bugzilla.wikimedia.org/show_bug.cgi?id=25163>. So far everything
is working fine in my local development environment, but I am still trying
to familiarize myself with the code review / patching part.
So, to wrap things up, my question is if I am heading towards the right
direction, and if not, what advice do you have.
Thank you,
Roxana.
<https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wiki…>