In the next RFC meeting, we will discuss the following RFC:
* Integrate file revisions with description page history
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CEST: Wednesday 23:00
* Australia AEST: Thursday 07:00
-- Tim Starling
After a long and intense selection process, Google and GNOME Foundation
have finally announced the list of GSoC and Outreachy selects for the
current round. I'm pleased to announce we have 9 interns for GSoC and 1 for
Congratulations to everyone selected and to the mentors who have put in
much hard work in selecting worthy candidates. Also thanks to those who put
in hard work but could not be selected. We had limited projects and had to
make some hard decisions. We hope you'll keep contributing to Mediawiki and
try again for the next GSoC/Outreachy round.
We have a general guide to being a successful intern at
still under development and we'll be adding more details to it as we move
forward in the program. The main pages for the respective programs are at
The students selected are:
1. Dibya Singh (Phenix303) from India
Project: One-stop Translation Search
Mentors: Nemo_bis and Nikerabbit
Google Summer of Code:
2. Frédéric Bolduc (ferdbold) from Quebec
Project: GraphData extension for VE
Mentors: Mooeypoo and Mvolz
3. Ankita Kumari (ankita-ks) from India
Project: Unified language proofing tools integration framework
Mentors: Aharoni and Eranroz
4. Jiarong Wei (VcamX) from Hangzhou, Zhejiang
Project: Implement OAuth support for Pywikibot
Mentors: Jayvdb and Halfak
5. Tina Johnson (tinajohnson) from India
Project: Newsletter Mediawiki Extension
Mentors: Quim Gil and Tony Thomas
6. Vivek Ghaisas (polybuildr) from India
Project: Extension to identify and delete spam pages
Mentors: Yaron Koren and Jan
7. Sumit Asthana (codezee) from India
Project: Wikivoyage Pagebanner Extension
Mentors: Nicolas Raoul and Jdlrobson
8. Alexander Jones (happy5214) from United States
Project: Implement Flow support in Pywikibot
Mentors: Jayvdb and Mattflaschen
9. Jan Lebert (sitic) from Germany
Project: An enhanced cross-wiki watchlist
Mentors: Yuvipanda, Legoktm
10. Sarvesh Gupta (s1991) from India
Project: Allow contributors to update their own details in tech metrics
Mentors: Alvaro, Daniel
Let's all welcome them into the Wikimedia family!
Thanks for your work on this, Chris.
Forwarding to Wikitech-l.
On Apr 20, 2015 4:58 PM, "Chris Steipp" <csteipp(a)wikimedia.org> wrote:
> On Apr 20, 2015 4:13 PM, "Andrew Sherman" <asherman(a)wikimedia.org> wrote:
> > Hello Everyone,
> > We just published "Improving the security of our users on Wikimedia
> sites" to the blog. URL:
> > https://blog.wikimedia.org/2015/04/20/improving-security-for-our-users/
> > Thanks to Chris for writing and helping us edit this post.
> > Below are some proposed social media messages. Tweak as needed.
> > Twitter
> > We teamed up with @iSECPartners and @OpenTechFund to assess the security
> of our sites. Check out the report here [link]
> > FB/G+
> > We teamed up with iSEC Partners to assess the security of our sites and
> protect the privacy of our users. Their engineers developed attacks against
> the current version of MediaWiki to identify security flaws, in a new
> report sponsored by the Open Technology Fund. [link]
> Maybe just "MediaWiki" instead of "the current version of MediaWiki",
> since we did a release to specifically fix issues that they found. Might
> confuse some people as is.
> > Thanks,
> > --
> > Andrew Sherman
> > Digital Communications | Wikimedia Foundation
> > E: asherman(a)wikimedia.org
> > WMF: ASherman (WMF)
> Social-media mailing list
What is the best way (in code) to locate the most recent revision of article in which the text actually changed? That is, the revision was not a "move" or other non-editing operation?
I figure the logic would be something like:
$r = GetTheMostRecentRevision();
IF $r NOT a "Move"
walk the list of revisions until the SHA1 value changes
but I don't know how to determine that a revision is a "Move."
Thanks for any tips!
I was trying to develop a MediaWiki skin based on Bootstrap3. I am facing
several type of issues at the time of doing this. MediaWiki is forcing me
to use the default vector styles and for may of the pages it is "very hard"
to use own CSS classes, for example Special:Allpages. I am lucky that my
skin/bootstrap default is similar with the MediaWiki UI and i enabled it in
everywhere. But even this could not cover the page " Special:Allpages ".
I found it very complex to develop a new skin for MediaWiki and it forces
everyway to use the default vector skin. About a year ago i headed a
project on "Separating skins from core MediaWiki", could anyone please let
me know the progress and current status of that project.
 - http://en.banglapedia.org/index.php?title=Special:AllPages
*Nasir Khan Saikat*
the quarterly reviews for the past quarter (January-March 2015) took
place last week. Minutes and slides are now available for the
Community Engagement, Advancement (Fundraising and Fundraising Tech):
Mobile Web, Mobile Apps, Wikipedia Zero:
Parsoid, Services, MediaWiki Core, Tech Ops, Release Engineering,
Multimedia, Labs, Engineering Community:
Editing (covering VisualEditor), Collaboration (covering Flow),
As mentioned in February , the quarterly review process has been
extended to basically all groups in the Foundation since Lila took the
helm last year, and it was further refined this quarter, reducing the
number of meetings to six overall, each combining several areas.
Minutes and slides from the remaining two meetings should come out
soon, too. (And naturally, all the engineering team names above refer
to the structure before the reorganization that has just been
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 :
> - 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:
> - Editor Engagement Experiments
> - Visual Editor
> - Mobile (Contribs + Zero)
> - 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 , 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:
> The internal review will, at minimum, include:
> Sue Gardner
> 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
> 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,
>  https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
>  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
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
IRC (Freenode): HaeB
T43345 <https://phabricator.wikimedia.org/T43345>is classified as a high
priority, and hasn't been fixed for three years. Getting a column added to
indicate that a language link is stored in a foreign repo shouldn't be this
hard. I can think of quite a few cases where this data could be leveraged
in one way or another. Wikidata is extremely widely used, and we still dont
have this basic feature implemented, who needs pressured to get progress
made on this? this should be a fairly straight up and trivial feature to
OOjs UI 0.10.0 was released on Wednesday. It will be in MW from 1.26wmf4+.
As there are several breaking changes, please look carefully over them to
determine if they affect your code.
Breaking changes since last release:
- [BREAKING CHANGE] ButtonWidget: remove deprecated nofollow option
alias (C. Scott Ananian)
This was deprecated in v0.8.0, at which point it was already unused as far
as we are aware. The real config option, "noFollow" (with a capital 'F')
continues to work as before.
- [BREAKING CHANGE] Convert ToggleWidget from a mixin to an abstract
class (Bartosz Dziewoński)
This is only technically a breaking change; the interface and behaviour of
the widgets built on top of ToggleWidget are unchanged.
- [BREAKING CHANGE] MenuLayout: Reimplement without inline styles
Menu size can be set using CSS now. MenuLayout's CSS will override the
appropriate values with 'auto' or '0' to display the menu correctly. If
`menuPosition` is known beforehand, CSS rules corresponding to other
positions may be omitted. This was a bit of a mess (and only used by one
consumer, already fixed). The behaviour of the 'showMenu' and
'menuPosition' configuration options is unchanged.
Additional details are in the full change log. If you have any further
questions or need help dealing with deprecations, please let me know. As
always, general library documentation is available at mediawiki.org and
generated code-level documentation at doc.mediawiki.org.