Meant to CC Wikitech-l too...
---------- Forwarded message ----------
From: Tilman Bayer <tbayer(a)wikimedia.org>
Date: Wed, Jun 25, 2014 at 8:37 AM
Subject: Re: [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
Minutes and slides from last Friday's quarterly review of the
Foundation's Parsoid 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
Can we have that? so that people can filter out bugs that are require
skills for certain languages only?
For example if I needed to fix something that is C++ I would just tag
it so, same for PHP, JS, etc... So that C++ devs could filter out only
all bugs that require C++ knowledge and see all bugs across all of
wikimedia that can be fixed in that language.
Developers could then simply filter out only bugs that they are
interested in or able to fix.
There are three important bugs that need to be fixed in VE before we can
move it to stable for tablets (specifically iPads). The first two were
added by me just today. The third was reported in May by Rummana and for
some odd reason had Jon assigned to it, although he has never worked on it
(I removed him).
Following Roan's suggestion I recorded videos on iOS simulator to
illustrate what is happening in each case (thanks to Monte for letting me
use his Macbook with up-to-date Xcode).
https://bugzilla.wikimedia.org/show_bug.cgi?id=66999https://bugzilla.wikimedia.org/show_bug.cgi?id=67002https://bugzilla.wikimedia.org/show_bug.cgi?id=65326
Let us (the mobile team) know if you need any help with those.
--
Juliusz
Chris Steipp submitted a patch add namespaces to the OAuth extension
[0] in order to fix a compatibility issue with HHVM [1]. This change
led to a bit of bikeshedding on the proper namespace to use for the
extension. Chris initially chose `MWOAuth` but later amended to use
`MediaWiki\Extensions\OAuth` at my suggestion.
There is some discussion in gerrit, but my primary arguments were made
in irc (and in an unlogged channel no less), so I thought this topic
would be worth dragging out in front of everyone for a little debate.
I don't know of anyone who is actively trying to change MediaWiki core
to use namespaces, but extensions are using them. This leads me to
think that we should think as a group about the "right way" to use
namespaces and how to chose namespaces.
I suggested MediaWiki\Extensions\OAuth because it seems like the most
natural naming to me. PSR-4 [2] is very opinionated about namespaces.
It requires a top-level (or vendor) namespace. I chose "MediaWiki"
because ... MediaWiki. Beyond that sub-namespaces are optional, but
the file system path from the base directory to the php file must
match. Assuming that $IP is the base directory led me to suggest
MediaWiki\Extensions\OAuth.
The loudest argument I've heard here (and elsewhere) about using
namespaces like MediaWiki\Extensions\OAuth is that there are too many
characters to type. This, in my opinion, is really a we-fear-change
argument. With full PSR-4 namespacing, the longest fully qualified
class name would be
"MediaWiki\Extensions\OAuth\Frontend\SpecialPages\SpecialMWOAuthConsumerRegistration.php"
[3]. I will give no argument that this is a short string. I will say
however that I spent enough of my career working in java [4] on a
codebase with fully qualified class names like
"org.accessidaho.apps.itd.dlr.common.pLAZma_RestrictionModel" [5] to
find out two things: you typically type a fully qualified class name
once per file at most, and any reasonable editor can be configured to
have tab completion and/or macro expansion for commonly typed strings.
[0]: https://gerrit.wikimedia.org/r/#/c/141608/
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=66929
[2]: http://www.php-fig.org/psr/psr-4/
[3]: This could be shortened a bit by removing the embedded pseudo-namespacing
[4]: "A witch! Burn him!"
[5]: Not meant as an example of a good classname
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
I just +2'ed a change to add a few basic selenium tests to core [1]. I
think it will benefit us all to have a set of automated tests to
quickly make sure mediawiki is working correctly. From a security
perspective, this also takes a step towards more efficient security
testing, which I'm also a fan of (if you've tried blindly scanning
mediawiki, you know what I'm talking about..).
I think the QA group is working on vagrant-izing these, but if you
have ruby >1.9.3 and firefox, then setting up and running these tests
on your local dev system is 4-6 commands,
$ cd tests/browser
$ gem update --system
$ gem install bundler
$ bundle install
You can either set your environment variables yourself, or edit
environment_variables and run `source environment_variables` to set
them. Then it's just
$ bundle exec cucumber features/
to run the tests. They currently complete in 36 seconds on my laptop.
I'd like to see more tests added and backported to REL1_23 to make
sure we have an ongoing suite to check releases against for next few
years that we support that LTS. If anyone is interested in both
mediawiki core and browser tests, I'm sure the QA team would like to
get you involved.
Big thanks to hashar, Chris McMahon, and Dan Duvall for indulging me
and getting this done. I'll let them jump in with all the details I've
missed.
[1] - https://gerrit.wikimedia.org/r/#/c/133507/
Hi folks,
I just wanted to provide a brief (and belated) announcement regarding some
added help we've enlisted over the summer on the Multimedia team.
Brian Wolff has been doing little bits of contracting work over the course
of his school year (as well as a lot of volunteer development), and this
summer will be doing a lot more contracting work. He plans to spend his
time taking out various bugs in all multimedia components. He's been at it
for a few weeks now, and has already made a lot of headway.
Neil Kandalgaonkar will be working with us this summer on unit tests for
UploadWizard. Neil originally wrote and maintained UploadWizard as an
employee of Wikimedia Foundation between 2009 and 2012. We're delighted to
have him back for a little while to help bootstrap our work on improving
UploadWizard.
Welcome guys! \o/
Rob
Hi.
Re: https://www.mediawiki.org/wiki/Manual:$wgNamespacesWithSubpages
Is there a reason NS_MAIN is not included in $wgNamespacesWithSubpages by
default? My understanding is that historically NS_MAIN wasn't included in
this array because the English Wikipedia and others don't use subpages in
their main namespace. But that's probably no longer really relevant. The
current default array (copied below from DefaultSettings.php) seems like
it should include NS_MAIN by default. My feeling is that wikis that don't
want to use subpages in the main namespace simply won't (the fallback
behavior here is pretty clean unless you're running an "AC/DC" wiki) and I
think most MediaWiki installations would want NS_MAIN included in the
default (e.g., the manual page's first custom configuration entry
addresses this issue... it comes up quite a bit).
Thoughts on adding NS_MAIN to $wgNamespacesWithSubpages in MediaWiki core?
I briefly searched Bugzilla for a previous discussion of this topic, but
couldn't find any relevant tickets.
Current default:
---
$wgNamespacesWithSubpages = array(
NS_TALK => true,
NS_USER => true,
NS_USER_TALK => true,
NS_PROJECT => true,
NS_PROJECT_TALK => true,
NS_FILE_TALK => true,
NS_MEDIAWIKI => true,
NS_MEDIAWIKI_TALK => true,
NS_TEMPLATE_TALK => true,
NS_HELP => true,
NS_HELP_TALK => true,
NS_CATEGORY_TALK => true
);
---
Proposed array addition:
---
NS_MAIN => true,
---
MZMcBride