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/]
Hello, dear volunteers. :-)
On my computer there is running tor exit node:
http://atlas.TorProject.org/#details/9017E55701FB08C0E0B4A8F9C65380537D5249…
As you can see, my server rejects HTTPS port of WikiMedia servers:
reject 91.198.174.0/24:443
reject 208.80.152.0/22:443
But I cannot edit WM projects(, when I do not use Tor on my computer).
HTTPS, i.e. port 443, is the ONLY way to edit WikiMedia projects,
so I thing such servers (those reject port 443 of WikiMedia servers)
should by excluded from Public proxy blacklist of WikiMedia.
Your respectfully:
--
Rudolf Dovičín
Partizánska 1506/92-34
957 01 Bánovce nad Bebravou 1
SLOVENSKO
xmpp: ruwolf(a)jabbim.sk
(cellular: +421 944 748308, short messages only)
Some of you may have heard of the latest bash vulnerability (codenamed
"Shellshock").
Bash has been patched, but you may need to update.
In most cases, you can update GNU/Linux distributions with the standard
update tool (e.g. apt-get, yum, or the graphical equivalent).
For OS X, you currently need to install it separately, from
http://support.apple.com/kb/DL1769?viewlocale=en_US&locale=en_US .
Matt Flaschen
Minutes and slides from last week's quarterly review meeting of the
Foundation's Analytics team are now available at
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB