Hey everybody,
So today at the iSEC Partners security open forum I heard a talk from Zane Lackey,
the former security lead for Etsy, concerning the effectiveness of bug bounties.
He made two points:
1) Bug bounties are unlikely to cause harm, especially for Wikipedia, which I asked
him about, because the mere popularity of our service means we are already being
scanned, pentested, etc. With a bounty program, there will be incentive for people to
report those bugs rather than pastebin them.
2) Even without a monetary reward, which I imagine WMF would not be able to supply,
crackers are motivated simply by the “hall of fame”, or being able to be recognized for
their efforts.
Therefore, I thought it may be beneficial to take that over to Wikipedia and start our own
bug bounty program. Most likely, it would be strictly a hall of fame like structure where
people would be recognized for submitting bug reports (maybe we could even use the
OpenBadges extension *wink* *wink*). It would help by increasing the number of bugs
(both security and non-security) that are found and reported to us.
Any thoughts? (Of course, Chris would have to approve of this program before we even
consider it.)
--
Tyler Romeo
0xC86B42DF
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_June_30th>
A quick list of notable items...
== Monday ==
* CirrusSearch
** CirrusSearch will be turned on as primary on half of the remaining
wikis. 34 in this bunch.
** See: <https://gerrit.wikimedia.org/r/#/c/142590/>
== Tuesday ==
* Perfect Forward Secrecy (PFS)
** We will be enabling PFS on all wikis at about 10:00 UTC.
** Please let us know if you see any issues.
** <https://gerrit.wikimedia.org/r/#q,132393,n,z>
* CentralAuth GlobalRenameUser
** The new GlobalRenameUser tool will be enabled and usable.
* MediaWiki deploy
** group1 to 1.24wmf11: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf10>
* Entity suggester will be enabled on Wikidata
** See: <https://bugzilla.wikimedia.org/show_bug.cgi?id=66382>
* The new extension "Mantle" will be deployed on production wikis
** This is a new shared code extension in use by the Flow and Mobile
FrontEnd teams.
** see: <https://www.mediawiki.org/wiki/Extension:Mantle>
== Thursday ==
* MediaWiki deploy
** group2 to 1.24wmf11 (all Wikipedias)
** group0 to 1.24wmf12 (test/test2/testwikidata/mediawiki)
*** This will include the "Support | as a magic word" patch and thus
ride the train
*** see: <https://gerrit.wikimedia.org/r/#q,136234,n,z>
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.06. This bundle is compatible with MediaWiki 1.23.x and
MediaWiki 1.22.x releases.
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.06.tar…
* sha256sum: 02721b25e8c8fe06889b825a1c03fc4c1b1e4268d1e56169815983b5e87e8932
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CLDR, CleanChanges and LocalisationUpdate ==
* Only localisation updates
== Translate ==
=== Noteworthy changes ===
* New feature, Special:PageMigration page has been added and feedback
is welcome!
** Fetches and displays the translation units created by Translate for
the given page.
** Imports the old translations for given language on paragraph level
and displays them.
** Feature can be now conditionally enabled by setting
$wgTranslatePageMigration to true.
** Allows to edit or delete a translation as well as swapping with the
unit below.
** Allows to save the translations by creating corresponding pages.
** Enabled by default for translation admins.
* Special:AggregateGroups page is now visible to unprivileged users in
read-only mode.
* Email notifications are no longer sent upon translation review.
* Page title can be excluded from translation.
* Regression fix: Message checker live updates is working again with
this release.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Bug 64741: Fix 'Add links' option in Monobook skin when page has no
interlanguage links.
* Added support for Khakas language.
Thanks!
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Hi,
I would appreciate if somebody could have a look at
https://gerrit.wikimedia.org/r/139268
This is the second patch on a bug on CSSMin url() value remapping.
Remapping was thrown off if the CSS contained comments containing
curly braces. The fix just replaces all comments (except embed
directives) with placeholders and re-inserts them after the url()
value remapping.
The first patch (https://gerrit.wikimedia.org/r/#/c/138286/) had to be
reverted. It involved fixing the regex used for the url() remapping
directly and would have worked, too, only the rule became too
complicated, so preg_replace bailed out on large chunks of CSS.
So, anybody up to it?
Cheers,
Stephan
Minutes and slides from Monday's quarterly review of the Foundation's
Analytics team are now available at
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
.
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
Hi all,
We've got the first DRAFT (sorry for shouting, but can't hurt to
emphasize :)) of the annual goals for the engineering/product
department up on mediawiki.org. We're now mid-point in the process,
and will finalize through June.
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals
Note that at this point in the process, teams have flagged
inter-dependencies, but they've not necessarily been taken into
account across the board, i.e. team A may say "We depend on X from
team B" and team B may not have sufficiently accounted for X in its
goals. :P Identifying common themes, shared dependencies, and
counteracting silo tendencies is the main focus of the coming weeks.
We may also add whole new sections for cross-functional efforts not
currently reflected (e.g. UX standardization). Site performance will
likely get its own section as well.
My own focus will be on fleshing out the overall narrative, aligning
around organization-wide objectives, and helping to manage scope.
As far as quantitative targets are concerned, we will aim to set them
where we have solid baselines and some prior experience to work with
(a good example is Wikipedia Zero, where we now have lots of data to
build targets from). Otherwise, though, our goal should be to _obtain_
metrics that we want to track and build targets from. This, in itself,
is a goal that needs to be reflected, including expectations e.g. from
Analytics.
Like last year, these goals won't be set in stone. At least on a
quarterly basis, we'll update them to reflect what we're learning.
Some areas (e.g. scary new features like Flow) are more likely to be
significantly revised than others.
With this in mind: Please leave any comments/questions on the talk
page (not here). Collectively we're smarter than on our own, so we do
appreciate honest feedback:
- What are our blind spots? Obvious, really high priority things we're
not paying sufficient attention to?
- Where are we taking on too much? Which projects/goals make no sense
to you and require a stronger rationale, if they're to be undertaken at all?
- Which projects are a Big Deal from a community perspective, or from
an architecture perspective, and need to be carefully coordinated?
These are all conversations we'll have in coming weeks, but public
feedback is very helpful and may trigger conversations that otherwise
wouldn't happen.
Please also help to carry this conversation into the wikis in coming
weeks. Again, this won't be the only opportunity to influence, and
I'll be thinking more about how the quarterly review process can also
account for community feedback.
Warmly,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Hello,
Earlier today I slightly changed how Jenkins run the MediaWiki extension
job. Specifically the way the database is updated.
We used to simply:
php maintenance/update.php
I wanted to log the SQL queries behind added to the database and the
script has a --schema option to do just that. So Jenkins now:
php maintenance/update.php --schema update_sql.log
sleep 1
php maintenance/update.php
The sleep is needed because --schema still write to the update_log
database. The two runs ends up having the same ul_key in the table
since it just vary by timestamp (so if two run occurs in the same
second, the second has a duplicate key error).
There should be a better fix, but sleep 1 works ™
Flow had an issue with the tests failing because --schema still run the
post-db maintenance script (might be the cause of above problem).
Erik Bernhardson figured out a temporary workaround for Flow:
https://gerrit.wikimedia.org/r/#/c/142303/
The issue is tracked by https://bugzilla.wikimedia.org/67163
Any help welcome!
--
Antoine "hashar" Musso
dumps.wikimedia.org, downloads.wikimedia.org will be down on Thursday
June 26 from 13.30 UTC until 14.30 UTC. While we expect the actual
downtime to be much less, we're blocking one hour just in case.
We will be moving it to a new rack in preparation for improved
bandwidth, and yes this mean raising download caps.
Services affected: dumps and pageview downloads, any other files hosted
on the server.
Dumps themselves will be stopped during the duration of the downtime.
They will be restarted as needed once the host is back on line.
Ariel