Currently, while {{urlencod}}ing, content in strip markers is skipped.
I believe this violates the expectation that the entire output
will be properly escaped to be placed in a sensitive context.
An example is in the infobox book caption on,
https://en.wikipedia.org/wiki/%22F%22_Is_for_Fugitive
There’s a brief discussions of the security implications of
some proposed solutions in the review of,
https://gerrit.wikimedia.org/r/#/c/181519/
It seems best (I guess) to just drop the content (`killMarkers()`).
Any opinions or better ideas?
Thanks,
Arlo
Oh what a day! Which began when perforce
a visitor from afar began to exhort
us to look far afield, to travel and visit
learn brand new things, uncover, elicit
stories of users far from our homes!
And so we set out, bravely to roam:
perhaps ten full blocks! We found creatures strange!
They all spoke English! The stories exchanged
recalled those of family: Mom, Dad, and friends --
it's true, then, we _are_ all the same in the end!
Such relief not to grapple
with projects baroque,
languages strange, or
features "they" wrote.
In tune with this sentiment
let's celebrate dominance!
Hush the less pertinent --
let's not mention "those" continents.
"Hurray," we all cheer: "Our wiki is strong!"
Our projects are weak, but shush, sing along:
our rivals are fierce, but yet we prevailed;
it must be because our PHP scaled!
Ignore those naysayers who laugh at our UX
And claims by our editors that it obstructs:
separate pages for talk, no friends and no chat --
no Serious Software has all of that!
Well, enough -- we're not free
to change even fonts
without acres of missives
to agony aunts:
let's move next to strategy,
where with speeches prolonged
new hires will tell us
what we got wrong.
Three commands we were given:
the first, to be punctual.
By fiat we've banished
the correct but eventual;
from now on our code
is timely _and_ functional.
Our prior disasters are
vanished by ritual.
The second was novel:
exhorted to innovate!
Our change-fearing userbase
I'm sure will reciprocate.
Perhaps we can grow
new crops of good editors.
New users, new processes,
throw off our fetters.
Perhaps we need spaces
where we can be bold --
it's hard else to see
how to do what we're told.
The last was to integrate,
engage with community;
never mind our tall silos
and product disunity:
we can have orphaned features
conflicted teams, clashing visions --
"What's key is to synergize!"
says our stratcom tactician.
Community discourse
will fix all that ails us:
except for those times
when instead they've assailed us.
Lift a glass to the mission!
We'll muddle through fine.
We all love each other,
but this day's been a grind.
I was really happy to hear Damon, at the MediaWiki Developer Summit,
ask us how long we take to code review and whether we had communicated
a timeframe in which we promised to do it to our community. He quite
rightly stressed that this was vital for the survival of our
community. I spoke to one of our more new developers during the summit
and he also confessed to me that the reason he was an active volunteer
in our extension was that he got feedback on his code pretty quickly.
I had a few ideas about how to measure this so in my spare time I have
generated this report based on data from Gerrit patchsets using a
hacked together python script [1] which I hope will be if nothing else
an interesting artifact to talk about and generate some discussion.
Introducing:
https://www.mediawiki.org/wiki/Extension_health
To help you understand what you are reading, let's take Echo as an example:
Project: mediawiki/extensions/Echo
524 patches analysed (23 open, 501 merged)
Average review time: 29 days
Oldest open patch: (bug 41987) Updating tables indexes' names. (766
days) - https://gerrit.wikimedia.org/r/40095
The average time for code to go from submitted to merged appears to be
29 days over a dataset of 524 patches, excluding all that were written
by the L10n bot. There is a patchset there that has been _open_ for
766 days - if you look at it it was uploaded on Dec 23, 2012 12:23 PM
is -1ed by me and needs a rebase.
There are many patches like this outside Echo. We should probably be
seeing those patchsets through to completion or abandoning them on the
basis that if it hasn't been merged in over 2 years it's probably not
important and shouldn't be clogging up people's review queues and
hiding other more important patchsets which need review.
The more troubling situation is when patches have been open for some
time and have not been reviewed at all or are awaiting for some
response... let's get better at this!
Help make this ecosystem better. I will rerun the script in a month
and see if we have improved. Note our average time to review across
all those projects seems to be 18 days. That's really not good. We can
do better. We will do better.
[1] https://github.com/jdlrobson/GerritCommandLine
Just a quick note that I really appreciated everyone's help making the
summit come together. As always, we'll be doing lots of second-guessing of
everything we did and didn't do, and how we want to use future time
together. Before we go into that, I'd like to thank the event team and
_everyone_ who worked to and beyond the point of exhaustion to organize the
event, support attendees, plan sessions, facilitate conversations,
negotiate sometimes difficult terrain.
Thank you. :)
Erik
--
Erik Möller
VP of Product & Strategy, Wikimedia Foundation
What is the process to add people as owners of an extension?
What is described on mw.org [0] does not work. Contrary to what is
written there I can not add group members myself to a group that I am
in. And a request I added there is open now for more than three
months.
So, what do I have to do to give other people access to extensions?
Are there any plans to streamline that process?
Stephan
http://www.mediawiki.org/wiki/Gerrit/Project_ownership#To_make_a_new_Projec…
Hello,
This bug <https://phabricator.wikimedia.org/T87645> is more serious than it
seems and it's blocked a huge part of our actions (e.g. creating pages
outside of main namespace via API)
Please someone take a look at this
--
Amir
Hi could I have some help to fix a problem that a user reported on the extension talk page. The talk page is at http://www.mediawiki.org/wiki/Extension_talk:CollapsibleVector and the title is flickering. I am not sure how to fix the problem I was wandering if someone on here knew how to fix the problem.
Minutes and slides from four recent quarterly reviews are now available:
Team Practices Group:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Engineering Commmunity Team:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Release Engineering and QA (Quality Assurance) team:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Mobile Partnerships (Wikipedia Zero) team:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
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 Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
PSR-3 logging has been fully supported in MediaWiki since1.25wmf5.
We've been making various tuning improvements since then including a
recent deprecation of the initial MWLogger wrapper class in favor of
direct usage of Psr\Log\LoggerInterface by wfDebugLog() and other
internal wrapper methods [2].
The next big step in introducing structured logging to MediaWiki is to
begin to replace calls to wfDebugLog() (and dear god wfDebug()) with
direct usage of Psr\Log\LoggerInterface instances. Kunal and I have a
couple starter patches that show this in gerrit [3]. In both
conversions we have chosen to implement Psr\Log\LoggerAwareInterface
in the effected classes to allow setter based injection of a
LoggerInterface. The log channel names were also chosen to match the
previous wfDebugLog logGroup values. When you use a PSR-3 logger you
need to choose a severity for each log message. PSR-3 has quite a few
possible levels, but I'd like to propose that we really only need 4 to
start with in MediaWiki:
* debug: Useful for ummm.... debugging. :) These are messages that are
useful for local development and are generally too "spammy" to output
on a production wiki. This would typically include anything currently
being logged via wfDebug.
* info: Valuable state change information. This level is a great place
to record information that would be useful in a production environment
when tracing the path of a request that eventually had an error.
* warning: A soft error condition such as a recoverable error or
another condition that typically should not be seen but isn't halting
for the operation in process
* error: A hard error such as a caught exception with no recovery path.
The notice, critical, alert and emergency log levels seem unnecessary
to me, but I'm willing to hear arguments about where they are super
duper useful for some log event state that I haven't thought of yet.
When thinking about Wikimedia cluster logging, events emitted at
warning and error levels should be things that you want deployers and
operations staff to see in the Logstash "fatalmonitor" view and
recorded to other durable logging stores. Events at info level may or
may not be captured similar to how we currently enable some but not
all wfDebugLog channels. Events at debug level will probably only be
captured in beta labs and similar low volume debugging environments.
The wfDebug* methods are not being deprecated officially yet but it
would be great if people started treating them like they were
deprecated when writing new classes. It would be even more awesome if
more folks started making small cleanup patches to convert existing
classes to the new style of logging. Tagging gerrit reviews for these
patches with "PSR-3" as either a submitter or a reviewer would also be
appreciated.
[0]: https://gerrit.wikimedia.org/r/#/c/119940/
[1]: https://gerrit.wikimedia.org/r/#/c/185210/
[2]: https://gerrit.wikimedia.org/r/#/c/184830/
[3]: https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:master+top…
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
(Sorry, this was meant for wikitech-l.)
On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh <ori(a)wikimedia.org> wrote:
> We should do the same, IMO.
> http://bowery.io/posts/Nodejs-to-Golang-Bowery/
>