Hi Sumana,
I asked around about priorities on RFCs in MediaWiki Core's weekly
meeting. Nothing popped up, but I made it clear that I plan to be
persistent with that question.
I specifically asked about the RCStream RFC, and Tim suggested it does
need more discussion. Link for your convenience:
https://www.mediawiki.org/wiki/Requests_for_comment/Publishing_the_RecentCh…
We also briefly discussed Structured Logging. It's mainly blocked on
the Composer RFC. Once that's done, the structured logging RFC seems
to have received adequate review for now; any remaining conversation
can happen in the normal course of code review of the structured
logging implementation, which is pretty much done.
Rob
Minutes and slides from Wednesday's quarterly review of the
Foundation's MediaWiki Core team are now available at
https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_revi…
(agenda/overview page:
https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_revi…
)
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 folks,
Looks like we've got some holes to fill in here:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/June
Rob
---------- Forwarded message ----------
From: Guillaume Paumier <gpaumier(a)wikimedia.org>
Date: Mon, Jul 14, 2014 at 2:11 AM
Subject: Re: June engineering report: please add your status updates
To: Mark Bergsma <mark(a)wikimedia.org>, Andrew Russell Green <
agreen(a)wikimedia.org>, Rob Lanphier <robla(a)wikimedia.org>, Emmanuel
Engelhart <kelson(a)kiwix.org>
Hi,
A friendly reminder; a few activities are still missing status updates
for the monthly report. Please add them today, as I need to publish
the report tomorrow (before I go on leave for the rest of the week).
Thanks!
On Mon, Jun 30, 2014 at 1:55 PM, Guillaume Paumier
<gpaumier(a)wikimedia.org> wrote:
>
> As usual, the month is ending and we need to add status updates so we
> can publish the report before the next Metrics meeting (this
> Thursday):
>
> https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/June
--
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
Hi folks,
One thing I should have brought up in our weekly meeting this week is the
quarterly review coming up next week (July 16).
I've started the wiki page here:
https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_revi…
There is much prose-ifying left to do on this. The current state of the
page is that the section headers are correct, but the contents need a lot
of work. The "previous quarter" part is a copy-paste of the "next quarter"
sections in last quarter's review page, so it needs to be turned into a
retrospective.
While we're behind on the preparation of our presentation, the good news (I
believe) is that our plan is reasonably clear moving forward, thanks to the
annual planning process. Our big projects are HHVM and SUL finalization.
What I think makes sense for this review is to break it up by project,
going with highest priority first, and having individual leads for each
section. So, what this means:
* Ori - HHVM / Performance
* Dan - SUL finalization
* Nik (or Dan?) - Search
* API hub - Sumana
* SecurePoll redesign - Dan
* Everything else - Rob
Make sense? If so, I'll get started on a slide deck that you can fill in
your bits on. Nothing fancy....just bullet points will be fine.
Thanks
Rob
I just rebased a few of my old patches, and I'm hoping someone will decide
to review (and hopefully merge) them before they need still-another rebase.
API:
* https://gerrit.wikimedia.org/r/#/c/62229/ - Fixes a fatal error in the
API, waiting since May 2013.
* https://gerrit.wikimedia.org/r/#/c/111954/ - Yuri had an IMO pointless
objection, but in the interest of getting the thing merged...
* https://gerrit.wikimedia.org/r/#/c/130093/ - Just addressed suggestions
and added a fix for yet-another bug in this code.
Scribunto:
* https://gerrit.wikimedia.org/r/#/c/55602/ - Last in a long series of
patches that were slowly merged over the past year
* https://gerrit.wikimedia.org/r/#/c/84985/ - luasandbox fix for passing a
table with a __pairs function to PHP code
Thanks
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
See
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Search_stu…
I've had suspicions that lsearchd is a little wonky on indexing for some
time but
never had any firm cause pinned down. Considering we can probably fix the
indexer faster than I can deploy Cirrus to enwiki, let's try to unbreak
lsearchd for
the last time.
Mainly pinging Tim since he knows lsearchd as well as anyone on this list.
Pinging Nik to help Tim as needed.
Pinging Dan to keep an eye on the VPT thread please.
-Chad
I had a useful conversation about Puppet changes with Mark and Faidon. The
outcome is this: the conditions under which I am allowed to merge Puppet
changes are:
1) The change is my own
2) The change has been +1'd by an ops team member with sufficient domain
expertise
Sometimes you guys add me as the sole reviewer of small Puppet changes.
Please be aware that I am not able to merge those changes on my own, and
help me out by adding some relevant opsen. Giuseppe (_joe_ on irc) is my
buddy for mediawiki-related changes so he's a good person to add. Adding
whomever is on RT duty is probably a good idea as well. You can still add
me for initial review and +1 / -1.