Minutes and slides from last week's quarterly review meeting of the
MediaWiki Release Management team are now available at
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 Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
Minutes and slides from the recent quarterly review meeting of the
Foundation's Parsoid, Services and OCG (Offline content generator)
teams have appeared at
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 Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
On Tue, Oct 21, 2014 at 4:34 AM, Gergo Tisza <gtisza(a)wikimedia.org> wrote:
> On Sun, Oct 19, 2014 at 5:44 PM, Brian Wolff <bawolff(a)gmail.com> wrote:
>
> > Well there are a lot of links to it first of all.
> >
>
> For which a redirect is a much better solution than sending the reader to a
> dead site and leaving them to figure out it's dead. At least for direct bug
> references it should be easy to set up a rewrite rule forwarding them to a
> Phabricator search on the bugzilla ticket number.
>
This is what will happen: https://phabricator.wikimedia.org/T40
The main reason for keeping Bugzilla up as long as possible would be, IMO,
> the personal details which won't be migrated but help people keep track of
> their bugs of interest, often across many years - votes, saved searches,
> personal whiteboards and such.
We have committed to keep Bugzilla in read-only mode after the Phabricator
launch, and we haven't decided on any date to decommission it. We don't
need to rush to decide that date. Bugzilla will be there until the day that
it doesn't make sense to keep it. Tracked in
https://phabricator.wikimedia.org/T366
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Assume we have the following call of a template:
{{template
|key1=value1
|key2=value2
|key1=value3
}}
What is the expected value of {{{key1}}} when parsing the template?
>From the docs I've read, I would expect it to be value3. If so, does
value1 appear anywhere?
Thanks,
Strainu
-------- Messaggio originale --------
Oggetto: Re: [Wikisource-l] Standardize ProofreadPage namespaces, again
Data: Mon, 20 Oct 2014 22:15:42 +1100
Mittente: Wiki Billinghurst <billinghurstwiki(a)gmail.com>
Rispondi-a: discussion list for Wikisource, the free library
<wikisource-l(a)lists.wikimedia.org>
A: discussion list for Wikisource, the free library
<wikisource-l(a)lists.wikimedia.org>
Fully agree with Thomas's points.
Find the right person within WMF to whom we need to talk. Get the
defaults determined by them, and plugged into their configs. Then
work with them to move sites to the config, fix up filters, etc. Bite
size.
I would suggest that on this matter we would be best to approach
someone like Rob Lanphier to get someone as a contact.
Regards, Billinghurst
On Mon, Oct 20, 2014 at 6:44 PM, Thomas Tanon <thomaspt(a)hotmail.fr> wrote:
> Yes, it's a small detail for Wikisourcerors but not for tech people because it requires to update a lot of rows in the database. So, I think that the concertation should be done more with system administrators than with Wikisourcerors.
>
> As 250/252 are the default ids for Page/Index namespaces and are dedicated to ProofreadPage they should be used.
>
> About the other namespaces, they are not managed specifically by an extension so the context is not exactly the same. I believe that this point should be raised only after the changes for Page/Index are done.
>
> Thomas
>
>> Le 20 oct. 2014 à 09:07, Nicolas VIGNERON <vigneron.nicolas(a)gmail.com> a écrit :
>>
>>
>> 2014-10-20 2:51 GMT+02:00 Ricordisamoa <ricordisamoa(a)openmailbox.org>:
>> About this RFC, John Vandenberg agreed to use the 250 / 252 pair for Page and Index namespaces, respectively.
>> Is it wise to just go ahead and request changing one site at a time? What are your wikis' general opinions about this?
>>
>> Not sure but I think that this change is important for technichal people and in the same time, it's probably a small detail for the wikisorcerors. Isn't it ? If it is, we should go ahead.
>>
>> What about the other namespaces ? (like I asked in March)
>>
>> Cdlt, ~nicolas
>> _______________________________________________
>> Wikisource-l mailing list
>> Wikisource-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
>
>
> _______________________________________________
> Wikisource-l mailing list
> Wikisource-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
_______________________________________________
Wikisource-l mailing list
Wikisource-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l
Hi.
Splitting off from the Phabricator for code review thread, I'm trying to
figure out if Phabricator could be a code viewer (and perhaps a code
mirror for cloning...) and whether that would be a good idea as an
intermediate step toward using Phabricator for code review. I'm thinking
about either a Phabricator application similar to ViewVC or GitBlit. Or
the more advanced option would be closer to how we currently treat GitHub.
In other words, looking at <http://phabricator.org/applications/>, are
there gradations of Phabricator code integration between nothing and
installing Differential?
Apologies if this has been discussed elsewhere and I've just missed it.
MZMcBride
If you need a new project in https://phabricator.wikimedia.org, now you can
request it.
Please follow the instructions at
https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project
Read the guidelines! If this is your first Phabricator project, they will
probably teach you something relevant you didn't know.
BIG DISCLAIMER
Currently the creation of new projects is restricted to teams migrating
from Trello and Mingle, as well as initiatives without any presence in
Bugzilla. Members of these new projects must be aware that Wikimedia
Phabricator will be inaccessible during several days in the following
weeks, due to the RT and Bugzilla migrations. They also need to understand
that the Phabricator maintainers have limited capacity to support them
while they are focusing on the Phabricator launch.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi list,
tl;dr: If you use a fixed length buffer to store edit tokens, you'll
need to update your code.
I'm planning to +2 https://gerrit.wikimedia.org/r/#/c/156336/ in the
next day or so. That provides for two hardening measures:
* Tokens can be time limited. By default they won't be, but this puts
the plumbing in place if it makes sense to do that on any token checks
in the future.
* The tokens returned in a request will change on each request. Any
version of the token will be good for as long as the time limit is
valid (which again, will default to infinite), but this protects
against ssl-compression attacks (like BREACH) where plaintext in a
request can be brute-forced by making many requests and watching the
size of the response.
To do this, the size of the token (which has been a fixed 32 bytes +
token suffix for a very long time) will change to add up to 16 bytes
of timestamp (although in practice, it will stay 8 bytes for the next
several years) to the end of the token.
If that's a problem for anyone, please add a review in gerrit, or
respond here. Otherwise 1.25wmf5 will have the change included.