I was poking around in UploadBase today because Quim asked how we
checked SVGs to make sure they are not full of nasty javascript stuff
and realised that we have a non-trivial amount of code in there for
that purpose. That got me wondering if that code and other scanning
and filtering things would be a good candidate for a library to
extract share with the wider world. Thoughts?
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
Minutes and slides from the recent quarterly review meeting of the
Foundation's MediaWiki Core team can now be found at
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
Hey guys,
See this note from Katie. Summary:
1) PCI compliance says that the code they deploy to the payments
cluster must have peer-review.
2) There are 35 commits to core that are self-merged with no review
(see Elliot's script).
Retroactively +1ing the changes is probably sufficient (after you've
reviewed the change, of course :) ).
Deadline appears to be "before November".
Help?
Greg
PS: Katie is cc'd, but I don't think she is on ourlist.
---------- Forwarded message ----------
From: Katie Horn <khorn(a)wikimedia.org>
Date: Tue, Oct 14, 2014 at 3:59 PM
Subject: Self-reviews in core between 1.22 and 1.23
To: Greg Grossmeier <greg(a)wikimedia.org>
Hey Greg,
Thanks for looking in to this. Elliott came up with the following awk
script and its subsequent output, both attached.
To summarize: PCI rules say that we can not deploy code to payments
systems if there were any unreviewed (self-merged) patches, and we
found about 35 in the upgrade of mediawiki core that fundraising would
like to do before November.
It should be sufficient to have somebody other than the original
committer retroactively +1 the patch in gerrit. Just so I can prove
everything had extra eyes on it before we deploy the code to payments.
Please let me know if something went wrong with the attachments, and I
will gladly resend.
Thanks!
-Katie
---------- Forwarded message ----------
From: Elliott Eggleston <eeggleston(a)wikimedia.org>
Date: Tue, Oct 14, 2014 at 3:48 PM
Subject: Fwd: Fwd: For your inner PCI lawyer
To: Katie Horn <khorn(a)wikimedia.org>
Do this log command and the attached awk script look correct?
git log --no-merges --show-notes=review --name-status
fundraising/REL1_22..REL1_23 -- *php *php5 skins resources includes >
allLog
./findSelfMerge.awk < allLog > unreviewed.txt
--
Greg Grossmeier
Release Team Manager
A login/account creation issue we found on beta cluster is now on
production.
Help very much appreciated before it goes out further (or we have to
revert/hold the train).
Greg
--
Sent from my phone, please excuse brevity.
---------- Forwarded message ----------
From: <bugzilla-daemon(a)wikimedia.org>
Date: Oct 11, 2014 4:16 PM
Subject: [Bug 71862] "There was an unexpected error logging in" when
creating accounts on Beta
To: <greg(a)wikimedia.org>
Cc:
Sam Reed (reedy) <sam(a)reedyboy.net> changed bug 71862
<https://bugzilla.wikimedia.org/show_bug.cgi?id=71862>
What Removed Added Priority Normal Highest
*Comment # 12 <https://bugzilla.wikimedia.org/show_bug.cgi?id=71862#c12>
on bug 71862 <https://bugzilla.wikimedia.org/show_bug.cgi?id=71862> from
Sam Reed (reedy) <sam(a)reedyboy.net> *
Seems to be affecting production now...
------------------------------
You are receiving this mail because:
- You are on the CC list for the bug.
I'm trying to compare the feeling of the group (that we know exactly
why we are here and how this aligns with the WMF mission) and my
personal feeling (that we do whatever is asked and often the asks are
questionable).
I'm willing to admit that some of the difference in viewpoint is based
on the particular work that I have done over the last year. I have
been on loan to Multimedia, developed Wikimania Scholarships, on loan
to Release Engineering and developed IEG grant review. In between and
overlapping I worked briefly on the "DevOps sprint", setup logstash,
rewrote scap and dabbled in HHVM related research. This level of
bouncing around and number of solo projects has not given me a great
feeling that I'm on a well scoped team. It actually makes me feel like
I'm just a gun for hire (or worse monkey at a keyboard) to be called
to service whenever and wherever RobLa and Erik feel an extra hand is
needed.
I'm not looking for pity or a "you're doing good job Bryan" out of
this rant, I'm just trying to make my point of view clear. I've
actually generally enjoyed the work that I've done here and have
certainly had plenty of things to keep me busy and learning. I am
however interested in acquiring a better model of what it is that I
should be trying to do when I have the opportunity to choose work from
the never ending list of things that could be done. I feel that this
is important not just for me personally but for the team as a group
when doing things like grooming our collective project backlog and
defending our choices to management.
I went to the wiki page for our group [0] and found this list of
"responsibilities" for the MediaWiki Core team:
* Manage the MediaWiki release cycle
* Ensure that MediaWiki core is meeting the evolving needs of the website
* Make quality MediaWiki releases available for others outside of the
Wikimedia Foundation
* Develop and document a clear set of APIs so that external developers
can create applications that easily interface with MediaWiki
This seems out of date to me. I think that the newly formed Release
Engineering team is responsible for the first and third bullet points.
That leaves "meeting the evolving needs of the website" and "develop
and document a clear set of APIs" still on our plate. Neither of these
seems like something that can be used to exclude much work from
consideration. This can be seen as a good thing when the team is
presenting their ideas outwardly, but it seems like a double edged
sword for incoming work requests. It also feels like something is
missing here. I really don't see any mention of our team's role in
code review and stewardship of quality for MediaWiki and
responsibility for security and performance considerations.
I think it would be a worthwhile exercise to spend some time next week
talking about what it is that we do here and what reasonable
boundaries and expectations we would like to set with the Foundation
and the community.
[0]: https://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering#MediaWiki_Core
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've started an etherpad [0] with some ideas about what we could try
to do for the Q2 Library infrastructure project. Since this morphs a
bit every time two or more of us talk about it, I'd like to get some
collective notes/input before we walk into the quarterly review to
pitch the idea and let the group there tell us what we should be
doing.
I know that I want to finish the logging work. I think this can be
used as a good example of how to consume external libraries in
MediaWiki core as well as helping solve a real deficiency in our
existing code base. My RFC on the topic is a good start but the
processes and procedures outlined there need to be published in a more
visible place on wiki and battle tested for deficiencies.
I think I'd also like to see the Profiler work done as I've heard that
many components in MediaWiki are basically only tied to logging and
profiling. I'm totally willing to be persuaded that there is a better
candidate for extracting into a library however. One question I'd like
to ask is "what functionality from MediaWiki do you miss when you
write a standalone PHP app?" Database? Caching? I18n bits and pieces?
Is one of these more compelling for extracting and publishing than the
profiler?
I'd also like to hear ideas about how we should be documenting the
extracted libraries. Should we have a different workflow for
generating docs from code? Is publishing docs as wiki pages a good,
bad or meh idea? If we don't document on wiki how can we encourage
document contributions from casual users? If we do document on wiki
how can we ensure that changes in the API are propagated to the
documentation soon after merge? How important is localization for code
documentation?
In case you are wondering "who put Bryan in charge here?", the answer
is RobLa. :) Following in the model of the HHVM project where Ori has
been acting as project manager / product owner, RobLa has tapped me to
take the lead on organizing the library infrastructure project if it
gets green lighted. I'll need a lot of help since I still don't know
as much about MediaWiki itself as our average 13 year old contributor,
but I hope I can be of service with my experience in project and
product management.
[0]: https://etherpad.wikimedia.org/p/MWCoreLibraryInfrastructure
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