To make life easier for the fundraising translators, I added CLDR
support to XML::languageSelector(). This means you can now request a
language select list in any language you want (rather than just getting
the native names). This would also be useful for things like the Upload
Wizard.
Unfortunately, we only have 1 available deployment day left before the
holidays, so if there's any chance someone could review the revision
before 2pm tomorrow, it would be greatly appreciated.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106912
The change should be 100% backwards compatible. Thanks.
Ryan Kaldari
MediaWiki is a mature, living breathing beast. When making lots and lots of
little tweaks, please try to make sure they actually work correctly prior
to committing.
I'm becoming convinced that a huge benefit of the git migration will be in
moving to pre-commit review. If it doesn't work, don't let it into to core
yet... The very idea what we can have a big "review backlog" on things
ALREADY COMMITTED is a large part of why we have so many regressions when
we finally catch up and update.
That is all; please go on about your business, citizens.
</rant>
-- brion vibber (bvibber @ wikimedia.org)
Everyone,
I wanted to let everyone know that we recently began testing some new
versions of the Article Feedback tool. As you may remember, the first
version of the tool (launched earlier this year), focused on having readers
provide feedback on the quality of articles [1]. The new versions try a
different approach, based in part on feedback from the community. Rather
than ask readers for feedback on quality, the new feedback forms prompt the
user to help improve the encyclopedia. For example, one version we're
testing asks the reader "Did you find what you're looking for?". If the
reader answers "No", the tool prompts them to explain what is missing. The
intent is to provide editors with some idea of feedback on what readers are
actually hoping to see when they read a Wikipedia article, so that the
editing community may incorporate that feedback when developing the
article. Hopefully, some of these readers will also become editors.
Here is the blog post with more details:
http://blog.wikimedia.org/2011/12/20/a-new-way-to-contribute-to-wikipedia/
Right now, there are three test versions running on approximately 10,000
randomly selected rticles.
Is this type of feedback actually going to be helpful? We don't know. So
the next step is to evaluate the comment streams coming in from each test
version to see which one offers the most number of constructive comments
accompanied by the least amount of noise [2]. We'll be doing this with
community members, so if you'd like to be involved, please drop either me
or Oliver Keyes (okeyes at wikimedia dot org) a line. We're also tracking
progress on the project page [3].
Howie
[1]
http://blog.wikimedia.org/2011/07/15/%E2%80%9Crate-this-page%E2%80%9D-is-co…
[2] The comment streams aren't going to be viewable by the public yet. One
of the next phases of the project is to design a "Feedback Page" which
displays the comment stream on a per article basis. We'll be collaborating
closely with the editing community on the design of this page.
[3] http://en.wikipedia.org/wiki/Wikipedia:Article_Feedback_Tool/Version_5
I've been informally mentoring André, Tiago, Diego, and César. They
are four students at Minho University who are currently working on a
project to improve DB2 database support in MediaWiki.
So far, they've:
- Fixed several outstanding issues with DB2 support involving
character encoding, Windows vs Linux, etc
- Added DB2 support to the new MediaWiki 1.17 Installer and Updater
- Put in the appropriate Updater sql patches to reflect database
schema changes since 1.14
MediaWiki already had some DB2 support, but it's been broken since
1.15 and never complete. As a result of their work, it's now possible
to successfully install MediaWiki on DB2 out of the box and to use the
core wiki features.
I'll shortly commit their first patch using my SVN account (leonsp).
I've taken some care to look over the code and make sure it abides by
the MediaWiki code guidelines.
Regards,
Leons Petrazickis
http://lpetr.org/blog/
Welcome to three new extensions committers:
Alexander (grafzahl) expects to work on: "Extension:Score, possibly
Extension:JHilbert should it ever go into SVN."
Adam White (adamw) is working on Extension:Offline -- more info at
http://code.google.com/p/wikipedia-offline-patch/ .
Isaac "Ike" Hecht (tosfos) works on the AdManager extension and will be
working on Semantic MediaWiki-related extensions.
Welcome, Ike, Adam, and Alexander!
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Hi, everyone. I'm looking for some clarification about the process whereby
code gets deployed on the Wikimedia cluster. Not so much the technical
side of things, and in fact, I'd love to keep this conversation
VCS-agnostic. We'll be moving to git soon and things will change, but
these questions apply regardless.
I've been working to review a new extension that Petr Bena wrote,
InteractiveBlockMessage. It's a simple little extension that adds some
template magic for blocked users, to facilitate the creation of less
confusing talk page templates. This bug has links to the relevant code and
on-wiki discussions: https://bugzilla.wikimedia.org/show_bug.cgi?id=32819
Here's my present understanding of the process for community-contributed
code:
1. Discussion happens, a need arises, etc.
2. Someone writes some code, probably in the form of an extension
3. That extension is checked in and makes its way through code review. All
revisions must be ok'd to deploy.
4. On-wiki consensus is reached regarding deployment, and the discussion
closes.
5. A ticket is created to request deployment on a specific wiki
6. Someone Who's Been Around A While (Tim, Roan, maybe others) looks over
the code and decides it's okay
7. (maybe) A discussion regarding the extension happens here on wikitech-l.
8. The ticket gets picked up, extension gets deployed, ticket gets closed.
(Of course, I'm probably getting this wrong and I'm sure the steps are out
of order. Please correct.)
This differs rather significantly from the deployment process we've been
following for new code here in the office. That's more like:
1. Someone decides we need the code.
2. The code gets written
3. Code is checked in, makes its way through CR, must be ok'd before
deployment
4. A deployer schedules a window and deploys it.
Note that I'm leaving out the technical parts (creating a patch, pushing to
prototype, testing, etc...) That's unnecessary detail here. This message
concerns only the social part of the procedure.
My specific questions:
Process B is what I'm used to, but it seems that for this extension, it's
process A. When do we pick one or the other? Is process A for
community-contributed code, whereas B is for stuff from WMF? Do things
change when we're deploying a whole new extension? I understand that this
process is informal, and I'm not necessarily pushing to formalize it, but
maybe a few general guidelines or a minimum standard would help make things
more clear.
The step where Someone Who's Been Around A While reviews the code makes
sense, but it seems to be applied inconsistently, or perhaps the conditions
for that just aren't clear. When does code need to be run past one of
these very busy people, and when is it okay to push it without? Is there a
way to indicate which code needs this review, and when it's done aside from
the existing 'OK' status in CR? Secondly, who *are* these people? I've
heard Roan and Tim so far, but I bet there are more.
Is a discussion on wikitech-l generally part of the process in addition to
the on-wiki discussion? Is that only for new extensions, or for other
types of deployment as well?
I would love to get this worked out and document it, so community
developers can better understand how to get their code deployed. Of
course, if this is already documented somewhere please send me a link. :)
-Ian
Cross-posting.
---------- Forwarded message ----------
From: Steven Walling <swalling(a)wikimedia.org>
Date: Tue, Dec 20, 2011 at 11:58 AM
Subject: [Foundation-l] IRC office hours with the WMF features team, Jan.
4th 2012
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
Hey everyone,
Since folks have been asking about it, I wanted to announce that the
features development team at the Wikimedia Foundation will be holding an
office hours (in #wikimedia-office) about the general past, present, and
future of MediaWiki features being worked on here at the WMF.
This will be on January 4th, 2012 at 23:00 UTC. Documentation is on Meta
for time conversion and IRC how-tos.[1]
--
Steven Walling
Community Organizer at Wikimedia Foundation
wikimediafoundation.org
1. https://meta.wikimedia.org/wiki/IRC_office_hours
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
I'm running a firefox plugin called certpartol which alerts me to unusual
ssl cert changes.
The existing cert signed by GeoTrust, Inc. wasn't set to expire until
2016-07-19 02:17:12.
The new cert is signed by DigiCert Inc.
I just want to make sure this is an intentional change and not a fake cert.
I took a screenshot of the certpatrol warning @
http://img204.imageshack.us/img204/8463/screenshot20111220at953.png
Hi,
I am looking for some bug tracking thing where I could keep track of
how the various caching issues on Wikipedia are being addressed. Issues
like Wikipedia showing the "view source" tab rather than the "edit" tab,
or claiming there are pending revisions when there aren't. Some time ago
I'd have added broken images due to pending revisions, but that at least
seems to have been addressed. I also had, about two months ago, an issue
on Commons where a page would constantly automatically reload, unless
you did something like clicking Edit and then Read again, unless you did
clear your cache, in which case the issue would re-appear. I also had an
issue where some thread on the german Wikipedia would not be updated un-
less you forced some reload, and it would re-appear again if you happen
to clear your cache and re-connect to your ISP (meaning you get a new IP
address).
(This is all for users who are not logged into any account.)
I've tried a couple of times to find something on Bugzilla, but in over
a year and a half or so could not find much, so either I suck at search
or these problems have poor visibility.
(I'd post links, but the issues are not quite as reproducible as you'd
might like; a recent case I noticed was de:WP:K, some time after it was
locked it showed only "Show Source" rather than "Edit", but if you did
click "Show Source" that'd turn into "Edit". That was last week. I also
saw the "pending revisions even though there are none" issue after it,
but I don't recall which page it was on.)
regards,
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Facebook have announced that a JIT compiler for PHP called HipHop
Virtual machine (hhvm) is now at a fairly advanced stage of
development, and that they expect its performance to eventually exceed
that of the compiled binaries produced with hphpc:
<https://www.facebook.com/notes/facebook-engineering/the-hiphop-virtual-mach…>
We had planned on compiling MediaWiki with hphp, with project
completion and deployment to Wikimedia around April 2012, at least for
parsing. But the idea of a slow compile/test cycle (a few
processor-hours) was daunting. Slow compilation is a problem in
practice for Facebook, and one of the main reasons for this new hhvm
project.
So we've decided to defer our HipHop deployment until hhvm is at a
suitable level of maturity. We don't know exactly when that will be,
but Jason Evans says in the note linked above that "the first 90% is
done; now we're on to the second 90% as we make it really shine."
We still want to do something about parser performance in the first
half of 2012, so we're going to bring forward our other performance
project, i.e. server-side scripting embedded in wikitext. That's a
project which is still at an early stage of planning. We will need to
define its scope, and to bite the bullet and make some tough design
choices (such as Lua versus JavaScript), if it's going to progress
from pipe dream to reality.
An extension specific to citations (like TemplateAdventures) would be
an alternative if scripting proves to be too hard.
Deferring HipHop will affect our project priorities in other ways:
* We kicked around the idea of splitting out parsing into a separate
cluster of servers, accessible via an HTTP API. The main motivation
for doing that is gone now (it would have allowed us to use HipHop for
parsing and Zend for everything else).
* We shelved a project plan for better source file distribution (a
scap replacement), on the basis that it would be obsolete with HipHop.
And our system for having different versions of MediaWiki on different
wikis (HetDeploy) was implemented in a quick and dirty way, for the
same reason. These two projects may have to be revisited.
-- Tim Starling
