Brion and Tim hope to chat with Jon Robson, Pau Giner, Juliusz Gonera, and
other interested folks about the current UI styling RFCs. More information:
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-27
These meetings move around so we can sometimes accommodate Europe,
Australia, or various bits of North America, depending on who needs to be
in the meeting. This time the meeting's 00:00 UTC until 1:00 UTC on Feb 28:
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=2…
San Francisco: Thursday, February 27 at 4 PM
Berlin: Friday, 28 February at 1 AM
Mumbai: Friday, 28 February at 5:30 AM
Sydney: Friday, 28 February 2014 at 11 AM
As usual, it's in IRC, in #wikimedia-office on Freenode.
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Minutes and slides from this week's quarterly review of the
Foundation's Core features 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
Chrome beta (version 34) now includes native 'srcset' support:
http://www.chromestatus.com/features/4644337115725824
This means that on high-density screens like a Retina MacBook Pro, the 1.5x
or 2.0x-size image will be loaded automatically by the browser, and our
JavaScript hack disables itself. I've confirmed that this works as expected
with Chrome 34 beta and 35 'canary' builds.
This means faster page loads on hi-dpi devices and less unnecessary default
loading of 1.0x-size images when they're not going to be used.
Presumably this is also coming to Chrome for Android, where it's more
important due to the large number of Android devices running at 1.5 or 2.0
(or even 3.0) display density (hdpi/xhdpi/xxhdpi):
http://developer.android.com/about/dashboards/index.html#Screens
-- brion
Hi, I am Inderpreet Singh, this is my first mail and I hope I am on
correct mailing list. I am currently working on an online geometry
viewer that was developed under BRL-CAD (brlcad.org) as one of it's
GSOC projects last summer. It's in it's very basic stage. It currently
allows you to upload a CAD model (.g file) and view it 3D in the
browser. I was planning to add a feature that would allow users to
embed their models on websites and share it, (think of it as
http://codepen.io/ for CAD). Also, we were planning to add a mged
command interface so that we can edit the CAD model online using mged
commands. We were having discussions over these when someone among us
pointed out that there is a need of similar extension for mediawiki. I
would really love to know more about the requirements and propose
BRL-CAD (one of the oldest open
source repositories in world) on a server with web-interface as a full
open source candidate for the required tool.
--
Inderpreet Singh
Ekoankar Sahai
ishwerdas.comfacebook.com/okayinderhttps://kippt.com/okayinder
Вы можете прочитать сообщение и ответить на него через наш чат.
Откройте своё сообщение
http://eu1.badoo.com/0311318950/in/fIgvQLfMBoI/?lang_id=2&g=57-0-4&m=29&mid…
Они ждут встречи с вами:
Если ссылка не работает, скопируйте и вставьте её в адресную строку браузера.
До скорого!
Команда Badoo
Вы получили это письмо от Badoo Trading Limited (почтовый адрес ниже). Если вы не хотите получать уведомления от Badoo, нажмите здесь: https://eu1.badoo.com/impersonation.phtml?lang_id=2&email=wikitech-l%40wiki….
Badoo Trading Limited зарегистрирована в Англии и Уэльсе под номером CRN 7540255 по юридическому адресу: Media Village, 131 - 151 Great Titchfield Street, London, W1W 5BB.
Вы можете прочитать сообщение и ответить на него через наш чат.
Откройте своё сообщение
http://eu1.badoo.com/0311318950/in/G1x.KSiSP6U/?lang_id=2&g=57-0-4&m=29&mid…
Они ждут встречи с вами:
Если ссылка не работает, скопируйте и вставьте её в адресную строку браузера.
До скорого!
Команда Badoo
Вы получили это письмо от Badoo Trading Limited (почтовый адрес ниже). Если вы не хотите получать уведомления от Badoo, нажмите здесь: https://eu1.badoo.com/impersonation.phtml?lang_id=2&email=wikitech-l%40wiki….
Badoo Trading Limited зарегистрирована в Англии и Уэльсе под номером CRN 7540255 по юридическому адресу: Media Village, 131 - 151 Great Titchfield Street, London, W1W 5BB.
Hi all, I wanted to bikeshed just a little bit, to make sure there is some
consensus.
tl;dr We're upgrading the password hash used to store passwords to make
offline cracking more difficult. In doing that, we need to set one of the
options as default. Speak up if you have strong feelings about one over the
other.
Along with refactoring how passwords are stored and checked,
https://gerrit.wikimedia.org/r/#/c/77645 implements two strong hashing
algorithms PBKDF2 [1] and bcrypt [2]. I added a followup commit to add in
the algorithm that Tim came up with in 2010 using Whirlpool as a hash
function [3].
For any of these, there is a maintenance script to wrap current passwords
with one of the strong ones, so we can upgrade the whole database without
interaction from the users. It's also simple to upgrade the work factor or
change to a new algorithm, if we decide that is needed in the future. But
for the actual default...
Bcrypt is probably the most common option for password storage in webapps
that I see. PHP 5.5 uses it as the default for the new password_hash()
function. The only issue is that PHP before 5.3.7 had a flaw in their
implementation which resulted in weak hashes. If we set bcrypt as default,
we would want to raise the minimum php version to 5.3.7 (it's currently
5.3.2) for MediaWIki 1.23.
PBKDF2 is an RSA standard and is included in PHP 5.5. Tyler did an
implementation in the patch to make it backwards compatible. The only
downside to it is the connection to RSA, who may have knowingly
standardized weak algorithms, although the security properties of PBKDF2
are fairly well studied and haven't been called into question.
The Whirlpool algorithm by Tim would force password cracking software to do
a custom implementation for our hashes. It has very similar work effort to
bcrypt, and should keep our passwords as safe as using bcrypt. The theory
behind it seems good, but obviously, we might discover a gaping hole in it
at some point.
Is there any strong preference among these options? My personal vote is for
bcrypt, if bumping the php version doesn't seem like a big deal to everyone.
[1] - https://en.wikipedia.org/wiki/PBKDF2
[2] - https://en.wikipedia.org/wiki/Bcrypt
[3] -
http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg08830.html
I just wanted to report a bug, and info-en(a)wikipedia.org referred me here.
Sadly, upon trying to create a pdf (using the otherwise genius
Print/export feature) of a page that involves lines above letters
(e.g. http://en.wikipedia.org/wiki/List_of_mesons) the lines above
letters (here essential to indicate the difference between Particle
and Antiparticle) just disappear.
In the linked Article that can be seen in the caption under the first
Image where the pdf then contains the text "The strange antiquark (s)"
despite there being a line above the "s" in the online Article.
greetings,
Daniel