[Wikitech-l] 2016W43 ArchCom-RFC meeting: Allow HTML in SVG?

[Rob Lanphier]

Hi everyone,

For [this week's ArchCom-RFC meeting][E325], let's talk about SVG.

As you probably know, MediaWiki optionally allows for SVG uploads,
which is allowed on many Wikimedia wikis (e.g. on Commons).  However,
in order to make this preference safe to use, we need to validate the
SVG.

One thing that's allowed in the SVG spec is to embed fragments of
XHTML inside the SVG.  This isn't just a obscure spec feature; this is
understood to be the best way to embed a caption for a diagram that
allows for word wrap when the image is scaled.  Having XHTML support
also would allow for greater compatibility between MediaWiki and
real-world SVG editing tools (e.g. like draw.io)

matmarex made a suggestion in [the bug for this][T138783]:
> We have a HTML validation library (the Sanitizer class) and it could
> probably be hooked up to validating HTML in SVG file uploads. But it
> would definitely require some work.

It's not officially an RFC, but I suggested it as a discussion topic
in [last week's ArchCom planning meeting][3], and no one objected.

Let's see if we can answer a couple of questions:
1.  Is this a good idea in theory?  i.e. is it possible/likely that an
experienced developer could implement something that can pass security
review, or is it conceptually flawed?
2.  Is matmarex's suggested approach a good one?
3.  Should we turn our SVG validation code into a proper library?
4.  (if there's time) Let's step through the [brion's June 30 comment][4]

This week it will be the usual time (Wednesday 21 UTC, 14 PDT, 23 CEST)
and place (#wikimedia-office).  Next week, things get complicated
because of the end of [Summer Time in Europe][5]; an announcement
about next week's meeting will hopefully find its way to the
[ArchComStatus page][6].

Rob

[E325]: 
[T138783]: 
[3]: 
[4]: 
[5]: 
[6]: 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W42 ArchCom-RFC meeting: Surveying Cookie/Local Storage Use

[Rob Lanphier]

Hi all,

At this week's ArchCom Office hour, we'd like to help the WMF Legal
team ensure our software development practices don't accidentally
cause us to enable all sorts of creepy surveillance because a naive
developer adds it.  The challenge, of course, is when the royal "we"
accidentally add something, and then we deploy it (because that's a
pretty routine thing these days).  Sometimes, no amount of begging "NO
WAIT, WE DIDN'T *MEAN* TO DO THAT" (no matter how sincere) can undo
the damage done.  Wikimedia seems to have a pretty good reputation in
the grand scheme of things, but maintaining that reputation is going
to take a lot of vigilance.

Zhou Zhou filed an RFC about this:



...which seems like a good topic for our Wednesday meeting[1].  Zhou
is hoping to figure out how to build the alerts necessary to
understand when some new form of tracking is created.  I'm guessing
there's lots of automated and semi-automated monitoring that we could
create to make keeping track of new cookie uses easier; let's talk
about what's realistic, what WMF needs to invest in directly,  and how
our wider community of developers can chip in.

Our meeting is at its usual time (Wednesday 21 UTC, 14 PDT, 23 CEST)
and place (#wikimedia-office).

Rob

p.s.  Obligatory reminder about ArchComStatus page[2]

[1]: 
[2]: 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W41 ArchCom-RFC meeting: CREDITS

[Rob Lanphier]

Hi everyone,

This week's ArchCom Office Hour[1] is going to be about a
long-neglected item: giving credit where credit's due in the CREDITS
file (Jon Robson's T139300 proposal[2]).  Jon and I spoke about it
earlier today; he's not sure he can be there, and this is a meeting
where I would have hoped to have done more prep, but I'm hoping we can
at least come to a better collective understanding for the people at
the meeting.

The reason why this isn't as easy as it looks on the surface is
because the COPYING file notes: "MediaWiki contributors, including
those listed in the CREDITS file, hold the copyright to this work."

The fact that I hadn't gotten around to consulting our Legal
department made me very, very tempted to call off the meeting this
week.  But I think maybe instead it'll be the "what does the
wikitech-l community want RobLa to go ask Legal about" meeting.  :-)
Let's figure out what our viable options are.

I took the liberty of taking the prose in T139300, and adapting it to
wiki page[3].  We can conceivably use this as a space to figure out
what we want the policy page to say.

Our meeting is the same time as always (Wednesday 21 UTC, 14 PDT, 23
CEST) and place (#wikimedia-office).

Rob

p.s.  Obligatory reminder about ArchComStatus page[4]

[1]: 
[2]: 
[3]: 
[4]: 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Timing of ArchCom meetings

[Rob Lanphier]

Hi folks,

The thing that's been great about having ArchCom meetings at the same
time and place has been that we've been able to make a habit out of
having them.  Because we're a global movement, there's never a good
time for anyone, but the time we typically schedule for these was the
best compromise we found for the ArchCom members.

The time of the meeting: Wednesday 2pm Pacific Time, which translates to:
*  23 CET/CEST most weeks
*  21 UTC during U.S. daylight savings time (northern hemisphere spring/summer)
*  22 UTC during U.S. standard time (the northern hemisphere fall/winter)
*  Possible confusion for people outside the U.S. when the time doesn't align

The time seems to work well enough for ArchCom (the last time I
asked).  However, just because the time works for ArchCom members,
doesn't mean it works for everyone in the world (and these are public
meetings open to everyone).  There have been suggestions that we
rotate the timing of these.  The challenge of that is that rotating
meetings are a lot harder to make a habit out of.

My preference would be that we add additional times, keeping the
current Wednesday time as the "main" meeting, but that we have adjunct
meetings at different times with different target attendees.  The

I'd be willing to facilitate multiple times (including times that suck
for me personally), but another aspect that I'm hoping for is that the
shepherds assigned to the ArchCom-RFC facilitates whatever meetings
necessary to move things along.

Thoughts?
Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Rob Lanphier]

Hi Legoktm,

Quim explained why this discussion is probably a moot point (for this
year's summit) at <https://phabricator.wikimedia.org/T146377>.  He's
the chair of Program committee, and he's calling the shots on our
tooling choice.  He's said "it is too late to start a discussion about
Phabricator vs MediaWiki to handle the call for participation. "

That said, I'll provide a more detailed reply, because someone is
wrong on the Internet!  ;-)  More inline

On Wed, Sep 28, 2016 at 2:27 AM, Legoktm <legoktm.wikipe...@gmail.com> wrote:
> On 09/27/2016 09:55 PM, Rob Lanphier wrote:
>> It's really unfortunate that you consider use of Phabricator to be
>> demoralizing, though.  I don't want to push something that seems
>> demoralizing to a great contributor like yourself.  More on this in a
>> bit
>>
>> It may be a little naive to hope it will
>> somehow make our software better at doing the thing it was designed to
>> do when we try to force it to do something it wasn't designed to do.
>
> In what way do you think that MediaWiki is not designed to promote and
> foster online collaboration?

That is a loaded question.

I believe that Phab is better than MediaWiki at:
1.  Doling out short unique identifiers of tasks, events, etc
2.  Maintaining state metadata about tasks (e.g. bug reports, RFCs, etc)

>> So, that's my rebuttal to the suggestion that we need "more
>> dogfooding"  I think we do need to get better at using our software.
>> Certainly, MediaWiki is hard to beat at collaborating on prose,
>> providing great attribution functionality about article changes.  I've
>> frequently called for ArchCom-RFC authors to move the bulk of the
>> prose of their RFCs onto mediawiki.org.  However, Phabricator is
>> really good tool for a couple of things:
>> 1.  Doling out short unique identifiers of tasks, events, etc
>
> Every page in MediaWiki is assigned a unique page_id. You can visit an
> article by it's page id with the = parameter to index.php.

That is technically correct, which, as we know, is the best kind of
correct!  ;-)

> But, I
> don't see how this is relevant to summit proposals. I think a URL like
> <https://www.mediawiki.org/wiki/WMDS17/Shadow_namespaces> is way more
> useful and readable than <https://phabricator.wikimedia.org/T115762>.
> Wouldn't you agree?

Readable: yes.  Useful: depends on what your use is:
*  Readability: yes
*  Using as a canonical identifier: no
*  Verbally giving someone the exact, unambiguous identifier for a proposal: no
*  Expanding a short ID into a long topic name: no

The thing that I found *really* useful last year was being able to
really quickly make a schedule.  I could drop text like this in a
comment:
| Monday | Room 1 | Room 2 | Room 3 |
| 10am | {T21}  |  {T22}  | {T23} |
| 2pm | {T24} | {T25}| {T26} |

| Tuesday | Room 1 | Room 2 | Room 3 |
| 10am | {T27}  |  {T28}  | {T29} |
| 2pm | {T200010} | {T200011} | {T200012} |

...and have it render as two 4x3 tables, with all of the task numbers
in curly brackets replaced with the full title of the task.  I could
cut and paste the comment text around, and drop it into plain text
emails (like this one) and have people get the basic semantics of what
I was referring to.

>> 2.  Maintaining state metadata about tasks (e.g. bug reports, RFCs, etc)
>
> Agreed. That said, MediaWiki categories can be pretty powerful, and then
> you can combine them with templates or things like DPL. We already have
> such a system set up for RfCs on mediawiki.org, I think making a similar
> template and set of categories for summit proposals would be easy.

That seems like a lot of work where the time and effort is better
spent elsewhere.

>> So, what about our use of Phab for this makes you glum? Is there a
>> way we can convince you that it's not so bad?
>
> For the purposes of drafting a document, asking other people to review
> and contribute to it, and then discussing it, Phabricator seems like a
> bad fit. Instead of being able to use an awesome VisualEditor, I'm
> forced to use remarkup. Instead of being able to use convenient
> templates like {[wg}} or {{ll}}, I'm forced to use clunky external
> links. Instead of automatically getting a CodeEditor when writing up
> some mock PHP/JS, I have to open a plain text editor on my laptop for
> proper tabs and brace completion and copy/paste it back in my browser

A, now we're getting to the real issue.  I agree, I find this
frustrating too.  Much of the scramble getting things together for
WikiDev16 (and my increased involvement in ArchCom facilitation)
really piqued my interest in markup conversion.  I would love for us
to have better interoperability with Phabricator.  However:

1.  Phabricator isn't l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Rob Lanphier]

At the risk of threadjacking about dogfooding

On Tue, Sep 27, 2016 at 2:45 PM, Legoktm  wrote:
> On 09/27/2016 03:57 AM, Quim Gil wrote:
>> * Phabricator form to submit Wikimedia developer Summit 2017 proposals
>> (urgent because it blocks the opening of the call for participation)
>> https://phabricator.wikimedia.org/T146377
>
> I have proposed the opposite on the ticket[1] - I believe we should be
> using mediawiki.org to organize the summit instead of Phabricator. I
> find it demoralizing that we cannot use our own online collaboration
> software to plan our own summit. We need more dogfooding[2], not less.
>
> [1] https://phabricator.wikimedia.org/T146377#2670042
> [2] https://en.wikipedia.org/wiki/Eating_your_own_dog_food

It's really unfortunate that you consider use of Phabricator to be
demoralizing, though.  I don't want to push something that seems
demoralizing to a great contributor like yourself.  More on this in a
bit

The "Eating your own dog food" article talks a lot about Microsoft's
use of the term, which makes sense because Microsoft was pretty proud
of their dogfooding strategy.  Dogfooding was the right strategy for
Microsoft in the early 1990s, given what they were trying to
accomplish, which world dominance of Microsoft operating systems.  It
worked well for them.  It may be a little naive to hope it will
somehow make our software better at doing the thing it was designed to
do when we try to force it to do something it wasn't designed to do.

The dogfooding article also points out many problems in the
"Criticism" section, where it cites an IEEE magazine editorial on the
subject.  Here's a quote from the cited article[2]:

> Also, dogfooding encourages the Not Invented Here syndrome. If the
> organization's philosophy is that employees must always use its own tools,
> scarce resources might get allocated to building tools that could easily
> be purchased from others, or worse yet, tools might get rejected simply
> because the company doesn't make them.

Sometimes, a non-Wikimedia system may be the best food ... er, tool
for the job.  We shouldn't compromise on WMF's guiding principles[1]
(which we hope are a reflection of movement principles), but we
shouldn't insist on using our own systems when a system developed
and/or maintained by someone else would be the best tool for the job.
Let's shoot for better interoperability with the rest of the free
software world, rather than mindless world dominance of
Wikimedia-controlled software.

So, that's my rebuttal to the suggestion that we need "more
dogfooding"  I think we do need to get better at using our software.
Certainly, MediaWiki is hard to beat at collaborating on prose,
providing great attribution functionality about article changes.  I've
frequently called for ArchCom-RFC authors to move the bulk of the
prose of their RFCs onto mediawiki.org.  However, Phabricator is
really good tool for a couple of things:
1.  Doling out short unique identifiers of tasks, events, etc
2.  Maintaining state metadata about tasks (e.g. bug reports, RFCs, etc)

...plus many other things we use Phabricator for.

So, what about our use of Phab for this makes you glum?  Is there a
way we can convince you that it's not so bad?  I'm open to being
convinced that we should stop using Phab for as much as we are, but
right now, it makes me happy that we have a tool that is rapidly
improving without Wikimedia Foundation needing to invest very much
money in it.  It makes me especially happy that Phab is free software,
and that the time and money we invest in it is making the universe of
free software better.

Rob

[1]: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles
[2]: https://www.computer.org/csdl/mags/so/2006/03/s3005.html

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Rob Lanphier]

Hi everyone,

Abstract
---
This mail doubles as an invitation to come to this week's ArchCom
office hour (Phab:E285), and provides an attempt to provide answers to
questions about the agenda of the Wikimedia Developer Summit
(WikiDev17).  I'm hoping we find a way to work with people who can't
travel, and noting we're also working to make remote participation
more rewarding.  This emphasizes the importance of WikiDev17 being a
better event for online attendance this year, and the primacy of
online conversations in our community's decision making.

Table of contents for the rest:
* ArchCom office hour E285
* Previous Dev Summits (2014-16)
* The dangers of prior RFC requirement
* Less spectators, more participants

ArchCom office hour

This week's ArchCom IRC office hour will be this coming Wednesday,


Wednesday, 2016-09-28, 21:00 UTC (2pm PDT, 23:00 CEST) on #wikimedia-office

This is a continuation of the many conversations we've had on this
mailing list (e,g, the "Wikimedia Developer Summit 2017: Registration
Open" thread last week) and elsewhere about the summit.

Previous Dev Summits (2014-16)
--
This is an admittedly biased version of history, based on my
involvement in the program committee that is still forming.  Quim is
chairing the program committee, and I'm one of the members, but my
understanding from Quim is that we're still waiting for some invitees
to respond.

Previous years, we had a more explicit emphasis on "architecture"
(e.g. even calling our 2014 event the "Architecture Summit"[1]).  The
ties between "architecture"<->MediaWiki<->wikitech-l are very strong.
Additionally, the 2014 and 2016 events had very explicit instructions
insisting on submission of MediaWiki RFCs[2].

The benefit of requiring submission of RFCs was that it caused many
people to write down "this is what I want to talk about".  There were
many conversations leading up to last year's summit that might not
have happened without such an explicit prompt.  Many of the
unconference sessions last year were discussions that were submitted
as RFCs, but were turned down for plenary session time.  Those
unconference sessions benefited from the prep work.

The dangers of prior RFC requirement
--
We don't intend to make the requirement so tough this year.  A
challenge we face is that many topics don't fit well into RFC form.
"RFC" and "conversation" are not interchangeable terms.  We hope that
all RFCs are indeed conversations, but certainly not all conversations
belong in RFCs.  Last year, the RFC requirement also meant that all of
the scheduled topics had Phab IDs associated with them.  Is there some
other short identifier we can use as a standard conversation
identifier?  Maybe Wikidata QIDs?  ;-)

The hope is that WikiDev17 enriches conversations that are well
underway *before* everyone shows up in San Francisco.  Complicated
conversations require a shared context, but humans have traditionally
had a difficult time building shared context without physically
putting everyone in the same room at the same time.  Developers
frequently want to cram "context building" into their discussion time,
spending 70 minutes out of a 90 minute conversation time bringing
attendees up-to-speed, so that we can have a "really good" 20 minute
conversation.

A big fear: we fail to connect WMF staff developers with larger
Wikimedia community developers.  Meetings bust up unconference style
into two camps: WMF staff led discussions where participation relies
on having the kind of knowledge that one needs "insider" access to
stay abreast of, and non-WMF staff led discussions where participants
try to solve problems that WMF staff doesn't seem interested in
solving.

A huge challenge: we can't *know* in September 2016 what conversations
will be important in January 2017, but based on our experience with
past Dev Summits, it's worth creating the opportunity for important
conversations to happen.  We have plenty of conversations that are
still ongoing, and plenty of conversations many of you all likely know
need to happen in January.  Let's start the conversations we know
about now, and *hope* that they're already done before the summit

Less spectators, more participants
--
One thing we know from all of our experience: y'all don't want to make
a point of coming to San Francisco to be talked at by someone.  As in
past years, we're working to bring up to 200 people together to have
great conversations about the collective hopes of the Wikimedia
development community.  It's happening the same week as the Wikimedia
Foundation All-Staff meeting, so the attendance will be heavily biased
toward WMF staff, but we hope this isn't just us talking to ourselves.
We're working hard to provide a framework for good conversations to
happen; not for 

Re: [Wikitech-l] Gerrit screen size

[Rob Lanphier]

On Sun, Sep 25, 2016 at 5:41 AM, Tim Starling 
wrote:

> On 25/09/16 21:09, Bináris wrote:
> > I try to familiarize myself with Gerrit which is not a good example for
> > user-friendly interface.
> > I noticed a letter B in the upper right corner of the screen, and I
> > suspected it could be a portion of my login name. So I looked at it in
> HTML
> > source, and it was. I pushed my mouse on it and I got another half window
> > as attached.
> >
> > So did somebody perhaps wire the size of a 25" monitor into page
> rendering?
> > My computer is a Samsung notebook.
>
> In T38471 I complained that the old version was too wide at 1163px
> (for my dashboard on a random day). Now the new version is 1520px. I'm
> not sure if the Gerrit folks are serious or are trolling us. Perhaps
> it is a tactic to encourage UI code contributions?
>

My suspicion is that the Gerrit folks (in particular, Shawn Pierce) aren't
so much trolling us as saying "stop relying on the UI of Gerrit!  That's
not the point!"  The last time I was paying close attention to this, Gerrit
upstream seems to be particularly focused on building code review features
suitable for:
1.  Incorporation into git upstream
2.  Integrated into development UIs like Eclipse

The strategy seems to be "Gerrit is a reference implementation of a code
review UI for Git".  I haven't paid close enough attention to either Gerrit
upstream or Git upstream to know if the Gerrit core contributors have made
progress in getting code review functionality added to Git core (or if
they've given up, or if I completely misunderstood their strategy).  I'm
guessing that Eclipse has pretty good Gerrit support, but I rarely play
with Eclipse, so that's just a guess based on the Eclipse Foundation's
involvement with Gerrit.

As bd808 noted, Gerrit upstream seems to be working on yet another UI,
which would make sense if their goal is to create a variety of compatible
implementations of advanced Git functionality.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Debian and Ubuntu packages for MediaWiki now available

[Rob Lanphier]

On Wed, Sep 21, 2016 at 11:44 PM, Legoktm 
wrote:

> Instructions, links, and help can all be found at
> . Please let me
> know if you have any questions or feedback.
>
> Finally, thanks to Luke Faraone, Faidon Liambotis, Moritz Mühlenhoff,
> Max Semenik, Chad Horohoe, Antoine Musso, and all of the beta testers of
> the package for making this a reality.
>

Congratulations, y'all!  This is a huge step toward making safe
installation of MediaWiki simple.  Thanks Legoktm for leading the charge!

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] WikiDev17 Collaboration topic (Re: Opening up MediaWiki dev summit in January?)

[Rob Lanphier]

Scott suggested the following as one of three suggested topic ideas
for WikiDev17.  The three ideas:
1) Collaboration
2) Wikitext Maintenance
3) Machine Translation

More inline about "1) Collaboration" below:

On Tue, Sep 20, 2016 at 10:05 AM, C. Scott Ananian
 wrote:
> *1. *(A unified vision for) *Collaboration*
>
>- Real-time collaboration (not just editing, but chatting, curation,
>patrolling)
>- WikiProject enhancements: User groups, finding people to work with,
>making these first class DB concepts
>- Civility/diversity/inclusiveness, mechanisms to handle/prevent
>harassment, vandalism, trolling while working together
>- Real-time reading -- watching edits occur in real time
>- Integration with WikiEdu
>- Broadening notion of "an edit" in DB -- multiple contributors,
>possibly multiple levels of granularity
>- Tip-toeing toward "draft"/"merge" models of editing
>- Better diff tools: refreshed non-wikitext UX, timelines, authorship
>maps, etc.

I've copied this wholesale into the "Collaboration" area on
[[WikiDev17/Topic ideas]], and quoted it directly here:


Let's use this thread to focus on this part of Scott's proposal.  A
lot of these seems in scope for the Wikimedia Collaboration team.
Does the scope that you're thinking of align with what the team has
published on their page:


Rob
(p.s. please feel free to start separate threads with the other parts
of Scott's proposal)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[Rob Lanphier]

On Tue, Sep 20, 2016 at 10:05 AM, C. Scott Ananian
 wrote:
> Here are three topic suggestions, cc'ed here in case folks aren't following
> the Flow, with an illustrative (but not exhaustive) list of sessions that
> could fit under each

Thanks for doing that breakdown!  I incorporated your suggestions into
this page:


I suspect each of the three ideas you presented here are worthy of
separate threads (and perhaps separate on-wiki conversations), so I'll
reply to at least the first part under separate cover.

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[Rob Lanphier]

On Thu, Sep 15, 2016 at 1:09 AM, Daniel Kinzler
 wrote:
> Am 15.09.2016 um 01:54 schrieb Chad:
>> Bummer. I think paying down tech debt is fun and way more rewarding
>> than making shiny new things.
>>
>> But I'm also weird as hell...
>
> /me waves to a kindred soul.

This seems apropos:
https://vimeo.com/121290570

It's good Hollywood is finally paying attention to our people.

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] No ArchCom IRC office hour planned for this week (2016W37)

[Rob Lanphier]

Hi folks,

Many of us at WMF will be at a Product and Tech meeting here in SF, so
we decided not to hold the usual IRC office hour on #wikimedia-office.

I've updated "upcoming meetings" part of the status page with some
info on *next* week's meeting:


Next week, on 2016-09-21, we plan to discuss Multi-Content Revisions.[1]

If y'all want to join a channel for an informal conversation, it seems
like #wikimedia-tech is usually a good place to find most of the
people who frequent the IRC office hour.

Rob
[1]: https://www.mediawiki.org/wiki/Multi-Content_Revisions

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Memento MediaWiki Extension at the W3C

[Rob Lanphier]

On Mon, Sep 12, 2016 at 10:57 AM, Shawn Jones  wrote:
> Considering the consensus from the RFC was to start a pilot of Memento on
> English Wikipedia, how do we start that process again?


Hi Shawn,

Thanks for your previous email, with all of the links.

Several of us investigated this in 2013, and we responded back in 2013
when we declined this in Bugzilla in 2013:


As I recall, older versions of this never fully addressed the caching
and infrastructure implications of using HTTP headers.  Am I
remembering that correctly?  Is there something different about
current versions?

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[Rob Lanphier]

On Thu, Sep 8, 2016 at 7:53 AM, Nuria Ruiz  wrote:
>
> Seems that defining what areas we want to cover in the summit is
> a prerequisite  to do what Brion was asking for in the initial e-mail, to
> open the summit beyond WMF.
>
>
Good point.  Let's say that we had to pick only one of these questions to
answer at WikiDev17.  Which would you choose?
* how do we make manipulating the information on our websites easier and
more useful? (both for humans and computers)
* how can we better distribute the information on our websites?
* how can we help our software development community be more inclusive and
productive (and attract many more people)?
* how can we improve the quality of our software, and pay down the
technical debt we've accumulated over the years?
* how can we make our websites better learning environments?
* how can we make our websites better support languages other than English
(and character sets other than Latin)?

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[Rob Lanphier]

Hi Quim,

Thanks for the response, and thanks for responding for my request to
talk about this at the upcoming IRC meeting:



I've got a lot of thoughts about your response, but I'm going to zero
in on the central thing that's confusing me (paraphrasing liberally
inline below):

On Wed, Sep 7, 2016 at 4:24 AM, Quim Gil  wrote:
> By agreeing on a few main focus areas
> beforehand and "curating" them (assuring the the right people are invited
> and the right topics are addressed), we could leave more freedom of
> self-organization to all the rest.
> [...]
> One way to get there is to have WMF Product selecting these challenges with
> feedback from the Technology department and have Community Tech selecting
> the challenges from Community Wishlist tasks, all this while keeping
> listening the discussion in wikitech-l.
> [...]
> [making the scope of invitations be "participants in wikitech-l".
> goes in the opposite direction of
> the "opening up" that we have been pushing, and that moved Brion to start
> this thread. I think we can find ways to assure that "wikitech-l people and
> concerns" are addressed, while assuring that the opening up keeps happening.

It's hard for me to read this as anything but "WMF Product selects the
topics, and then 'listens' for objections on wikitech-l".  That seems
the opposite of "opening up" to me, but rather seems to be about
disintermediating wikitech-l discussion.  Is your sense that the
correct direction for us is for someone to provide more top-down
direction instead of wikitech-l conversation?

I'm going to repeat my rationale for wanting to emphasize wikitech-l.
Wikitech-l has long been our "paper of record" for Wikimedia technical
decision making.  To the extent that causes us to ask the question
"ok, what's the goal of wikitech-l?", then I think that makes this a
success.  We only hold WikiDev once a year, but wikitech-l is active
all year long.  Let's figure out why we're using this mailing list to
write messages at each other.

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[Rob Lanphier]

On Mon, Sep 5, 2016 at 11:14 PM, Quim Gil  wrote:
> Thank you for starting this conversation, Brion!
>
> Let me share the point where Rachel Farrand (Summit organizer) and I
> (Summit budget owner) find ourselves, after some conversations.
>
> GOALS [...] The Summit and its goal have been a moving target over the
> years, as you can deduce from the many changes of names & goals. [0]

It has been, but given the high satisfaction scores last year, I think
it behooves us to come up with iterative improvements, not a radical
rethink.  It seems like last year we got closer to what we've been
struggling to achieve in previous years.

> Widening the audience was a main goal last year. This is why we renamed it
> to Wikimedia (not MediaWiki) Developer Summit, and we invited developers of
> tools, templates, bots, mobile apps, the MediaWiki Stakeholders Group, and
> also non-Wikimedia users of our APIs. It was a half-backed thought that
> received half-backed support that unsurprisingly brought half-backed
> results.

I think that's a bit unfair to what we accomplished last year.

> What if the Summit would be product driven, with architecture and the rest
> following that drive. All we are here to offer better products to our
> users. All the technical discussions make more sense when there is a clear
> product vision to be either supported or contested with reality checks.

I would like to get Wes's take on this.  Last year, I didn't get the
sense that Wes was eager to grab the reins on WikiDev16, and I'd be
surprised if he wants to do it this year.  That seems to dump too much
of the responsibility on him.

It would seem that the target *participant* for this summit would be
the future WMF Chief Technology Officer (CTO).  Assuming that we have
the CTO hired by January, it would set the bar way too high to expect
that the new CTO will be responsible for running the summit.  We
should strive to make a big theme of this summit be "onboarding WMF's
new CTO".  Obviously, the scope should be more than that, but let's
hope that WikiDev17 is a great introduction to the wikitech-l
community for our new CTO

> We have a Wikimedia Foundation Product department and also a Community
> Wishlist where the communities push for product improvements.

The Community Wishlist seems like a great item to highlight (again) this year.

> We could set
> the goal of selecting (top down) a small number of product challenges and
> invite whoever needs to be involved to push them forward. Then we can leave
> plenty of free space for other topics that participants want to push
> (bottom up).
> [...]
> AUDIENCE [...]  Product
> managers, UX designers, researchers, [add other roles here], and maybe even
> selected users/editors must be invited too in order to push the selected
> product improvements forward.
>
> But there is a problem: we have a capacity limit of 200 people. The
> Foundation alone could basically fill the event if we don't set limits, The
> Summit is immediately followed by the Wikimedia Foundation AllHands annual
> meeting. The Summit is actually the successor of Tech Days, an AllHands for
> all people who worked in tech at the Foundation.

That's obviously the primary challenge we're faced with.  Given that
we can't invite all 5 billion or so stakeholders, we're going to have
to figure out how to narrow the scope of invitations, and accomplish
great things with a smaller audience.

My proposal: let's make the scope of invitations be "participants in
wikitech-l".  Wikitech-l has long been our "paper of record" for
Wikimedia technical decision making.  To the extent that causes us to
ask the question "ok, what's the goal of wikitech-l?", then I think
that makes this a success.  We only hold WikiDev once a year, but
wikitech-l is active all year long.  Let's figure out why we're using
this mailing list to write messages at each other.


> Basically, we would need to make some tough calls to define main goals and
> main audiences for the Summit in 2017. Successful events (just like
> successful products) are often the result of tough calls, so no surprise
> here.

Yes.  I'm looking to our Engineering Community Manager to create a
great Engineering meeting.


> PS1: someone asked about lessons learned -->
> https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Lessons_Learned
>
> PS2: Rob suggested that a single email thread is not the best channel to
> solve this complex discussion and I agree with him... but I didn't want to
> kill this interesting thread either. Please note that the canonical places
> for Summit discussion are
> https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit_2017 and the
> related Phabricator project task
> https://phabricator.wikimedia.org/project/board/2192/
>
> [0] https://www.mediawiki.org/wiki/Wikimedia_Developer_
> Summit_2017#Previous_summits

My comments at Talk:Wikimedia_Developer_Summit_2017 don't have any
responses as of this writing.  Clearly, I said 

[Wikitech-l] 2016W36 ArchCom-RFC meeting: shadow namespaces?

[Rob Lanphier]

Hi all,

What do y'all think of using this week's ArchCom review to talk about
T91162: Shadow Namespaces[1]?  That's what I just put into the status
page[2], and up in the Phab event for this week[3].

This would be at the usual time (Wednesday 21 UTC, 14 PDT, 23 CEST) and
place (#wikimedia-office).

If this won't work for Legoktm especially, we'll plan on having an RFC
triage meeting instead, since we haven't had one of those in a while.

Rob

[1]: 
[2]: 
[3]: 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Dev Summit ideas from 2013

[Rob Lanphier]

Hi everyone,

In 2013, WMF was still holding it's traditional All-Hands meetings in
September.  In the days before the All-Hands, we had "Tech Days",
which was two days exclusive to WMF Engineering.

ArchCom was new back then.  That was where we were starting to plan
the first Architecture Summit in January 2014.

I can't remember if I sent the email below to this mailing list or if
I merely squirreled it away on mediawiki.org in February.
Nonetheless, it's worth rereading now, since we're just about at the
same point (chronologically) in the planning process for WikiDev17 as
we were in planning for Architecture Summit 2014.

I've posted links to everything I'm talking about above here:
<https://mediawiki.org/wiki/Talk:WikiDev17>

...and that place may be a better place to reply than here on list.

Rob
(p.s. thank you whoever fixed the Talk:WikiDev17 link)

-- Forwarded message ------
From: Rob Lanphier <ro...@wikimedia.org>
Date: Fri, Sep 6, 2013 at 5:01 PM
Subject: Architecture discussion next week
To: Development and Operations Engineers <engineer...@lists.wikimedia.org>


Hi everyone,


I’d like to bring you up to speed on what we’re thinking about for the
Architecture discussion at the tech days next week.  I have a long
background written up below, but I’d like to lead with the agenda.

The overall session is 90 minutes, and a lot of ground to cover:
*  15 minutes - Background: Basic explanation and clarifying
discussion of the process
*  15 minutes - Role of our architects, senior developers, WMF in the process
*  15 minutes - Running through a couple example RFCs (no decisions,
but highlighting the discussion; see below if you want to volunteer)
*  15 minutes - Brainstorming on RFCs that don’t exist yet, but should
*  10 minutes - How do we move things faster (e.g. open invite weekly meetings?)
*  10 minutes - Architecture summit in January
*  10 minutes - Summarize next steps; assign action items

Below is the way-too-long explanation about all of this.  I’ve broken
this up into sections which mostly mirror the agenda above.


Background
-
The way big architecture decisions get discussed and eventually
implemented for MediaWiki is highly dependent on context.  Much of the
work is very driven by big features; for example, we made changes to
the way the job queue works in service of Echo (with many benefits to
other aspects of the system, such as how we handle video transcoding).
 Other work is driven by community development; for example, IAlex’s
work on the context object[1].  There’s still other work that people
would like to embark on, but may not see a clear path forward, so they
work around problems rather than address them.  In all of these cases,
developers are often unclear about what they “should” do, so they
muddle through going with what worked for them in the past.

At the Amsterdam Hackathon, we started the process documenting our
architectural guidelines[2][3].  A goal of this documentation is to
have some written guidelines to compare design proposals against,
rather than basing our decisions on the design aesthetics of whichever
reviewer happens to be looking at a big change in Gerrit.  It has
served as a means of having discussions some seemingly intractable
disagreements and has defined a way forward for experiments in more
controversial areas.  For example, the idea that we should break up
objects into value objects and logic objects is something we’re still
divided on, if our discussion in Hong Kong is any guide[5].  However,
rather than continuing this argument in the abstract, we agreed that a
specific example will be helpful, so Daniel Kinzler is working on an
example based on the Title object.

Our defined process for making big changes to MediaWiki is the RFC[4].
 We’ve had this process for a number of years, but until recently, we
didn’t have a concrete commitment to move anything forward.  Even now,
the process is still a bit fuzzy, but things are moving forward.  Tim
Starling did a very preliminary assessment of all of the RFCs in the
queue, and some have moved forward.

We’re now at the point where we need to have a conversation about how
to make this really work for us, both as WMF Engineering and as a
larger development community.  We seem to have general agreement that
MediaWiki could use more coherence in its design, but we’re still
quite far from agreement on exactly what we should aspire to.


Role of our architects, senior developers, WMF in the process
-

We’ve gotten big enough as an organization that having just one or two
people (e.g. Tim and Brion) make all of the major decisions about
MediaWiki architecture just doesn’t scale, at least not the way we’re
doing it today.  But, as noted above, it’s also important that we
strive for some level of coherence in how we do things, and a very
common strategy is to centralize the decision-making in a single BDFL
(e.g

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[Rob Lanphier]

On Thu, Sep 1, 2016 at 1:33 PM, Rob Lanphier <ro...@wikimedia.org> wrote:
> I copied your message here:
> <https://www.mediawiki.org/wiki/Talk:WikiDev17>

Ooops, I meant here:
<https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit_2017>

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Opening up MediaWiki dev summit in January?

[Rob Lanphier]

On Thu, Sep 1, 2016 at 10:12 AM, Brion Vibber  wrote:
> I think we should change this.

I think so too!  I have a lot more to say, but I'm thinking that the
best place to say it will be on wiki rather than on mailing list.  So,
I copied your message here:


I'd like to give you a better response later when I have more food in me  ;-)

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2016W35 ArchCom-RFC meeting: Revisiting image/oldimage (T589)

[Rob Lanphier]

My apologies.  I made a confusing thinko in the announcement about the
ArchCom office hour in 2.5 hours.  I wrote:
"schema change for page content language" (last week's RFC discussion)

...when I meant:
"image and oldimage tables" (what we'd like to revisit this week)

Corrected version below (highlighted with "***")

Rob

On Wed, Aug 31, 2016 at 12:20 AM, Rob Lanphier <ro...@wikimedia.org> wrote:
> Hi everyone,
>
> For this week's office hour, we'd like to discuss [T589: ***RfC: image and 
> oldimage tables***][1]  Timo brought this up on the list a
> couple of weeks ago, and didn't get much of a response. (But thank you
> Jaime for responding!)  We discussed this one fairly recently ([July
> 13][2]).  This area of our system is still in need of simplification
> and optimization.
>
> The discussion is scheduled for 2016-08-31 UTC:
> Time: Wednesday 21 UTC (2pm PDT, 23 CEST)
> Place: #wikimedia-office
> Phab event: [E266][3]
> [ArchCom/Status][4]
>
> Rob
>
> [1]: <https://phabricator.wikimedia.org/T589>
> [3]: <https://phabricator.wikimedia.org/E228> July 13 meeting
> [3]: <https://phabricator.wikimedia.org/E266> Upcoming meeting
> [4]: <https://www.mediawiki.org/wiki/Architecture_committee/Status>
> -- Forwarded message --
> From: Krinkle <krinklem...@gmail.com>
> Date: Wed, Aug 10, 2016 at 1:54 PM
> Subject: [Wikitech-l] Schema migration for 'image' and 'oldimage' tables
> To: Wikimedia developers <wikitech-l@lists.wikimedia.org>
>
>
> TL;DR: Participate on T589 and help decide what the upcoming schema change
> should entail, and how we'll migrate existing data.
>
> Hey all,
>
> Couple weeks ago we dedicated an IRC office hour to
> https://phabricator.wikimedia.org/T589 (RFC: image and oldimage tables).
>
> Updated draft at:
> https://www.mediawiki.org/wiki/Requests_for_comment/image_and_oldimage_tables
>
> We clarified scope and purpose of this particular RFC. Other issues are
> still important but considered orthogonal, and to be dealt with parallelly
> (or at a later time).
>
> Revised problem statement:
>
> 1. File revisions should have unique identifiers (better than "current file
> title + upload timestamp". (Subject to race conditions, hard to
> index/query, etc.)
> 2. Uploading new file revisions must not involve rows moving across tables,
> or rows being replaced.
>
> Participants agreed with the revised problem statement, it makes sense not
> to merely add primary keys to the existing tables ("Proposal 1" on the RFC
> draft), as that wouldn't adequately solve the Problem 2.
>
> The second proposal was to separate information about image revision from
> the image entity itself. Similar to the page/revisions tables. This was
> generally accepted as a good idea, but details are still to be determined.
>
> The general idea is that all revision-specific information (except for a
> pointer to the current revision) would no longer live in the 'image' table.
> Instead, information about all (for both current and past revisions) would
> live in the same table (instead of being moved around from one table to
> another when it's no longer the current one).
>
> Details at:
> https://www.mediawiki.org/wiki/Requests_for_comment/image_and_oldimage_tables#2._Separate_entity_and_versioning
>
> Some open questions I'd like to see discussed on Phabricator (or here on
> wikitech):
>
> 1. Which fields do we keep in the 'image' table (img_id, img_name,
> img_latest, anything else?).
>
> All fields currently being queried from both tables, will probably only
> stay in the image revision table. But there are a few fields that we
> intentionally only want to query about current versions. For example
> 'img_sha1'. For duplicate-detection, we need to only consider the latest
> revisions. Doing this by keeping img_sha1 means uploading a new revision
> will involve updating two fields instead of one (img_latest and img_sha1).
> This isn't unprecedented as we do this for page as well
> (WikiPage::updateRevisionOn; page_latest, page_touched, page_is_redirect,
> page_len).
>
> Are there other fields we need to keep besides img_sha1? Or should we can
> solve the img_sha1 use case in a different manner?
>
> 2. img_metadata
>
> This field is a blob of serialised PHP (typically representing the Exif
> data of an image).
>
> Tim (correct me if I got it wrong) mentioned we could potentially make
> migration easier by changing img_metadata to be stored in a separate table
> and change the img_metadata field (in the image revision table) to instead
> be a pointer to a primary key.
>
> This could potentially be done separately later, but

[Wikitech-l] 2016W35 ArchCom-RFC meeting: Revisiting image/oldimage (T589)

[Rob Lanphier]

Hi everyone,

For this week's office hour, we'd like to discuss [T589: schema change
for page content language][1]  Timo brought this up on the list a
couple of weeks ago, and didn't get much of a response. (But thank you
Jaime for responding!)  We discussed this one fairly recently ([July
13][2]).  This area of our system is still in need of simplification
and optimization.

The discussion is scheduled for 2016-08-31 UTC:
Time: Wednesday 21 UTC (2pm PDT, 23 CEST)
Place: #wikimedia-office
Phab event: [E266][3]
[ArchCom/Status][4]

Rob

[1]: 
[3]:  July 13 meeting
[3]:  Upcoming meeting
[4]: 
-- Forwarded message --
From: Krinkle 
Date: Wed, Aug 10, 2016 at 1:54 PM
Subject: [Wikitech-l] Schema migration for 'image' and 'oldimage' tables
To: Wikimedia developers 


TL;DR: Participate on T589 and help decide what the upcoming schema change
should entail, and how we'll migrate existing data.

Hey all,

Couple weeks ago we dedicated an IRC office hour to
https://phabricator.wikimedia.org/T589 (RFC: image and oldimage tables).

Updated draft at:
https://www.mediawiki.org/wiki/Requests_for_comment/image_and_oldimage_tables

We clarified scope and purpose of this particular RFC. Other issues are
still important but considered orthogonal, and to be dealt with parallelly
(or at a later time).

Revised problem statement:

1. File revisions should have unique identifiers (better than "current file
title + upload timestamp". (Subject to race conditions, hard to
index/query, etc.)
2. Uploading new file revisions must not involve rows moving across tables,
or rows being replaced.

Participants agreed with the revised problem statement, it makes sense not
to merely add primary keys to the existing tables ("Proposal 1" on the RFC
draft), as that wouldn't adequately solve the Problem 2.

The second proposal was to separate information about image revision from
the image entity itself. Similar to the page/revisions tables. This was
generally accepted as a good idea, but details are still to be determined.

The general idea is that all revision-specific information (except for a
pointer to the current revision) would no longer live in the 'image' table.
Instead, information about all (for both current and past revisions) would
live in the same table (instead of being moved around from one table to
another when it's no longer the current one).

Details at:
https://www.mediawiki.org/wiki/Requests_for_comment/image_and_oldimage_tables#2._Separate_entity_and_versioning

Some open questions I'd like to see discussed on Phabricator (or here on
wikitech):

1. Which fields do we keep in the 'image' table (img_id, img_name,
img_latest, anything else?).

All fields currently being queried from both tables, will probably only
stay in the image revision table. But there are a few fields that we
intentionally only want to query about current versions. For example
'img_sha1'. For duplicate-detection, we need to only consider the latest
revisions. Doing this by keeping img_sha1 means uploading a new revision
will involve updating two fields instead of one (img_latest and img_sha1).
This isn't unprecedented as we do this for page as well
(WikiPage::updateRevisionOn; page_latest, page_touched, page_is_redirect,
page_len).

Are there other fields we need to keep besides img_sha1? Or should we can
solve the img_sha1 use case in a different manner?

2. img_metadata

This field is a blob of serialised PHP (typically representing the Exif
data of an image).

Tim (correct me if I got it wrong) mentioned we could potentially make
migration easier by changing img_metadata to be stored in a separate table
and change the img_metadata field (in the image revision table) to instead
be a pointer to a primary key.

This could potentially be done separately later, but if it helps migration,
we should consider doing it now.

How will this interact with file deletion? Will it be difficult to garbage
collect this? Do we need to? (We don't seem to do it for the 'text' table /
external store; is it worth moving this an external store?)

3. Migration

If we rename both tables (image/oldimage -> file/filerevision), we'd have
the ability to run migration in the background without interfering with the
live site, and without requiring a long read-only period and/or duplicate
and additional code complexity to be developed.

Is there a way we can do the migration without creating two new tables?
Using the oldimage table as import destination for current rows isn't
straight forward as existing scan queries would need to skip the current
rows somehow while in the midst of this migration. Seems possible, but is
it worth the complexity? (We'd need extra code that knows about that
migration field, and how long do we keep 

[Wikitech-l] Last call on ArchCom-RFC T69223 (Schema change for page content language)

[Rob Lanphier]

Hi everyone

Per 

During E263, Jaime (@jcrespo) put the following choice to us. Should he:

a. Apply this change to all wikis
b. Apply this change to a subset of wikis, on request
c. Not apply this change

We seemed to get consensus around "a" (applying this change to all
wikis), so that's the decision we're putting in "final comment".
ArchCom plans to move this task to "Approved" during E265 (barring any
unaddressed objections in the comments on this task).

See also: 

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Introduction for Gsoc 2017

[Rob Lanphier]

On Wed, Aug 24, 2016 at 10:09 AM, MAYANK JINDAL
 wrote:
>  My name is Mayank Jindal. I am third year undergraduate student
> currently studying at Indian Institute of Technology, Kharagpur. I want to
> take part in Gsoc-2017 from Wikimedia.
> I have knowledge of C, C++, JAVA, Python, Android app development and Web
> development and beginner in *Machine Learning, Artificial Intelligence.*
> I am very enthusiastic to learn new skills which would be required.
> Kindly guide me to proceed further.

Greetings!  It's a bit early for GSoC 2017, but certainly getting to
know the project now will help everyone in 2017.  I think a good next
step is to join one of our IRC channels and say "hi" there:


In case you have a tough time striking up a conversation, this page
gives you some more information to peruse while you wait.


Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W34 ArchCom-RFC meeting: Schema change for page content language

[Rob Lanphier]

Hi everyone,

For this week's office hour, let's discuss [T69223: schema change for
page content language][1]  Jaime Crespo has asked that the developers
seeking this change get general consensus for the change.  A
discussion at an ArchCom IRC meeting isn't strictly necessary for
this, it can't hurt, so let's do it.

My understanding of the key commit[2] is that the new "page_lang"
field was added to the "page" table and that the other schema changes
in the commits are just the ripple effects from changing the page
table.

The discussion is scheduled for 2016-08-24 UTC:
Time: Wednesday 21 UTC (2pm PDT, 23 CEST)
Place: #wikimedia-office
Phab event: [E263]3]
[ArchCom/Status][4]

Rob

[1]: 
[2]: 
[3]: 
[4]: 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] T47317: Sections generated by tag extension do not show up in TOC

[Rob Lanphier]

On Thu, Jul 28, 2016 at 5:46 AM, Lord_Farin  wrote:
> I would like to draw your attention to ticket
> https://phabricator.wikimedia.org/T47317.
> This ticket highlights some issues with the way sections, headers and the
> TOC are handled in the parser in combination with tag extensions and parser
> functions.
>
> Basically the problem is that the TOC is created before strip markers are
> substituted, which prevents some sections from showing up in the TOC.

Thanks for the ping on T47317.  For those that haven't been following
it: Lord Farin has done some exploration of formatHeadings in the
parser, and made the following observation:
> [The call to preprocessToDom] indicates to me that something is wrong
> here. Reprocessing the entire DOM tree of the raw wikitext indicates that 
> things
> are happening at the wrong level or wrong place in the sequence altogether.

I'd love for someone who is more familiar with the differences between
Parsoid's DOM model and MediaWiki's PHP-based processing model to
reply to this (preferably on the ticket[1])

Rob
[1]: https://phabricator.wikimedia.org/T47317

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W33 ArchCom-RFC meeting: Revisiting Content model storage

[Rob Lanphier]

Hi everyone,

For this week's office hour, we'll be revisiting the 2015 proposal to
change content model storage[1] (see also T105652).  The RFC describes
the problems it is solving:

> * The content model and format of a revision is stored as NULL if it
>is the default. This makes changing the default problematic[...]
> * content model and content format are stored as strings
>("wikitext" and "text/x-wiki" respectively) which is inefficient from
>a storage point of view

It then describes some schema changes which hopefully address the problems.

The idea was approved, but was never implemented.  Daniel is now
interested in moving this forward to unblock Multi-Content
Revisions[2] (which relies on this).

The discussion is scheduled for 2016-08-17 UTC:
Time: Wednesday 21 UTC (2pm PDT, 23 CEST)
Place: #wikimedia-office
Phab event: [E261][3]

Rob
p.s. ArchCom status updates continue on [ArchCom/Status][4]

[1]: 
[2]: 
[3]: 
[4]: 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W32 ArchCom-RFC meeting: Wikitext

[Rob Lanphier]

Hi everyone,

This week's office hour: Wikitext!  This discussion is intended to be
a continuation of the "Loosing the history of our projects to bitrot."
thread.

Coren stated the work in front of us very well at the start of it.
> You know, this is actually quite troublesome: as the platform evolves
> the older data becomes increasingly hard to use at all - making it
> effectively lost even if we kept the bits around.  This is a rather
> widespread issue in computing as a rule; but I now find myself distressed
> at its unavoidable effect on what we've always intended to be a permanent
> contribution to humanity.

The thread he started had pretty robust participation on a really
important, which seemed to us in ArchCom worth continuing the
discussion in one of our weekly office hours.  So, after checking with
Subbu (in my list message) that's what ended up as the top candidate.
Subbu did some work to structure the conversation ([A Spec For
Wikitext][1]) and I did some cleanup of the [Wikitext page on
mw.org][2] as a possible hub for information on this topic, with
[Talk:Wikitext][3] providing a durable conversation venue.

Please join us to discuss this further Wednesday UTC
Time: Wednesday 21 UTC (2pm PDT, 23 CEST)
Place: #wikimedia-office
Phab event: [E259][4]

Rob
p.s. as always, ArchCom status updates continue on [ArchCom/Status][5]

[1]: https://www.mediawiki.org/wiki/Parsing/Notes/A_Spec_For_Wikitext
[2]: https://www.mediawiki.org/wiki/Wikitext
[3]: https://www.mediawiki.org/wiki/Talk:Wikitext
[4]: https://phabricator.wikimedia.org/E259
[5]: https://www.mediawiki.org/wiki/Architecture_committee/Status

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Loosing the history of our projects to bitrot. Was: Acquiring list of templates including external links

[Rob Lanphier]

On Wed, Aug 3, 2016 at 8:48 PM, Subramanya Sastry <ssas...@wikimedia.org> wrote:
> On 08/03/2016 07:17 PM, Rob Lanphier wrote:
>> In our planning meeting (E250), we discussed this issue as a
>> possibility for next week's ArchCom office hour (E259).  We don't
>> (yet) have a specific RFC we can point to, but this seems ripe for a
>> discussion to answer whether we should work toward a spec.  Thoughts?
>
> Works for me.

Excellent!

> I can take the email I posted, clean it up a bit, and also pull additional
> thoughts from
> https://www.mediawiki.org/wiki/User:SSastry_(WMF)/Notes/Wikitext and
> elsewhere that are relevant. The idea I have is to provide a very high level
> view of what one possible spec might look like, and what that might enable.
>
> Or, should I pull together something else that might be useful to guide the
> discussion?

I suspect User:SSastry_(WMF)/Notes/Wikitext is a really good
explanation that I suspect will be a good explanation for people who
have deep understanding of parsers and our parsing infrastructure.  I
say "suspect" because I'm operating from a point of someone whose
knowledge of our system is wide and shallow.[1]  I fear that we're
coming from a wide enough set of perspectives about wikitext that
we're doomed to talk past each other, despite ample preparation.

Perhaps a good place to start for our 2016-08-10 conversation is with this page:
<https://www.mediawiki.org/wiki/Markup_spec>

As of this writing, the last really substantive addition to that page
was in 2010.  Maybe we can have a discussion about what should reside
at that URL, and where the content currently on that page should go.

Of course, it would be a lot more fun to have a celebration about how
awesome that page had become in the past week after I sent this email.
That probably won't be because I made the first (or any) edits to the
page  ;-)

Rob

[1] Like the Platte River, which traveling pioneers described as "a
mile wide and an inch deep" and "the most magnificent and useless of
rivers": <https://en.wikipedia.org/wiki/Missouri_River#cite_ref-188>

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Loosing the history of our projects to bitrot. Was: Acquiring list of templates including external links

[Rob Lanphier]

On Mon, Aug 1, 2016 at 10:15 PM, Subramanya Sastry
 wrote:
> When [a detailed list of stuff is] done, it become far more feasible to think 
> of defining
> a spec for wikitext parsing that is not tied to the internals of mediawiki
> or its extensions. At that point, you could implement templating via Lua or
> via JS or via Ruby ... the specifics are immaterial. What matters is those
> templating implementations and extensions produce output with certain
> properties. You can then specify that mediawiki-HTML is a series of
> transformations that are applied to the output of the wikitext parser ...
> and where there can be multiple spec-compliant implementations of that
> parser.
>
> I think it is feasible to get there. But, whether we want a spec for
> wikitext and should work towards that is a different question.

In our planning meeting (E250), we discussed this issue as a
possibility for next week's ArchCom office hour (E259).  We don't
(yet) have a specific RFC we can point to, but this seems ripe for a
discussion to answer whether we should work toward a spec.  Thoughts?

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W31 ArchCom-RFC meeting:

[Rob Lanphier]

Hi everyone

We have another ArchCom-RFC IRC office hour coming up tomorrow.  This
week, we plan to discuss what parts of the notification infrastructure
in Echo we can/should move into MediaWiki Core (T128351).  Brion is
shepherding this RFC, and pointed out on the task that we need "good
enough interfaces in core that other extensions don't have to depend
on Echo; also agreed that shipping Echo with core as a default
extension makes sense."  Much of the recent discussion on that task
has been about what a reasonable level of abstraction, and avoiding
generalizing from a sample set of 1 (as Tgr puts it)

Discussion time/place:
#wikimedia-office: 2016-08-03 (Wednesday) 21:00 UTC (2pm PDT, 23:00 CEST)

More details about the meeting: 
More details about the topic: 

Rob
p.s. ArchCom status updates continue on


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Loosing the history of our projects to bitrot. Was: Acquiring list of templates including external links

[Rob Lanphier]

On Mon, Aug 1, 2016 at 1:56 PM, Gergo Tisza <gti...@wikimedia.org> wrote:
> On Mon, Aug 1, 2016 at 1:01 PM, Rob Lanphier <ro...@wikimedia.org> wrote:
>> On Mon, Aug 1, 2016 at 12:19 PM, Gergo Tisza <gti...@wikimedia.org> wrote:
>> > Specifying wikitext-html conversion sounds like a MediaWiki 2.0 type of
>> > project (ie. wouldn't expect it to happen in this decade), and even then
>> it
>> > would not fully solve the problem[...]
>>
>> You seem to be suggesting that
>> 1.  Specifying wikitext-html conversion is really hard
>> 2.  It's not a silver bullet (i.e. it doesn't "fully solve the problem")
>> 3.  HTML storage looks more like a silver bullet, and is cheaper
>> 4.  Therefore, a specification is not really worth doing, or if it is,
>> it's really low priority
>>
>> Is that an accurate way of paraphrasing your email?
>
> Yes. The main problem with specifying wikitext-to-html is that extensions
> get to extend it in arbitrary ways; e.g. the specification for Scribunto
> would have to include the whole Lua compiler semantics.


Do you believe that declaring "the implementation is the spec" is a
sustainable way of encouraging contribution to our projects?

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Loosing the history of our projects to bitrot. Was: Acquiring list of templates including external links

[Rob Lanphier]

On Mon, Aug 1, 2016 at 12:19 PM, Gergo Tisza  wrote:
> Specifying wikitext-html conversion sounds like a MediaWiki 2.0 type of
> project (ie. wouldn't expect it to happen in this decade), and even then it
> would not fully solve the problem[...]

You seem to be suggesting that
1.  Specifying wikitext-html conversion is really hard
2.  It's not a silver bullet (i.e. it doesn't "fully solve the problem")
3.  HTML storage looks more like a silver bullet, and is cheaper
4.  Therefore, a specification is not really worth doing, or if it is,
it's really low priority

Is that an accurate way of paraphrasing your email?

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Loosing the history of our projects to bitrot. Was: Acquiring list of templates including external links

[Rob Lanphier]

On Mon, Aug 1, 2016 at 9:51 AM, Subramanya Sastry  wrote:
> On 08/01/2016 11:37 AM, Marc-Andre wrote:
>> Is there something we can do to make the passage of years hurt less?
>> Should we be laying groundwork now to prevent issues decades away?
>
>
> One possibility is considering storing rendered HTML for old revisions. It
> lets wikitext (and hence parser) evolve without breaking old revisions. Plus
> rendered HTML will use the template revision at the time it was rendered vs.
> the latest revision (this is the problem Memento tries to solve).


This is a seductive path to choose.  Maintaining backwards
compatibility for poorly conceived (in retrospect) engineering
decisions is really hard work.  A lot of the cruft and awfulness of
enterprise-focused software comes from dealing with the seemingly
endless torrent of edge cases which are often backwards-compatibility
issues in the systems/formats/databases/protocols that the software
depends on.  The [Y2K problem][1] was a global lesson in the
importance of intelligently paying down technical debt.

You outline the problems with this approach in the remainder of your email

> HTML storage comes with its own can of worms, but it seems like a solution
> worth thinking about in some form.
>
> 1. storage costs (fully rendered HTML would be 5-10 times bigger than
> wikitext for that same page, and much larger if stored as wikitext diffs)
> 2. evolution of HTML spec and its affect on old content (this affects the
> entire web, so, whatever solution works there will work for us as well)
> 3. newly discovered security holes and retroactively fixing them in stored
> html and released dumps (not sure).
> ... and maybe others.

I think these are all reasons why I chose the word "seductive" as
opposed to more unambiguous praise  :-)  Beyond these reasons, the
bigger issue is that it's an invitation to be sloppy about our
formats.  We should endeavor to make our wikitext to html conversion
more scientifically reproducible (i.e. "Nachvollziehbarkeit" as Daniel
Kinzler taught me).  Holding a large data store of snapshots seems
like a crutch to avoid the hard work of specifying how this conversion
ought to work.  Let's actually nail down the spec for this[2][3]
rather than kidding ourselves into believing we can just store enough
HTML snapshots to make the problem moot.

Rob

[1]: https://en.wikipedia.org/wiki/Year_2000_problem
[2]: https://www.mediawiki.org/wiki/Markup_spec
[3]: https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] BetaFeatures grafana dashboard

[Rob Lanphier]

On Fri, Jul 29, 2016 at 11:14 AM, James Forrester
 wrote:
>
> On 29 July 2016 at 02:54, Addshore  wrote:
>
> > Recently WMDE started rolling out the RevisionSlider beta feature to a
> > handful of wikis.
> >[...]
> > https://grafana.wikimedia.org/dashboard/db/betafeatures
> >
> > Any comments / suggestions are very welcome.
>
> This is neat; as I mentioned to Adam, there's already the Beta Feature
> dashboard
> 

Thank you Adam for developing this dashboard, and thanks James for
linking to it from the Beta Features page[1].  I would add a "Usage"
section to the Beta Features page, and briefly describe how to read
the graphs, but I would probably get it wrong.  I'd be happy to talk
more about the prose on Talk:Beta_Features[2] (and I may even try
adding that prose myself, but don't want to cookie lick[3])

Rob

[1]: https://www.mediawiki.org/wiki/Beta_Features
[2]: https://www.mediawiki.org/wiki/Talk:Beta_Features
[3]: https://en.wiktionary.org/wiki/cookie_licking

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W30 ArchCom-RFC meeting: authenticated key-value store

[Rob Lanphier]

Hi everyone

In our upcoming ArchCom-RFC IRC office hour meeting, we plan to
discuss T128602, which discusses how to implement an authenticated
key-value store in MediaWiki.  Dmitry Brant wrote the original RFC,
and Brad Jorsch refined it, listing out many questions on the Phab
task (e.g. Action API endpoint or RESTbase service, how should we
store the data, what limits should we have, what sort of abuse
prevention strategy should we employ)

Discussion time/place:
#wikimedia-office: 2016-07-27 (Wednesday) 21:00 UTC (2pm PDT, 23:00 CEST)

More details about the meeting: 
More details about the topic: 

Rob
p.s. ArchCom status updates continue on


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How widely is Flow being used?

[Rob Lanphier]

On Thu, Jul 21, 2016 at 4:19 PM, Pine W  wrote:
>
> I believe that Flow is being used on an opt-in basis on Wikidata and
> Catalan Wikipedia, and is used on user talk pages by default on MediaWiki.
>
> Is that correct?
>
> Are there any wikis other than MediaWiki where Flow is enabled on all talk
> pages by default?
>
> Are there any wikis where Flow is widely used on an opt-in basis, even if
> it's not the default?


Good questions.  I'm kinda curious, but I'm not interested enough to dig it out.

I imagine a great place to (also) ask this set of questions is here:


Rob
p.s. if you already have asked this on wiki, please let us know a
pointer to your question on-wiki, as that will result in a much better
archive for the conversation.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W29 ArchCom-RFC meeting: Plan for a cross-wiki watchlist back-end

[Rob Lanphier]

Hi all,

The plan for next week's ArchCom office hour is to discuss T126641:
[RFC] Devise plan for a cross-wiki watchlist back-end.  There's been a
fair amount of discussion already on T126641 which is trying to sort
out the following questions:
* Is keeping a central table of all recent changes for all wikis a
doable option?
* Is doing separate queries for each wiki a better or worse idea?
* Are there ways that we could mitigate the impact of either of those options?
* Are there other options that we haven't even thought about yet?

#wikimedia-office: 2016-07-20 (Wednesday) 21:00 UTC (2pm PDT, 23:00 CEST)

More details about the meeting: 
More details about the topic: 

Of course, no one needs to wait for the meeting to comment.  Please
make your thoughts known on this list, or in Phab on T126641.

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Rob Lanphier]

On Tue, Jul 12, 2016 at 8:02 AM, Brad Jorsch (Anomie)
 wrote:
> One simple method: assign the numeric IDs by making the numeric ID column
> auto-increment, and insert the model strings into the table as needed.
> PageAssessments uses this model for tracking its project tags.[1]
>
> The disadvantage is that there wouldn't be any cross-wiki mapping between
> model names and ids, which can be mitigated somewhat by never exposing the
> ids externally.

Could you explain this idea in a way that doesn't require diving into
the codebase to figure out what you mean?  Cloaking the mapping of
local ids (e.g. auto incremented in the DB) to global ids ("model
names") seems to suggest a new way of making our system behave in an
inscrutable way.

On Tue, Jul 12, 2016 at 9:00 AM, Brad Jorsch (Anomie)
 wrote:
>  [Does this namespace registry idea work?]
>
> https://www.mediawiki.org/wiki/Extension_default_namespaces?

 That doesn't seem like a good model to emulate.  We're not iana.org,
and we don't have anywhere near the rigor defined in IETF RFC 5226.  I
may put further thoughts on this topic in the Interwiki map RFC
(T113034) task

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What's the "correct" content model when rev_content_model is NULL?

[Rob Lanphier]

On Tue, Jul 12, 2016 at 1:40 AM, Daniel Kinzler  wrote:

> Do we really want to manage something that is essentially configuration,
> namely
> the set of available content models and formats, in a database table? How
> is it
> maintained?
>
> For context:
> * As per T113034, we are movign away from managing interwiki prefixes in
> the
> database, in favor of configuration files.
> * Namespace IDs are defined in LocalSettings.php.
>
> The original design of ContentHandler used integer IDs for content models
> and
> formats in the DB. A mapping to human readable names is only needed for
> logging
> and error messages anyway.


This oversimplifies things greatly.  Integer IDs need to be mapped to some
well-specified, non-local (global?) identifier for many many purposes
(reading exports, writing exports, reading site content, displaying site
content for many contexts, etc)

As Jaime points out, we don't want or need 6 billion copies of the same
identifier in our database.  However, relegating that information to
LocalSettings.php means that we'll have to manually sync that critical
configuration data for use by non-PHP implementations interacting with the
information.

On Tue, Jul 12, 2016 at 3:40 AM, Daniel Kinzler  wrote:
>
> I'm fine with the DB based solution, if we have decent tooling for
> extensions to
> register their content models, etc.


We need to put a lot of thought into content model management generally.
This statement implies managing content models outside of the database is
easy.

Rob



>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W28 ArchCom-RFC meeting: image and oldimage tables

[Rob Lanphier]

Hi all,

The ArchCom-RFC office hour is coming up soon (Wednesday, 21:00 UTC,
2pm PDT, 23:00 CEST).  Our topic: image and oldimage tables (which are
an artifact from when we had "cur" and "old" tables).  Rumor has it
that it was discussed at the 2011 Amsterdam Hackathon

Phab task: https://phabricator.wikimedia.org/T589
Phab event: https://phabricator.wikimedia.org/E228
Phab phour: https://en.wikipedia.org/wiki/Fab_Four

The ArchCom status page continues to have regular updates from the group:
https://www.mediawiki.org/wiki/Architecture_committee/Status

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W27 ArchCom-RFC meeting: programming languages in MediaWiki

[Rob Lanphier]

Hi everyone,

This week, here's the planned agenda for the ArchCom office hour:

ArchCom-RFC office hour 2016W27: 2016-06-29: E226 (E66/42)[1]

-   T136866: Improve the per-programming-language listings for our
tools[2]
-   Let's figure out how newcomers should identify programming
languages used on the Wikimedia cluster that align with their
interests/skills."What can I work on in language foo" or "I'm
really great with language foo, bar, and baz; anything for me to
help out with?"
-   Is the [[mw:Programming_languages]][3] page a good start? Is this
the page we should easier to find? Are there better landing
pages for someone trying to answer the questions above?

The ArchCom status page[4] has these links and other information too
(e.g. last week's decision to deprecate running MediaWiki without
curl)[5]

Rob

  [1]: https://phabricator.wikimedia.org/E226
  [2]: https://phabricator.wikimedia.org/T136866
  [3]: https://www.mediawiki.org/wiki/Programming_languages
  [4]: https://www.mediawiki.org/wiki/Architecture_committee/Status
  [5]: https://phabricator.wikimedia.org/T137926

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Crediting the work of our community members

[Rob Lanphier]

On Tue, Jul 5, 2016 at 10:33 AM, Brion Vibber  wrote:
> On Mon, Jul 4, 2016 at 9:06 AM, Jon Robson  wrote:
>> I've created the following 2 actionable tasks:
>> https://phabricator.wikimedia.org/T139300
>> https://phabricator.wikimedia.org/T139301
>>
>> I hope we can reach a decision somewhat promptly with this.
>
> Jon, I like both of these.
[...]
> These should probably both go through our ArchCom RfC process, which we're
> trying to get more involvement in both from WMFers and others.

That sounds like a good idea.  Jon, are you amenable to that?  If so,
one of us should add the #ArchCom-RFC project tag to one or both of
these.

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] μRfC: Requiring 'curl' PHP extension for MediaWiki

[Rob Lanphier]

On Wed, Jun 15, 2016 at 1:51 PM, James Forrester
 wrote:
> Right now we have some features that require curl (it's probably the #2
> issue third parties have with installing VisualEditor, for instance, after
> mis-matched versions).

We discussed [the proposal to start requiring curl][2] at [this week's
IRC office hour][1], where we decided to deprecate running MediaWiki
without curl.  In particular, we agreed:

*  We still won't require curl, keeping existing non-curl codepath
*  We'll add a non-parallel MultiHttpClient fallback
*  Special:Version will let users know if the wiki is running without curl

Now we'd like to open this up for last call, and review any objections
discussed over the course of the week at [next week's ArchCom Planning
meeting][3].  Any objection to this plan?

Rob

[1]: https://phabricator.wikimedia.org/E224
[2]: https://phabricator.wikimedia.org/T137926
[3]: https://phabricator.wikimedia.org/E225

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Plan for 2016W26 ArchCom-RFC meeting: curl? programming languages?

[Rob Lanphier]

Hi everyone,

With Wikimania and associated summer travel, this is going to be a rough
week to get everyone together at our usual time for the weekly
ArchCom-RFC IRC office hour:


There are a couple of RFCs that might make good short-term choices:

-   T137926 - Require 'curl' PHP extension for MediaWiki[1]

James filed this a couple of weeks ago as a "μRfC".  The hope is
to enable greater use of MultiHttpClient.


-   T136866 - Improve the per-programming-language listings for our
tools[2]

Quiddity plans to expand this documentation in the coming quarter.
A clearer idea about the status quo would help us guide developers
about which languages we hope to attract new development in.


However, we would welcome suggestions for others.  Please comment here:


If nothing else, we can use this week's meeting as a triage discussion.

Rob

p.s. Updates continue on Architecture_committee/Status:


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Plan for 2016W25 ArchCom RFC meeting: talk about Markdown support

[Rob Lanphier]

Hi folks

I've made some updates to the [ArchCom status][1] page.  In
particular, I linked to [the very rough RFC I filed about
Markdown][2], where I'm suggesting we develop a strategy around
Markdown.  The plan we agreed to in [2016W24 ArchCom Planning
meeting][3] was to discuss Markdown at [next week's ArchCom-RFC office
hour][4], since we think that'll be a good hallway track conversation
for people at Wikimania, and the IRC conversation will be good fun for
those of us who aren't going to make it out this year but can make it
to the IRC conversation.

Rob

[1]: https://www.mediawiki.org/wiki/Architecture_committee/Status
[2]: https://phabricator.wikimedia.org/T137946
[3]: https://phabricator.wikimedia.org/E212
[4]: https://phabricator.wikimedia.org/E218

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W24 ArchCom RFC meeting (2016-06-15)

[Rob Lanphier]

Hi everyone,

We're holding another ArchCom-RFC meeting this week to follow up on
the thread Yuri started about T120452.

The ArchCom status page is finally up-to-date with last week's info:


(and it's quoted below)

Links!:
This week's meeting: 
RFC for this week's meeting: 
Subject of the RFC: Allow tabular datasets on Commons (or some similar
central repository) (CSV, TSV, JSON, XML)
Location: #wikimedia-office IRC channel
Time: 2016-06-15 Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)

Meetbot looks forward to scribing your presence!

Rob



Source of [[mw:Architecture_committee/Status]], where "phab:" links
are pointers to https://phabricator.wikimedia.org

This page provides status update for [[Requests for
comment|ArchCom-RFCs]], with an emphasis on ArchCom team member.  As
of this writing on 2016-04-29, this update is an experiment discussed
[[Topic:T2zctt083izvx07l|weekly ArchCom update discussion on the
"ArchCom/Team practices" talk page]].

= Recent RFC meetings =
*ArchCom Planning meeting 2016W23: 2016-06-08: [[Phab:E202]] (E156/10)
**Notes: [[Architecture committee/2016-06-08]]
*ArchCom-RFC office hour 2016W23: 2016-06-08: [[Phab:E203]] (E66/38)
** [[Phab:T89331|T89331 Replace Tidy in MW parser with HTML 5
parse/reserialize]]

= Upcoming RFC meetings =
*ArchCom Planning meeting 2016W24: 2016-06-15: [[Phab:E212]] (E156/11)
**Notes: [[Architecture committee/2016-06-15]]
*ArchCom-RFC office hour 2016W24: 2016-06-15: [[Phab:E213]] (E66/39)
** [[Phab:T120452|T120452]]: Allow tabular datasets on Commons (or
some similar central repository) (CSV, TSV, JSON, XML)
*** See also: comments in T124569 and T134426

= Entering Final Comment Period =
* None.

= Recently Approved =
* none

 RFC inbox 
* [[phab:tag/archcom-rfc/|ArchCom RFC board]]:
** [[Phab:T124569|T124569 RFC: Data namespace blob storage on wikidata.org]]

= Shepherd status =
* Brion
** [[Phab:T107595|T107595]] Multi-content revisions is interesting,
needed for various things in multimedia land
*** Meeting happened earlier this week; notes are on the ticket
** T66214 - predictable thumb URLs
*** Break this out into:
 Define set of core & extensible media file options for Handler extensions
 Predictable thumb URLs
 Improve InstantCommons perf by reducing need to run thumbnail URL lookups
 Iframe-based rich media embedding for InstantCommons
** plan to write up new RfCs for:
*** In-browser SVG rendering (pick up existing bug & mailing list notes)
*** iframe+CSP-isolated JS widgets for rich content
 & extend that to InstantCommons via embedding
*** iframe+CSP-isolated JS gadgets for UI plugins
 Build these out from ideas from hackathon project T131436
* Daniel
** Software Quality working group - will follow up on earlier
proposal.  Will talk to people at Wikimania
** Working on Multi Content Rev Spec with Brion
** T113034 [[phab:T113034|RFC: Overhaul Interwiki map, unify with
Sites and WikiMap]]: checking in with Adam
** T89733 (approved, with Stas driving implementation)
* Gabriel
** Looking into content composition working group, possibly kick-off
at Wikimania
** Discussing Multi Content Rev / RB interaction with Daniel;
follow-up at Wikimania
* Roan
** T108655 [[phab:T108655|RFC: Standardise JavaScript interfaces]]: I
need to start the second part, but the recent comments have me
confused. I'll need to talk to Timo and figure out what the subject of
part two should be.
* RobLa
** Working with [[User:DPatrick (WMF)|DPatrick]] on [[Wikimedia
Security Team]] issues in an attempt to be useful there.
** T123753 [[phab:T123753|Establish retrospective reports for Security
and Performance incidents]]
*** In scope for this group?
** Forming ArchCom-affiliated working groups
*** RFCs
 T124504 [[phab:T124504|Transition WikiDev '16 working areas into
working groups]] and
 T123606 [[Phab:T123606|RFC: Implement ArchCom-affiliated working
groups (process inspired by Rust's "subteams")]]
*** Testing Conpherence use for means of piloting ArchCom working
groups.  Still using [[Phab:Z425]] as asynchronous ArchCom-RFC triage
channel.  A Security/ArchCom quasi-working group discusses some issues
in [[Phab:Z411]].  I started renaming "subteams" to "working groups"
on [[Requests for comment/Governance]] (with Nemo's help).
* Tim
** [[Phab:T89331|T89331 (Replace Tidy in MW parser with HTML 5
parse/reserialize)]] - should meet to discuss migration rather than
implementation plan
** T11 [[phab:T11|RFC: Introduce notion of DOM scopes in
wikitext]]: (Update?)
*** Scott has implementation work in progress
* Timo
** [[phab:T18691|T18691 RFC: Section headings should have a clickable
anchor]]: Reading team expressed interest to help shape the solution.
Still open for more use cases and different ideas for how to solve it.
Possible scope creep.
** 

Re: [Wikitech-l] Enabling shared tabular data pages

[Rob Lanphier]

Let's revive this thread for this week's ArchCom RFC meeting.  I'll
doll up a more formal announcement as I finish cleaning up some of our
notes documents, but for now, the short version:
URL: 
Time: 2016-06-15, Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)
Location: #wikimedia-office IRC channel

Rob

On Sat, Jun 4, 2016 at 9:47 AM, Yuri Astrakhan  wrote:
> We have had some good feedback for the new shared tabular data feature, and
> we are getting ready to deploy it in production. It would be amazing if you
> can give it a final look-over to see if there are any blockers left.
>
> The first stage will be to enable  Data:*.tab  pages on Commons, and allow
> all other wikis direct access to it via Lua code and Graph extension. All
> data at this point must be licensed under CC0. More licensing options are
> still under discussion, and can be easily added later.
>
> In line with the "release early, release often", we will not have any
> elaborate data editing interface beyond the raw JSON code editor for the
> first release. Our initial target audience is the more experienced users
> who will evaluate and test the new technology. Once the underlying tech is
> stable and prooven, we will work on making it more accessible to the
> general audience.
>
> Links:
> * Task: https://phabricator.wikimedia.org/T134426
> * Demo: http://data.wmflabs.org
> * Technical: https://www.mediawiki.org/wiki/Extension:JsonConfig/Tabular
> * Discussion:
> https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Tabular_data_storage_for_Commons.21
> * Facebook:
> https://www.facebook.com/groups/wikipediaweekly/permalink/997545366959961/
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Crediting the work of our community members

[Rob Lanphier]

On Tue, Jun 7, 2016 at 9:19 AM, Andre Klapper  wrote:
> Is there a Phabricator task [associated with MediaWiki CREDITS file 
> membership] so this topic does not get forgotten?

Not that I'm aware of.  It's easy to get lost looking through the
various attempts to objectively characterize contributions (he says,
just emerging from the fog of doing so himself).  Here's a few places
a person could go:
* 
* 
* 
* 

...and that's hardly comprehensive.  The "productivity of mediawiki
developers" thread from April[1] probably has some other sources I've
missed.  If I were to spend more time on this, I would start looking
for the Phab tickets associated with the stats on Korma.

I concur with Jon that we should endeavor to move to a more objective
(and ideally, more automated) mechanism for acknowledgement, so that
we don't have to rely on contributors confidently declaring that they
deserve acknowledgement.

Rob
[1] http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/86127

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W23 ArchCom RFC meeting (2016-06-08)

[Rob Lanphier]

Hi everyone,

This week's ArchCom-RFC meeting is about T89331 ("Replace Tidy in MW
parser with HTML 5 parse/reserialize"). Information about the
goings-on of ArchCom continues to exist on the ArchCom Status page:


...and also copied below for your convenience.

My understanding is that the authors feel pretty good about the
implementation, and are looking for help figuring out how to implement
a successful migration.

Other handy links and information:
This week's meeting: 
RFC for this week's meeting: 
Subject of the RFC: Replace Tidy in MW parser with HTML 5 parse/reserialize
Location: #wikimedia-office IRC channel
Time: 2016-06-08 Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)

I'm looking forward to chatting with you there!

Rob




Source of [[mw:Architecture_committee/Status]], where "phab:" links
are pointers to https://phabricator.wikimedia.org


This page provides status update for [[Requests for
comment|ArchCom-RFCs]], with an emphasis on ArchCom team member.  As
of this writing on 2016-04-29, this update is an experiment discussed
[[Topic:T2zctt083izvx07l|weekly ArchCom update discussion on the
"ArchCom/Team practices" talk page]].

= Recent RFC meetings =
* ArchCom Planning meeting 2016W22: 2016-06-01: [[Phab:E197]] (E156/9)
** Notes: [[Architecture committee/2016-06-01]]
* ArchCom-RFC office hour 2016W22: 2016-06-01: [[Phab:E198]] (E66/37)
** Security discussion, including:
*** CSP - [[Phab:T135963|T135963]]

= Upcoming RFC meetings =
*ArchCom Planning meeting 2016W23: 2016-06-08: [[Phab:E202]] (E156/10)
**Notes: [[Architecture committee/2016-06-08]]
*ArchCom-RFC office hour 2016W23: 2016-06-08: [[Phab:E203]] (E66/38)
** [[Phab:T89331|T89331 Replace Tidy in MW parser with HTML 5
parse/reserialize]]

= Entering Final Comment Period =
* None.

= Recently Approved =
* none

 RFC inbox 
* [[phab:tag/archcom-rfc/|ArchCom RFC board]]:
** Inbox zero on 2016-06-11.

= Shepherd status =
* Brion
** Multi-content revisions (T107595) is interesting
* Daniel
** Software Quality working group?
** Working on Multi Content Rev Spec with Brion
** T113034 [[phab:T113034|RFC: Overhaul Interwiki map, unify with
Sites and WikiMap]]: checking in with Adam
** T89733 (approved, with Stas driving implementation)
* Gabriel
** Working with [[User:BSitzmann (WMF)|BSitzmann]] on
[[Phab:T132597|T132597]] (no longer an RFC)
* Roan
** T108655 [[phab:T108655|RFC: Standardise JavaScript interfaces]]: I
need to start the second part, but the recent comments have me
confused. I'll need to talk to Timo and figure out what the subject of
part two should be.
* RobLa
** Starting to use [[Phab:Z425]] as asynchronous ArchCom-RFC channel,
testing Conpherence use for means of piloting ArchCom working groups.
We may still have more separate triage discussions, but I'm waiting to
get feedback on [[phab:T135674|T135674]].
** Working with [[User:DPatrick (WMF)|DPatrick]] on [[Wikimedia
Security Team]] issues in an attempt to be useful there.
* Tim
** [[Phab:T89331|T89331 (Replace Tidy in MW parser with HTML 5
parse/reserialize)]] - should meet to discuss migration rather than
implementation plan
** T11 [[phab:T11|RFC: Introduce notion of DOM scopes in
wikitext]]: (Update?)
* Timo
** Section anchors - will update T18691
** CSP - [[Phab:T135963|T135963]] - Will shepherd
** Local storage abstraction [[Phab:T121646|T121646]] working with
Fundraising on this to move cookies into local storage; not an RFC
yet, but may become one.

= No activity in the last two weeks =
* T122942 [[phab:T122942|RFC: Support language variants in the
RESTBase]] (Gabriel)
* T39902 [[phab:T39902|RFC: Implement rendering of redlinks in
Parsoid]] (no shepherd)
* T18691 [[phab:T18691|RFC: Section headings should have a clickable
anchor]] (Timo)
* T111588 [[phab:T111588|RFC: API-driven web front-end]] (Timo)
* T123753 [[phab:T123753|Establish retrospective reports for Security
and Performance incidents]] (RobLa)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T105766 [[phab:T105766|RFC: Dependency graph storage]] (Gabriel)
* T124504 [[phab:T124504|Transition WikiDev '16 working areas into
working groups]] (RobLa)
* T66214 [[phab:T66214|Use content hash based image / thumb URLs &
define an official thumb API]] (Brion)
* T91162 [[phab:T91162|RFC: Shadow namespaces]] (Brion)
* T128351 [[phab:T128351|RFC: Notifications in core]] (Brion)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T54807 [[phab:T54807|Identify and remove legacy preferences from
MediaWiki core]] (no shepherd)
* T88596 [[phab:T88596|Improving extension management]] (Daniel)

= Useful Phab links =
* [[phab:maniphest/query/xc.j4DEYcjwu/#R|Query for shepherd assignments]]
* 

Re: [Wikitech-l] Enabling shared tabular data pages

[Rob Lanphier]

On Mon, Jun 6, 2016 at 6:40 AM, Yuri Astrakhan 
wrote:

> Daniel, I agree about the data/api versioning. I was mostly talking about
> features and capabilities. For example, we could spend the next year
> developing a visual table editor, implement support for unlimited table
> sizes, provide import/export from other table formats, introduce elaborate
> schema validation, and many other cool features. And after that year
> realize that users don't need this whole thing at all, or need something
> similar but very different.  Or we could release one small, well defined,
> stable subset of that functionality, get feedback, and move forward.
>

Hi Yuri,

I think one thing that would be helpful for me (and I suspect many people
who want to help) is some more specifics about this statement from your
original email: "We have had some good feedback for the new shared tabular
data feature, and we are getting ready to deploy it in production."  Which
"we" are you referring to, and by "getting ready to deploy it in
production", does that mean it's about to be usable where someone could
upload gigabytes of production data in this format Commons by the end of
the week?  Is there a more measured plan published somewhere?

This all sounds very cool, but also an area where we could accidentally
accrue a crushing load of technical debt without fully realizing it (per
Daniel's comment).  I'll confess to being ignorant on everything that's
been going on, and I'm wondering now how desperately I should study your
documentation to make up for it (and how important it is to drop other work
to make time for this).

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016W22 ArchCom RFC meeting (2016-06-01)

[Rob Lanphier]

Hi everyone,

We're planning to have our regular ArchCom-RFC IRC meeting in a couple
of hours.  Phab event: 

Location: #wikimedia-office IRC channel
Meeting type: Problem definition
Time: 2016-06-01 Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)

The experiment using Phab Conpherence rooms for public discussions
continues with Phab:Z425.  I will optimistically say this has not
*yet* succeeded  :-) [1]

The topic ArchCom agreed to focus on this week is Security.  Here's a
few candidate topics for us to discuss in today's meeting:

* T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki
* T75953: RFC: MediaWiki HTTPS policy
* T123753: Establish retrospective reports for #security and
#performance incidents

Broadly speaking: the theme for today is "security is everyone's job".
Really, it is.  If you have +2 rights, and you *don't* think security
is your job, please think about why you deserve to keep that right.
We all have a responsibility to step up our game in this area.  Let's
use today's IRC meeting to figure out how we intend to step up.

Rob

[1]   The thing that makes me optimistic about Conpherence is that
it's a persistent log of a linear conversation that integrates well
with the rest of Phabricator.  The Z425 Conpherence:


More thoughts later here:
, and the
talk page there is a good place for off-thread replies.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Add Content-Security-Policy header to MediaWiki

[Rob Lanphier]

On Sun, May 22, 2016 at 6:17 PM, Brian Wolff  wrote:

> Content-Security-Policy (CSP) header is a header that disables certain
> javascript features that are commonly used to exploit XSS attacks, in
> order to mitigate the risks of XSS. I think we could massively benefit
> from using this technology - XSS attacks probably being the most
> common security issue in MediaWiki. The downside is that it would
> break compatibility with older user scripts.
>
> Please see the full text of my proposal at
> https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
>
> The associated phabricator ticket is:
> https://phabricator.wikimedia.org/T135963


Hi everyone,

Brian, thanks for starting the discussion about CSP here!  We're not yet in
the position to make a final call on this, but let's use tomorrow's
security-oriented ArchCom-RFC IRC office hour[1] as an opportunity to
discuss this one further.

For the rest of y'all: my apologies for the short notice on the meeting
tomorrow.  The IRC meeting is in Phab as E198; more on that as my next
email.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom-RFC triage meeting later today (22:00 UTC/2pm PDT)

[Rob Lanphier]

Hi everyone,

We're planning on making today's RFC office hour[1] a triage meeting (at my
request).  The agenda I'm planning to use is to (reasonably) quickly step
through the list of RFCs in the backlog column of the ArchCom-RFC board.  A
wiki copy of this is posted on mediawiki.org[3], which I invite edits to
(albeit with the usual risk of edit conflicts).

The goal of this meeting will be to get through as many of the RFCs, where
I give a gut check for what the priority is, y'all tell me how wrong I am,
and then I set the priority.

For those of you that can't make it, don't sweat it.  Nothing is set in
stone; Phab tickets are easy enough to edit.  Furthermore, I'd like to
experiment with using a Phab Conpherence room for ongoing triage: Phab:Z425
[4].  Conpherence rooms are a bit more persistent than IRC conversations,
are cognitively cheaper to set up and use than mailing lists, and they
integrate nicely with Phab.  If there's a comment about something we do in
the E187 meeting that you wish you had been there to make, and you don't
feel it's appropriate for a wikitech-l posting, the Z425 Conpherence room
is a great place to make your comment.

I'm looking forward to chatting with y'all!

Rob


[1] E187: RFC Meeting: triage meeting (2016-05-25, #wikimedia-office)
https://phabricator.wikimedia.org/E187
[2] #ArchCom-RFC board: https://phabricator.wikimedia.org/tag/archcom-rfc/
[3] Preliminary ordered list of items for triage:
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_triage_2016-05-25
[4]: https://phabricator.wikimedia.org/Z425
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom-RFC status update: 2016-W20

[Rob Lanphier]

Hi everyone,

Here's the ArchCom RFC status update for 2016-W20 [1], which is also
available via mw:Architecture_committee/Status [2]

= Recent RFC meetings =
* ArchCom Planning meeting 2016W20: 2016-05-18: [[Phab:E183]] (E156/7)
** Notes: [[Architecture committee/2016-05-18]]
* ArchCom-RFC office hour 2016W20: 2016-05-18: [[Phab:E184]] (E66/35)
** [[Phab:T102476|T102476: RFC: Requirements for change propagation]]

= Upcoming RFC meetings =
* ArchCom Planning meeting 2016W21: 2016-05-25: [[Phab:E194]] (E156/8)
** Notes: [[Architecture committee/2016-05-25]]
* ArchCom-RFC office hour 2016W21: 2016-05-25: [[Phab:E187]] (E66/36)
** RFC triage meeting using [[phab:tag/archcom-rfc/|ArchCom RFC board]]
** Goal: assign priorities for items marked "needs triage" and ensure
that high priority items are clearly marked as such

= Entering Final Comment Period =
* None.

= Recently Approved =
* [[Phab:T120164|T120164 RFC: Institute "last call" period]]

 RFC inbox 
* [[phab:tag/archcom-rfc/|ArchCom RFC board]]:
** Inbox zero on 2016-06-11.

= Shepherd status =
* Brion
** (?)
* Daniel
** Software Quality working group?
** Working on Multi Content Rev Spec with Brion
** T113034 [[phab:T113034|RFC: Overhaul Interwiki map, unify with
Sites and WikiMap]]: (Update?)
* Gabriel
** Working with [[User:BSitzmann (WMF)|BSitzmann]] on
[[Phab:T132597|T132597]] (RFC: Agree on endpoints for feeds)
* Roan
** T108655 [[phab:T108655|RFC: Standardise JavaScript interfaces]]: I
need to start the second part, but the recent comments have me
confused. I'll need to talk to Timo and figure out what the subject of
part two should be.
* RobLa
** Still need to schedule an RFC triage meeting outside of ArchCom-RFC time
*** Filed [[phab:T135674|T135674]], and made it clear that I'm not
going to be able to do this without some help.
** Created [[phab:project/manage/2002/|#ArchCom-Approved Phab tag]]
([[Phab:T133803|T133803]])
* Tim
** Not many updates with cscott out of office.  T89331 (Replace Tidy
in MW parser with HTML 5 parse/reserialize)
** T11 [[phab:T11|RFC: Introduce notion of DOM scopes in
wikitext]]: (Update?)
* Timo
** No update

= No activity in the last two weeks =

* T18691 [[phab:T18691|RFC: Section headings should have a clickable
anchor]] (Timo)
* T111588 [[phab:T111588|RFC: API-driven web front-end]] (Timo)
* T123753 [[phab:T123753|Establish retrospective reports for Security
and Performance incidents]] (RobLa)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T105766 [[phab:T105766|RFC: Dependency graph storage]] (Gabriel)
* T124504 [[phab:T124504|Transition WikiDev '16 working areas into
working groups]] (RobLa)
* T66214 [[phab:T66214|Use content hash based image / thumb URLs &
define an official thumb API]] (Brion)
* T91162 [[phab:T91162|RFC: Shadow namespaces]] (Brion)
* T128351 [[phab:T128351|RFC: Notifications in core]] (Brion)
* T122825 [[phab:T122825|Service ownership and minimum maintenance
requirements]] (Gabriel)
* T54807 [[phab:T54807|Identify and remove legacy preferences from
MediaWiki core]] (no shepherd)
* T88596 [[phab:T88596|Improving extension management]] (Daniel)

Our meeting for 2016-W21 (this coming Wednesday) will be a triage of
the ArchCom-RFC queue[3]

Rob
[1] ISO week 2016-W20: https://en.wikipedia.org/wiki/ISO_week_date
[2] https://www.mediawiki.org/wiki/Architecture_committee/Status
[3] https://phabricator.wikimedia.org/tag/archcom-rfc/

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal to invest in Phabricator Calendar

[Rob Lanphier]

> If we're going to be investing money into improving Phabricator upstream...

It's really good that we're having a healthy debate about the
usability of Phabricator.  I've enjoyed working with Phab a lot more
than the tools that it has replaced, but it is by no means perfect.
We have a role to play in helping Phab upstream make Phab more
perfect.

That said, I think we should be careful with our assumptions about how
much influence we can buy with the money we have.  We need to be smart
about how we spend it, but we also need to respect that we don't know
what our role is in upstream's priority setting and roadmap.  We
shouldn't assume we're their most important customer.

Without identifying specific issues, let's assume that we have a
feature list ordered like this:
* Feature A
* Feature B
* Feature C
- cut line for what we'd pay for 
* Feature D
* Feature E
- cut line for features that we care about at all 
* Feature F
* Feature G

My (admittedly limited) understanding is that upstream is choosing
between Feature C and Feature G as the next big thing they work on.
If we chip in for Feature C, we could tip the balance and cause them
to choose Feature C over Feature G.

I fear that a lot of the feedback seems to be "stop worrying about
Feature C; Feature A is *way* more important".  If upstream is making
a C vs G decision, and we try distracting them with A, they may choose
to ignore us and opt for Feature G.  There is a significant
opportunity cost in time and energy to spend influencing upstream to
pay attention to Feature A.

Sogetting out of the abstract and into the specific: is improving
calendaring (T1035) important enough to invest a little money in,
*considered independently* of the other features we may want?  Is it
above the "cut line for what we'd pay for" or is it less than that?

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom-RFC status update: 2016-05-11

[Rob Lanphier]

Hi everyone,

The ArchCom-RFC status update from our previous Wednesday's ArchCom
meeting is in the mail below.  The dedicated wiki page was updated in
a far more timely manner than this mailing list:


-
# Recent RFC meetings

-   ArchCom Planning meeting: 2016-05-11: [Phab:E170][] (E156/6)
-   Notes: [Architecture committee/2016-05-11][]
-   ArchCom-RFC office hour: 2016-05-11: [Phab:E171][] (E66/34)
-   [T113034 RFC: Overhaul Interwiki map, unify with Sites and
WikiMap][]

# Upcoming RFC meetings

-   ArchCom Planning meeting: 2016-05-18: [Phab:E183][] (E156/7)
-   Notes: [Architecture committee/2016-05-18][]
-   ArchCom-RFC office hour: 2016-05-18: [Phab:E184][] (E66/35)
-   [T102476: RFC: Requirements for change propagation][]

-   The [ArchCom-RfCs board][] has a "Ready for RFC meeting" column
which should contain an ordered queue of RFCs planned for IRC office
hour

# Entering Final Comment Period

-   (none)

# Recently Approved

-   [T120164 RFC: Institute "last call" period][]

 RFC inbox

-   [ArchCom RFC board][]:
-   Inbox zero on 2016-06-11.

# Shepherd status

-   Brion
-   (?)
-   Daniel
-   Software Quality working group?
-   Working on Multi Content Rev Spec with Brion
-   T113034 [RFC: Overhaul Interwiki map, unify with Sites and
WikiMap][T113034 RFC: Overhaul Interwiki map, unify with Sites
and WikiMap]: (Update?)
-   Gabriel
-   T39902 [RFC: Implement rendering of redlinks as
post-processor][]: Solutions for highlighting links to
non-existing pages in Parsoid HTML. Plan in place / agreed
between Parsing and Services. Implementation in change
propagation service ready, preparing for deploy possibly next
week.
-   T122942 [RFC: Support language variants in the REST API][]:
Waiting for progress on more general question of language
selection granularity / strategy & T114662.
-   Roan
-   T108655 [RFC: Standardise JavaScript interfaces][]: I need to
start the second part, but the recent comments have me confused.
I'll need to talk to Timo and figure out what the subject of
part two should be.
-   RobLa
-   Created [RFCstatus][] page.
-   Still need to schedule an RFC triage meeting outside of
ArchCom-RFC time
-   Tim
-   T11 [RFC: Introduce notion of DOM scopes in wikitext][]:
(Update?)
-   Timo
-   No update

# No activity in the last two weeks

-   T18691 [RFC: Section headings should have a clickable anchor][]
(Timo)
-   T111588 [RFC: API-driven web front-end][] (Timo)
-   T123753 [Establish retrospective reports for Security and
Performance incidents][] (RobLa)
-   T122825 [Service ownership and minimum maintenance requirements][]
(Gabriel)
-   T105766 [RFC: Dependency graph storage][] (Gabriel)
-   T124504 [Transition WikiDev '16 working areas into working groups][]
(RobLa)
-   T66214 [Use content hash based image / thumb URLs & define an
official thumb API][] (Brion)
-   T91162 [RFC: Shadow namespaces][] (Brion)
-   T128351 [RFC: Notifications in core][] (Brion)
-   T122825 [Service ownership and minimum maintenance requirements][]
(Gabriel)
-   T54807 [Identify and remove legacy preferences from MediaWiki
core][] (no shepherd)
-   T88596 [Improving extension management][] (Daniel)

# Useful Phab links

-   [Query for shepherd assignments][]
-   [Query for all ArchCom RFCs][]
-   [ArchCom-RfCs board][]

  [Phab:E170]: https://phabricator.wikimedia.org/E170 "phab:E170"
  [Architecture committee/2016-05-11]:
https://www.mediawiki.org/wiki/Architecture_committee/2016-05-11
"Architecture committee/2016-05-11"
  [Phab:E171]: https://phabricator.wikimedia.org/E171 "phab:E171"
  [T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap]:
https://phabricator.wikimedia.org/T113034
"phab:T113034"
  [Phab:E183]: https://phabricator.wikimedia.org/E183 "phab:E183"
  [Architecture committee/2016-05-18]:
https://www.mediawiki.org/wiki/Architecture_committee/2016-05-18
"Architecture committee/2016-05-18"
  [Phab:E184]: https://phabricator.wikimedia.org/E184 "phab:E184"
  [T102476: RFC: Requirements for change propagation]:
https://phabricator.wikimedia.org/T102476
"phab:T102476"
  [ArchCom-RfCs board]: https://phabricator.wikimedia.org/project/board/52/
"phab:project/board/52/"
  [T120164 RFC: Institute "last call" period]:
https://phabricator.wikimedia.org/T120164
"phab:T120164"
  [ArchCom RFC board]: https://phabricator.wikimedia.org/tag/archcom-rfc/
"phab:tag/archcom-rfc/"
  [RFC: Implement rendering of redlinks as post-processor]:
https://phabricator.wikimedia.org/T39902
"phab:T39902"
  [RFC: Support language variants in the REST API]:
https://phabricator.wikimedia.org/T122942
"phab:T122942"
  [RFC: Standardise JavaScript interfaces]:

Re: [Wikitech-l] [Mediawiki-i18n] Providing the effective language of messages

[Rob Lanphier]

Hi everyone,

Niklas brought this message[1] to my attention as something that
probably deserves more attention than it has gotten, and I trust he's
correct.  What he said back in April: "I added
wikitech-l to CC in hopes that people who have worked on localisation
cache more recently would comment on whether [Adrian's proposed option
to not merge
messages in LocalisationCache] would make more sense nowadays."

Adrian: assuming Niklas and I are correct, my suggestion for moving
this forward would be to turn your design thoughts into an
ArchCom-RFC[2] for more explicit consideration by ArchCom.  My attempt
at abstract for those who haven't followed this:

Adrian was trying to figure out how to output pages that need to have
multiple languages in a single page, which becomes difficult when
fallbacks are missing.  It results in some oddball behavior where
placeholder text is output with incorrect i18n attributes in the
surrounding div.  He provided several alternatives for how to solve
the problem in his mail to mediawiki-i18n.  Niklas replied, providing
the "if we stick with the status quo" answer (tag message strings in
LocalisationCache with the correct language), and then is trying to
figure out if the status quo makes the right space vs speed tradeoff
given the quantity of languages and messages we have in 2016.

Adrian & Niklas: did I get the gist of it?

Rob

[1]: The April 2016 mediawiki-i18n thread: "Providing the effective
language of messages"
 

[2]: My unofficial guide on how to turn something into an ArchCom-RFC:


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom-RFC status update: 2016-05-04

[Rob Lanphier]

Hi everyone,

I've included the ArchCom-RFC status update in this mail below, which now
has a dedicated wiki page:


Assuming we build the habit, this should be updated weekly.

Rob


Recent RFC office hours

-   2016-05-04: Phab:E169
-   T130528: RFC: PSR-6 Cache interface in Mediawiki core
-   Declined. A lot of the discussion was about these three
questions:
1.  what problem was this RFC trying to solve?
2.  if BagOStuff is an obstacle, then which is true?
-   a) need a better caching abstraction than BagOStuff?
or
-   b) does BagOStuff just need incremental improvement
-   c) should BagOStuff be deprecated, and not replaced
with anything?

3.  if we decide to rethink our caching model, do we need
tagged caching?

Upcoming RFC office hours

-   2016-05-11: Phab:E66/34(E171)
-   T113034: RFC: Overhaul Interwiki map, unify with Sites and
WikiMap

-   The ArchCom-RfCs board has a "Ready for RFC meeting" column which
should contain an ordered queue of RFCs planned for IRC office hour

Entering Final Comment Period

-   Phab:T120164 - this is a last call for a process RFC about last
calls. See RobLa's email to wikitech-l on 2016-05-04 about this.

RFC inbox

-   ArchCom RFC board:
-   empty on 2016-05-04

Shepherd status

-   Brion
-   (?)
-   Daniel
-   Software Quality working group?
-   Working on Multi Content Rev Spec with Brion
-   Gabriel
-   T39902 RFC: Implement rendering of redlinks as post-processor
(Gabriel): Solutions for highlighting links to non-existing
pages in Parsoid HTML. Plan in place / agreed between Parsing
and Services. Implementation in change propagation service
ready, preparing for deploy possibly next week.
-   T122942 RFC: Support language variants in the REST API
(Gabriel): Waiting for progress on more general question of
language selection granularity / strategy & T114662.
-   Roan
-   I need to start the second part of T108655, but the recent
comments have me confused. I'll need to talk to Timo and figure
out what the subject of part two should be.
-   RobLa
-   Created mw:RFCstatus
-   still need to schedule an RFC triage meeting outside of
ArchCom-RFC time
-   Tim
-   No update
-   Timo
-   No update

No activity in the last two weeks

-   T123753 Establish retrospective reports for Security and Performance
incidents (RobLa)
-   T122825 Service ownership and minimum maintenance requirements
(Gabriel)
-   T124504 Transition WikiDev '16 working areas into working groups
(RobLa)
-   T66214 Use content hash based image / thumb URLs & define an
official thumb API (Brion)
-   T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap
(Daniel)
-   T128351 RFC: Notifications in core (Brion)
-   T122825 Service ownership and minimum maintenance requirements
(Gabriel)
-   T54807: Identify and remove legacy preferences from MediaWiki core
(no shepherd)
-   T88596 Improving extension management (Daniel)
-   T11 RFC: Introduce notion of DOM scopes in wikitext (Tim)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Last call: on the idea of "last call"

[Rob Lanphier]

Hi folks,

One thing we've implicitly adopted is "last calls" for ArchCom-RFCs.
I filed it as an RFC to get it on our workboard:
https://phabricator.wikimedia.org/T120164

However, what that means is that we need to have a last call on the
"last call" RFC.  Obligatory xkcd reference: https://xkcd.com/244/

Barring objection in Phab, we'll consider T120164 approved then.

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Automatic image colorization

[Rob Lanphier]

On Tue, May 3, 2016 at 2:59 PM, Matthew Flaschen
 wrote:
> On 05/03/2016 03:21 PM, Ori Livneh wrote:
>> A forthcoming paper
>>  from
>> researchers at Waseda University of Japan have developed a method for
>> automatic image colorization using deep learning neural network. The
>> results are both impressive and easy to reproduce, as the authors have
>> published
>> their code  to
>> GitHub with a permissive license.
>
> Unfortunately, this is not an open source license, and thus we should not use 
> it.  It uses Creative Commons Attribution-NonCommercial-ShareAlike 4.0.
>
> Creative Commons consistently recommends against any use of CC licenses for 
> software, and this one in particular is not libre or open source because it 
> has a non-commercial restriction.

Hi Ori and Matt,

Matt, I agree that they probably picked an inappropriate license.
However, we shouldn't assume that the people picking the license have
a very sophisticated understanding of licenses.  It might be
worthwhile to ask the authors why they chose CC BY-NC-SA 4.0 instead
of a free license (like MIT, Apache, GPL or AGPL).  If we approach
them respectfully, we might convince them to learn more about our
ideals, and change the license on their software.

Ori, this is a fantastic find!  I haven't created this wiki page yet,
but I think it should exist:


It'd be really awesome if
 contained a pointer
back to this discussion.

That is, of course, that people reading this list agree is
interesting.  Anyone here against colors?  ;-)

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom-RFC status update: 2016-04-27

[Rob Lanphier]

Hi everyone,
Below is the ArchCom-RFC status update for this week.  This is copied from
the notes for the ArchCom Planning Meeting, available at
[[mw:Architecture_committee/2016-04-27]]
.  One
update while I have your attention: on May 4, we plan to discuss T130528:
RFC: PSR-6 Cache interface in Mediawiki core in the public IRC meeting next
week.

We discussed whether we should keep doing these updates in the ArchCom
Planning meeting this week.  I'd like to understand whether people find
these useful.  Feel free to discuss on this list, or (better) in reply to
the on-wiki discussion here: [[mw:Talk:Architecture committee/Team
practices]] 

Rob

RFC status update

   - Query for shepherd assignments
   
   - Query for all ArchCom RFCs
   
   - ArchCom-RfCs board
   

Today's IRC session

   - April 27: Phab:E66/32 
  - T122942: RFC: Support language variants in the REST API
  
  - Who is chairing this one? Tim today

Queue for future RfC office hours

   - May 4: Phab:E66/33 
  - T130528: RFC: PSR-6 Cache interface in Mediawiki core
  
  - Type of meeting: come to consensus.  Daniel is on vacation for the
  May 4 meeting, though, so probably won't attend.

Entering Final Comment Period

Nothing currently slated to go into final comment.
Under discussion

   - The inbox
  - T133462  standardize a
  way to make JS components be able to use different loaders
  - T133388  How to update
  JavaScript components
   - Around the table check-in with each of the ArchCom members
  - Absent: Brion, Roan, Timo
  - Daniel
 - Software Quality working group?
 - Working on Multi Content Rev Spec with Brion
  - Gabriel
 - T39902 RFC: Implement rendering of redlinks as post-processor
  (Gabriel): Solutions
 for highlighting links to non-existing pages in Parsoid HTML.
Plan in place
 / agreed between Parsing and Services. Implementation in
change propagation
 service under way.
 - T122942 RFC: Support language variants in the REST API
  (Gabriel): Scheduled
 for office hour today.
 - T122825 Service ownership and minimum maintenance requirements
  (Gabriel): Related
 mail discussion about OCG in the last days, exploring options
for the way
 forward.
  - RobLa
 - ACTION (RobLa): clearer meeting agenda next week  :-)
 - ACTION (RobLa): schedule an RFC triage meeting outside of
 ArchCom-RFC time
  - Tim
 - No update this week
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Rob Lanphier appointed to the Architecture Committee

[Rob Lanphier]

On Mon, Apr 25, 2016 at 10:32 PM, Tim Starling <tstarl...@wikimedia.org>
wrote:

> At the previous meeting of the MediaWiki Architecture Committee
> (April 20), the members present approved the appointment of Rob Lanphier
> to the committee.
>

Thank you, Tim and the rest of ArchCom!  I'll endeavor not to conduct our
meetings _too_ drunk on power, and keep my maniacal laughter to a minimum
 ;-)

Seriously though, I look forward to weekly conversations and other
collaboration with such a bright bunch of people with such amazing
accomplishments.  Group leadership on a complex set of projects like this
is incredibly difficult; doing that while still keeping a website of this
size up-and-running, using code (including many extensions and lots of
editor-contributed Lua) is a formidable task.  It's wonderful to be part of
building our software the same way our editors create the Wikimedia family
of projects, rather than resorting to the "benevolent dictator for life"
model.  I'm honored to receive the opportunity to make our decision making
process clearer for everyone who wants to contribute.

Rob
(who now feels the weight of responsibility, now that he can't use his old
disclaimer "I'm not a member of the committee")
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom RFC update #6

[Rob Lanphier]

Hi everyone,

Here is the RFC status update from last week's ArchCom meeting (E165).
This is pretty much what is posted on-wiki [1], where everything has
links.

Rob



 Today's IRC session 
** April 20 [[Phab:E66/31]]
*** T91162: RFC: Shadow namespaces

 Queue for future RfC office hours 
** April 27: [[Phab:E66/32]]
*** T122942: RFC: Support language variants in the REST API
** May 4: [[Phab:E66/33]]
*** T130528: RFC: PSR-6 Cache interface in Mediawiki core

 Under discussion 
:Daniel: [[Phab:T124752]]
::Let’s turn the “Changes Tags” refactoring proposed by
[https://gerrit.wikimedia.org/r/#/q/owner:cenarium.sysop%2540gmail.com+status:open,n,z
Cenarium] into an RFC and get it unstuck. Chain of patches starts at
https://gerrit.wikimedia.org/r/#/c/201905/64; The patch refers to
[[Phab:T91535]] but the topic is broader than that, and the ticket
doesn’t fully describe the proposed solution. Needs work.
: Tim: shepherding two for Parser. will pick another
: Roan: [[Phab:T108655]] still need to split it so discussion can take
place on part 2

 Other status 
The "RFC inbox" was empty, nothing "Entering Final Comment Period",
and we didn't discuss the "no activity" list

[1] 
https://www.mediawiki.org/wiki/Architecture_committee/2016-04-20#RFC_status_update

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Improving Wikimedia's Code Review process

[Rob Lanphier]

On Wed, Mar 16, 2016 at 3:47 PM, Jon Robson  wrote:

> We have two swat windows every day. It's magical... I post a request for a
> deploy on a Wiki page and someone deploys it.
>
> Could we try a similar thing with code review. Code review window (maximum
> 1 patch per person) and have a group of +2ers look at a maximum set of
> patches?
>

Hi Jon,

The SWAT comparison is a nice one!  Could you drop a comment on T128371
 (Code Review office hours) to
that effect?

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC meeting (E147): Notifications in core & define an official thumb API

[Rob Lanphier]

Hi everyone,

We plan to discuss two RFCs at the 2016-03-09 RFC Meeting (22:00 UTC on
Wednesday):

   - T128351  RfC: Notifications
   in core
  - @brion  is shepherding,
  and would like to confirm rough consensus for moving some of the
Echo code
  into core
  - T66214 : Use content hash
   based image / thumb URLs & define an official thumb API
  - Based on the 2016-03-02 ArchCom meeting
  
  and what he said in T66214#2087161
  , I believe @GWicke
   hopes we can reach
  consensus on the format of a thumb API, possibly putting that aspect into
  last call.

Details about the meeting are in Phabricator:
https://phabricator.wikimedia.org/E147

Hope to see y'all there!

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ArchCom RFC triage on Wednesday 2016-03-02?

[Rob Lanphier]

Hi folks,

An ArchCom RFC triage (per
) was penciled in for this
past RFC meeting (), but I was
out for jury duty and wasn't able to make the push for this or
facilitate it if we stuck with my hasty plan. I'm done now, and would
be happy to accommodate assuming everyone is available and up for
helping out with a triage for this coming meeting on Wednesday
2016-03-02 ()

The point of the triage would be to try to ensure that more RFCs have
assigned shepherds on ArchCom.  That, in turn, would hopefully make it
more likely for an RFC to make it through the process more quickly.
Instead of having to ask all of ArchCom status about a particular RFC,
there would be a single ArchCom owner to check in with.

Any RFC that doesn't have a shepherd is not likely to move through the
process.  There are always going to be several RFCs that don't have
shepherds.  Just submitting an RFC doesn't guarantee that an ArchCom
member will think your RFC is important.  Life is hard that way.  Make
your case!

Note also: shepherd != slave.  Even when an RFC has a shepherd,
there's no guarantee that the RFC is a high priority for the shepherd.
Certainly, the shepherd's credibility as a worthy ArchCom member is
potentially damaged by foot dragging, but don't bank on being able to
dump blame on the shepherd if your RFC isn't going fast enough for
your taste.

Thoughts?

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Using assignees for RFC shepherd

[Rob Lanphier]

On Thu, Feb 4, 2016 at 7:08 AM, MZMcBride  wrote:
>
> I'm still not really sure what [the "shepherd" definition in the
> Governance RFC
> ] means.
> The biggest focus seems to be on speed and throughput for the RFC process
> itself, when the focus should actually be code quality, sustainability, and
> overall architecture.


Are code quality, sustainability, overall architecture, and
speed+throughput for the RFC process mutually exclusive?

I filed T125865: Assign RFCs to ArchCom shepherds
 which I think will be the most
organized place to discuss this further.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Using assignees for RFC shepherd

[Rob Lanphier]

Hi folks,

In the ArchCom meeting earlier today, Daniel, Timo, Tim and I discussed the
way we handle RFC assignments in Phabricator.  Previously, the RFC would
frequently be assigned to person writing the RFC.  As we try out the Rust
model (per T123606 ), and as we
try to increase the speed by which RFCs move though the process, we thought
it would make sense to also assign RFCs to shepherds on the ArchCom.

We didn't discuss all of the implications of this in the meeting today, but
we think this might help us scale our RFC triage process.  What do you all
think?

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Developer Relations Weekly Summary

[Rob Lanphier]

On Thu, Jan 28, 2016 at 2:57 PM, Pine W  wrote:

> Is there, or will there be, a page somewhere that describes the outcomes of
> the Developer Summit?
>

I would love for the working group chairs to make the outcomes available
from the main WikiDev16 page:


The meeting notes from most of the meetings are there, but please add
anything you feel is missing, and/or ask the chairs of each of the meetings
to document their next steps.  I have this on my TODO list to continue
following up with various working group chairs (and helping with this), but
I also have been busy with other work, so I don't fault them at all for not
getting to it.

Pine, could you describe what you hope to get out of the information?

Thanks
Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Rob Lanphier]

On Wed, Jan 27, 2016 at 10:51 PM, Ori Livneh  wrote:

> Ok, understood. Keeping it around costs little. Dan, in case you were
> volunteering, please go ahead and document the purpose of test2 on its main
> page and/or wikitech -- I think it is a good idea.
>
> If it is cheap to keep it, why did I even bother asking? I'm glad you
> asked!
>
> As the Wikimedia software stack evolves, some of its components become
> vestigial. Their existence makes it harder for anyone to form a systematic
> understanding of the whole, because they don't have any clear functional
> relationships with others components. And since they're not on anybody's
> mind, they have a tendency to become "gotchas" for future upgrades and
> migrations. So it's good to get rid of them, even if the resource costs are
> small.


Hi Ori,

Thanks for bringing this seemingly vestigial weirdness to our attention.
As you say, it should be documented better.

As I'm reading this, you are still making the case that we should still
shut this down.  Given the amount of mailing list traffic this has
generated, not everyone agrees.  Rather than continuing this conversation
on wikitech-l, could you file a Phab task for this (e.g. "Decommission
test2.wikipedia.org"), and direct the conversation there?  That will help
people who care about this topic not only have a more focused audience for
their comments, but will also give us a good way of tracking all of the
things Phab tasks typically track (e.g. owner, priority, dependencies,
resolution)

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

Thanks for articulating this very clearly Faidon!  More inline...

On Thu, Jan 28, 2016 at 3:11 AM, Faidon Liambotis <fai...@wikimedia.org>
wrote:

> On Fri, Jan 22, 2016 at 02:30:22PM -0800, Rob Lanphier wrote:
> > Ultimately, WMF TechOps has correctly blocked a lot of software making it
> > to the Wikimedia cluster that hasn't been through the RFC process, even
> > though they themselves weren't entirely clear about the scope.  Wikimedia
> > Foundation leadership has an (unfortunately) long history of being
> unclear
> > about the scope.  I share the blame for this.  This is my attempt to
> > clarify.
>
> This is true, although the word "blocked" is perhaps a bit strong.
>
> We generally prefer large architectural changes to be discussed with a
> wider group across the movement, than just us and the person or team
> that proposed them. [ArchCom seems to be more diverse than Ops, and

probably better than leaving it up to Ops to keep organic growth under
> control]
> That said, there have been important deployments that have bypassed the
> RfC process entirely (including proposals that resulted into staffed WMF
> teams) and others that did go via the RfC process, but the resulting
> feedback wasn't incorporated into the final design (for various
> reasons).
>

I definitely appreciate it when Ops has been a firm stakeholder in this
process.  Mark unofficially dropped out of ArchCom back in August, which I
only recently acknowledged on the ArchCom page
<https://www.mediawiki.org/wiki/Architecture_committee> (sorry!)  The
remaining ArchCom members have been very good at ensuring that Ops' voice
is reflected in the decisions (e.g. the schema change update to the development
policy <https://www.mediawiki.org/wiki/Development_policy>)

It seems reasonable for y'all to object to deployments of code for which
consensus isn't clear.  We shouldn't expect you to be the police, and you
need to be careful about maintaining the trust and goodwill of the broader
community (and not seen as an obstacle to progress), but when you see
 that doesn't look right, a polite note to wikitech-l saying
"I'm confused about " would be greatly appreciated.

It's also worth noting that the opposite has happened as well: TechOps
> has blocked the production deployment of features that the MediaWiki
> ArchComm has approved. The fact that an optional feature is considered
> good enough for the MediaWiki architecture does not mean that it's
> appropriate for Wikimedia's complex and demanding production environment
> -- or for being worked on by the Wikimedia Foundation, for that matter.
>

This is a failure of process we should address.  ArchCom shouldn't approve
things that don't make sense for our environment.

That said, we want Wikimedia software to improve quickly.  We should aspire
to incorporate the best elements of the "bold, revert, discuss
<https://meta.wikimedia.org/wiki/Bold,_revert,_discuss>" consensus-building
process that serves many of our projects well.  We should endeavor to take
acceptable risks for things that are easily reversible, and only challenge
those risks where the consequences of failure aren't clearly understood
and/or disproportionately fall on the wrong people.

This is especially true given that ArchComm really has absolutely no say
> in resourcing and a given feature may not have secured funding (people,
> hardware etc.)
>

Awwwyou're mail was so great, and then you ended with this!  Are you
saying that the only real power in this world belongs to people with
control of the money?

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

On Thu, Jan 28, 2016 at 11:21 AM, Greg Grossmeier <g...@wikimedia.org>
wrote:

> 
> > On 28 January 2016 at 18:53, Rob Lanphier <ro...@wikimedia.org> wrote:
> >
> > > This is especially true given that ArchComm really has absolutely no
> say
> > > > in resourcing and a given feature may not have secured funding
> (people,
> > > > hardware etc.)
> > > >
> > >
> > > Awwwyou're mail was so great, and then you ended with this!  Are
> you
> > > saying that the only real power in this world belongs to people with
> > > control of the money?
> >
> >
> > He wouldn't be the only one who thinks this. I've seen other people with
> > similar concerns about whether ArbComm is really in control or whether
> WMF
> > management is, because it's WMF management that actually gets to decide
> > what the paid Wikimedia developers (probably the majority of active
> > developers at this point) work on. I'm inclined to agree with them.
>
> This is similar to the concern/line of reasoning that lead to all of the
> questions about whether or not "WMF senior leadership" will be in active
> attendance at the Dev Summit.
>

Also, Wes Moran gave the keynote, and didn't say anything to contradict
what I said in my email.  Is there something I missed there?

Generally speaking, the position WMF executive management has taken in the
conversations that I've had is that WMF needs to do a better job listening
to the community.  Saying that ArchCom has "no say" basically is taking a
needlessly fatalistic stance of a mindless wage slave.  I know y'all well
enough to know that everyone on this thread is intensely mission-driven,
and "mindless" is about as far from a truthful description anyone could
give.

ArchCom strives to define what we should do, based on listening to the
community and using our collective expertise to craft a vision based on
what we learn.  What "WMF senior leadership" (pls define) does with that
information is probably not in scope for this mailing list.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

On Mon, Jan 25, 2016 at 9:59 AM, Matthew Flaschen <mflasc...@wikimedia.org>
wrote:

> On 01/22/2016 05:03 PM, Rob Lanphier wrote:
>>
>> The reason I want the rename [in T124255
>> <https://phabricator.wikimedia.org/T124255>]:  ArchCom is the mechanism
>> we hope to ensure
>
> we build and deploy increasingly excellent software on the Wikimedia
>> production cluster in a consensus-oriented manner.  MediaWiki is at the
>> center of this, but ArchCom's responsibility doesn't end with MediaWiki.
>>
>
> In my opinion, there needs to be a group leading development of MediaWiki
> itself, focusing on the product and the product roadmap (influenced by who
> uses it).  WMF is a critically important user of MW, but not the only one.
>  [...] I would suggest we might want them to be separate groups.  The group
> in charge of MW's roadmap would not have to care about things like major
> operations/puppet restructuring, while the WMF cluster group would.


> (Note, this is related to the discussions about MediaWiki Foundation, but
> doesn't need to wait on that).
>

Logically, I think your long-term vision makes sense.  Managing the
software we deploy to the WIkimedia cluster is a lot of work, and it
deserves focus.

In the short-term, I believe a non-Wikimedia focused subgroup of ArchCom
may make sense.  The declining MediaWiki use outside of Wikimedia has been
a longstanding problem for us, but not the biggest problem.  ArchCom's
focus is (and should continue to be) the needs of Wikimedia.

The reason why I'm delineating it as a subgroup is not a power grab, but an
essential step toward building the trust required for long term viability
of a MediaWiki(?) Foundation to be viable.  The fact that the people
working on the "MediaWiki Foundation" are still(!) using the name
"MediaWiki" represents a failure of imagination among all of us.  For
example, if MW Stake wants to be a viable upstream, there has to be a
stake/steak pun buried in there somewhere that could represent a great name
for a viable fork of MediaWiki.

Yes, I used the word "fork".  I believe Wikimedia Foundation would love it
if MediaWiki forked, and we were "forced" to switch to the fork.  There are
other projects (e.g. gcc, KHTML/WebKit, Inkscape) that were helped by a
fork.  WMF wouldn't be offended at all by an attempt to create a viable
fork, as we know that there is a limit to how much we work we should try to
fund off of our current donation model.  If we should be pressuring anyone
to make non-Wikimedia use of MediaWiki viable, it shouldn't be WMF, someone
from Wikia should step up. :-P

As it stands, Wikimedia Foundation is the only trusted upstream for the
MediaWiki codebase.  I believe WMF should jealously guard the "MediaWiki"
trademark, if for no other reason than to force someone to come up with a
different name.  "MediaWiki" and "Wikimedia" are too similar, and there are
not good reasons for us to license that trademark to anyone else.  WMF
doesn't have a patent on the alphabet; come up with your own damn name  ;-)

Naming isn't the only issue for a viable fork, though.  There are other
things that a viable fork would need for WMF to trust it:

   - An upstream repository. This could be anywhere (even Github!).  We
   would need to be able to trust that upstream would collaborate with us to
   solve our dealbreakers.
   - Trusted architects with clear vision and leadership
   - A governance structure that allows WMF to operate as a worthy peer

We have healthy relationships with other upstreams (e.g. Phabricator,
Debian, Composer), and though we don't always agree with the choices of our
upstream, we strive to collaborate with respect, and we figure out what to
do if upstream makes a choice that creates a problem for us.

So: forks welcome!  Any takers?

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Scope of ArchCom

[Rob Lanphier]

Hi everyone,

Those with a keen eye will notice that I filed T124255
, which calls for renaming
#MediaWIki-RfCs in Phab to "#ArchCom-RfC".  This would be a boring Phab
administrivia email if it was simply that.

The reason I want the rename:  ArchCom is the mechanism we hope to ensure
we build and deploy increasingly excellent software on the Wikimedia
production cluster in a consensus-oriented manner.  MediaWiki is at the
center of this, but ArchCom's responsibility doesn't end with MediaWiki.

T124255  is an odd place to have
a more sweeping conversation about the scope of ArchCom, but it'll do for
now.  Feel free to comment there or on this mailing list.

Thanks
Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

 On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk  wrote:

> To clarify - are you saying this ([deploying increasingly excellent
> software on the Wikimedia production cluster in a consensus-oriented
> manner]) is the actual current scope of ArchCom, or are you advocating for
> a change in scope?


It's my attempt to clarify the scope, but you could argue it's a change.

Ultimately, WMF TechOps has correctly blocked a lot of software making it
to the Wikimedia cluster that hasn't been through the RFC process, even
though they themselves weren't entirely clear about the scope.  Wikimedia
Foundation leadership has an (unfortunately) long history of being unclear
about the scope.  I share the blame for this.  This is my attempt to
clarify.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Last call on RFC: drop PHP 5.3/5.4 support

[Rob Lanphier]

On Thu, Jan 21, 2016 at 8:12 PM, Tim Starling  wrote:
> This is a last call for new arguments and facts related to the
> proposal to drop PHP 5.3 and PHP 5.4 support in MediaWiki core git master.
>
> If you have anything new to say about this issue, please comment on
> the Phabricator ticket:
>
> https://phabricator.wikimedia.org/T118932
>
> The Architecture Committee plans on making a decision on this issue on
> the basis of the Phabricator comments in next week's committee meeting
> (January 27).

Clarifying this:  please make your comments in T118932 now; don't wait
for Wednesday's meeting.  Wednesday will be your opportunity to say
"hey, that commnet I wrote, did you read it?  did you understand it?
it's really important!".  If you're waiting until Wednesday to ambush
us with a stellar new argument that's going to change everyone's mind,
you are doing it wrong.  Make your case *now*.

Meeting URL:


We've dithered on this one long enough.  We really need to end the
uncertainty well before the 1.27 release.

Thanks
Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

On Fri, Jan 22, 2016 at 2:58 PM, C. Scott Ananian 
wrote:
> Perhaps you could elaborate on the "WMF TechOps" aspect a bit, either here
> in email or on the Phab ticket.  It seems that some of the tasks currently
> tagged as "RfCs" are actually not ArchCom RfCs (they are
> WikiData-related?).  From your description above, it seems there may also
> be some not-quite-ArchCom RfCs related to what software gets deployed on
> our cluster.

My "WMF TechOps" term was a slightly inaccurate way of describing the "Ops"
column in this table:


A relevant part to quote: "The Wikimedia Foundation
 legally controls the
servers; ultimately the Wikimedia Foundation Board of Trustees
 is responsible for
determining who has *sysadmin* access, and how that responsibility is
exercised. However, this power is delegated to various Wikimedia Foundation
managers . On a
day-to-day basis, various system administrators with root or shell access
manage the server clusters."

> Perhaps we should try to come up with more fine-grained labels for RfCs,
> rather than labelling them all "ArchCom RfCs"?   I think there was some
> discussion at the dev summit about trying to associate proposals with the
> dev summit "working groups", as a way of communicating a broad agenda for
> each ArchCom meeting.  Finer-grained RfC labeling might be part and parcel
> of this.

I would like one board to monitor for what is actually about to be
approved.  Per T123606 , I would
*love* for working groups to assume a lot of the earlier drafting/workflow
aspects of things, and Phab labels for that would be great.  I think we
need to agree on the working groups we want (see T124504
) before we start on the
administrative detail of what tags we want.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Meeting scribes for WMF meetings

[Rob Lanphier]

Hi folks,

One thing we'd love to get better at is taking and publishing useful
notes from our meetings.  An example of that is ArchCom meetings, for
which we have been taking notes for a while, but I haven't gotten
around to publishing.  Another example is our weekly tech Engineering
Tech managers meetings, which are increasing in importance as we head
into budget setting season.

Is there anyone available to be a volunteer scribe for ArchCom and/or
Tech/Eng management meetings?  For logistical reasons, I would prefer
existing WMF employee offers over non-WMF offers, but beggars can't be
choosers ;-)

The next meeting opportunity is in 15 hours: the ArchCom is having
it's weekly 1pm PST (21:00 UTC) meeting just prior to the 2pm PST
public IRC meeting.  If you're interested, please let me know!  The
best way to express your volunteer interest is by adding your sig on
the bottom of this page:


...and discussion is welcomed on the associated talk page.

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Governance model for Wikimedia software development (e.g. MediaWiki)

[Rob Lanphier]

Hi folks,

Over the past few weeks (including WikiDev '16) we've had several
conversations the Wikimedia software development governance model.
For a lot of people, the most important aspect of this is MediaWiki.
More generally, though, the scope is about we deploy to Wikimedia
sites that we intend to maintain, enhance, and further leverage.

On Wednesday, January 20, we intend to continue this conversation, and
welcome your participation:


In particular, we plan to discuss the work that Gabriel Wicke started:

"WIP RFC: Improving and scaling our technical decision making process"

...which is mainly a pointer to:


I've quoted the current text as of this writing below, and you're
welcome to reply on list or on the talk page (though let's try to
ensure a summary of important comments gets captured on T123606).

Based on the conversations I've been part of (and Gabriel's initial
writeup), Rust's governance model seems to be the leading candidate to
iterate toward.  This doesn't necessarily mean making one big change
with a fanfare-laden launch, but let's discuss.

Wait until Wednesday's IRC session if you have to (22:00 UTC, 14:00
PST), but we'd love to hear your thoughts sooner.

Rob
p.s. Here's the link to the RFC


...and below is the plain text from [mw:Requests for comment/Governance].


Problem statement

[Goal: Describe the problem we are seeing with the current process,
and why it is important to solve them.]

Difficulty of making clear and accepted decisions on important and
broad topics.
Scaling the decision making process.
Stakeholder involvement & legitimacy.
Clarity and transparency of decision making process.

Prior art

[Goal: Give a brief summary and pointers to options we looked at.]

IETF process
Python PEP process
Rust
Debian
W3C

See also this prior etherpad discussion.
Strawman proposal

[Goal: Summarize key ideas that we consider worth adopting, and point
to prior art. Provide rationale by explaining how each addresses
specific issues.]
More structured RFC decision process

Based on the Rust decision making process.

Nominate a shepherd from a (sub)team to guide an RFC through the process.
Makes sure that stakeholders are informed.
Guides the discussion.
Once the discussion plateaus or stalls & in coordination with
the RFC author(s), announces and widely publicizes a "Final Comment
Period", which is one week.
At the end of the "Final Comment Period", the (sub)team decides
based on the points made in the RFC discussion, and justifies its
decision based on the overall project principles and priorities. If
any new facts or aspects are surfaced in this discussion, a new Final
Comment Period needs to be started before making a decision.

Scaling the decision making process with sub-teams

Based on Rust subteams.

The core team is responsible for creating sub-teams, with a member
of the core team as its team leader. Initial membership is determined
by the leader, later changes are by consensus within the team.
Each sub-team has a specific vision and problem set to work on,
and the team leader is responsible for keeping the team on topic.
Sub-teams are empowered to decide on RFCs within their scope. The
team leader is responsible for elevating RFCs with unclear or broader
scope to the core team.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] WikiDev '16 summary

[Rob Lanphier]

Hi everyone,

As many of you know (because you were here), we had the Wikimedia
Developer Summit 2016 last week.  It was wonderful to see so many of
you!  Rachel Farrand and Quim Gil ensured we had an excellent venue
and had a wonderful opportunity to work together, and the people here
had some great conversations.  Valerie Aurora taught us a lot about
how to run effective meetings, which greatly increased the quality of
the discussions.

The conversations we started here are just that: a start.  We covered
a lot of very important topics.  Given the time and expense of
bringing everyone to one place, it would be a shame if the
conversations we started ended up needing to start over.  Hence, it
was really important to have good notes, to make it easier to pick up
these conversations where we left off.

For many of the sessions, the notes made their way into the Phab task
associated with the meeting. The main WikiDev '16 landing page makes
it a bit easier to find the notes:


The session leaders were very motivated to make sure we got something
out of the conversations they led, so they will be clarifying the next
steps on their respective sessions.  It's certainly easier than it was
this time last week to find out what happened in each respective
session, but there's a lot of work to do. Please help us out!

Rachel sent out a survey to all of you who attended.  Please fill this
out!  It will help us figure out if we'd like to have another one like
this next year.

If you're interested in real time conversation about WikiDev '16,
either because you were there and want to follow up or you weren't
there and you want to learn what you missed, please attend the RFC
office hour in a few hours (Wednesday 22:00 UTC, 14:00 PST):


Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] WikiDev '16 summary

[Rob Lanphier]

Hi everyone,

As many of you know (because you were here), we had the Wikimedia
Developer Summit 2016 last week.  It was wonderful to see so many of
you!  Rachel Farrand and Quim Gil ensured we had an excellent venue
and had a wonderful opportunity to work together, and the people here
had some great conversations.  Valerie Aurora taught us a lot about
how to run effective meetings, which greatly increased the quality of
the discussions.

The conversations we started here are just that: a start.  We covered
a lot of very important topics.  Given the time and expense of
bringing everyone to one place, it would be a shame if the
conversations we started ended up needing to start over.  Hence, it
was really important to have good notes, to make it easier to pick up
these conversations where we left off.

For many of the sessions, the notes made their way into the Phab task
associated with the meeting. The main WikiDev '16 landing page makes
it a bit easier to find the notes:


The session leaders were very motivated to make sure we got something
out of the conversations they led, so they will be clarifying the next
steps on their respective sessions.  It's certainly easier than it was
this time last week to find out what happened in each respective
session, but there's a lot of work to do. Please help us out!

Rachel sent out a survey to all of you who attended.  Please fill this
out!  It will help us figure out if we'd like to have another one like
this next year.

If you're interested in real time conversation about WikiDev '16,
either because you were there and want to follow up or you weren't
there and you want to learn what you missed, please attend the RFC
office hour in a few hours (Wednesday 22:00 UTC, 14:00 PST):


Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Community Wishlist Survey: Top 10 wishes!

[Rob Lanphier]

On Fri, Jan 8, 2016 at 11:07 AM, Bill Morrisson
 wrote:
> I wish to ask if volunteer developers can participate in one of the top 10
> wishes of the community wishlist or can only start working on those wishes
> that are at the rest of the list or if volunteer developers need a
> particular permission for that.

As Danny said, this is a wonderful thing to point out, and his answer
way more authoritative than mine.  Thinking back to my early MediaWiki
contribution experience, I would have loved to have had a ranked list
of "these are things that are really important" so that I knew my
contribution would ultimately be appreciated and important to the
project.

Are you asking on behalf of a specific potential contributor (e.g.
yourself) or are you making a more general request that we don't
accidentally cookie lick[1] the ideas on this list?

Rob
[1]  Cookie licking: metaphorically taking a cookie, licking it and
putting it back on the cookie tray without eating it (essentially
preventing anyone else from having it)
http://communitymgt.wikia.com/wiki/Cookie_Licking

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Making our software simple and effective

[Rob Lanphier]

Hi folks,

One thing we're trying to do as we schedule WikiDev '16 is make sure
that sessions are solving for one of five problems.  One of the
problems I've been trying to figure out how to articulate I think I've
finally got some wording around, and I'd like your thoughts.

The question: "how do we simultaneously optimize the following
conditions? 1) make software development more logical and obvious for
all Wikimedia contributors, 2) make Wikimedia software more useful and
reliable for the Wikimedia sites"

This is an expression of a balancing tradeoff that I think we've
implicitly made over the years, but I think it's time to make
explicit.  Ideally, new ideas should make both better, but sometimes
we need to sacrifice one to make big gains in the other.  Does that
question capture an important idea?

A lot more detail in Phab here:


Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Agenda bashing on Wednesday AND something to bash!

[Rob Lanphier]

Hi everyone,

Quim and I met earlier, and we agreed to a main room schedule for WikiDev '16:



That maybe is overstating it a bit; we mainly decided on two things:
1.  Each of the working groups/areas defined in T119018 should have a
session in the main room (Robertson 1, which seats 200).  Discussion
of how we should use the focused time in each area should happen in
the working area Phab tasks.
2.  We scheduled a couple of main room sessions

Things we scheduled for the main room:
* Next Generation Content Loading and Routing (Adam Baso and Gabriel Wicke)
* How should Wikimedia software support non-Wikimedia deployments of
its software? (Gilles Dubuc)

We still have many open slots in the schedule to fill, but we now have
a little better idea of what those things will be competing against.
Barring a radical change the discussion or in our planning process
this week, what Quim and I plan to do is start filling in the slots in
the competing rooms (Robertson 2 and Robertson 3) from the must have
list (T119593).  We'll also be prodding the working areas to decide on
their plan for their Robertson 1 time at WikiDev.

Here's the list of working areas, and the current owner assigned to each:
T119022: Content format - Tim Starling
T119029: Content access and APIs - Gabriel Wicke
T119030: Collaboration - Quim Gil
T119032: Software engineering - Daniel Kinzler
T119162: User interface presentation - Volker Eckl

The agenda bashing session is planned for Wednesday, 2015-12-16, 22:00
UTC (2pm PST) on #wikimedia-office, during what is normally our RFC
meeting.

This email is largely a repeat of a couple of comments I made on Phab:


For many people (myself included), it's probably easier to read and
respond on Phab, but replies here are welcome as well.

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Appreciation thread, 2015

[Rob Lanphier]

On Thu, Dec 10, 2015 at 8:33 AM, Vituzzu  wrote:

> *Wikidata developers which turned into solid reality one of the most
> dreamlike ideas of our universe
>

+thousands to this.

If I started on the full list of stuff I should say "thanks" for, I might
never get around to hitting send.  I'm ok with Wikidata being the only
thing on the list for now, because it's (still) such a big deal.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Who owns (or should own) OOjs UI?

[Rob Lanphier]

On Thu, Dec 10, 2015 at 5:40 PM, Jon Robson  wrote:
> [OOjs UI ownership] might be a good discussion for the dev summit?

Perhaps.  I'd say the idea in Phab.  It's obviously way past the
scheduled date for submissions[1], but the schedule isn't etched in
stone, and it might make a good unconference session anyway.

Rob
[1]  And, admittedly, we're behind the schedule we planned on for
putting the schedule together.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Ideas for tech-related IdeaLab Campaigns?

[Rob Lanphier]

Hi Chris,

I wonder if we can use Phabricator as an incubator for IdeaLab proposals?
We already have the #possible-tech-projects tag in Phabricator [1], which
seems like a sensible place to discuss the ideas amongst the people who
have ideas in this area.

I know there is some cynicism about the upcoming Wikimedia Developer Summit
in January, because it seems like a great opportunity to talk about what we
want, but then not have a strategy for getting it done.  That seems
justified, since "resourcing" seems a constant refrain in these
conversations.  Would anyone from IdeaLab be available to be at WikiDev
'16, looking out for appropriate opportunities to get from ideas to
IdeaLab(tm) grant proposals?

Rob

[1]  The board: <
https://phabricator.wikimedia.org/tag/possible-tech-projects/> and the
description: 

On Mon, Dec 7, 2015 at 12:54 PM, Chris Schilling 
wrote:

> Hey everyone,
>
> I've recently initiated a consultation to help decide on topics for IdeaLab
> campaigns for the future, and I'm very interested in your input on what
> technical issues, gaps, or general features we could consider focusing our
> attention upon.  These campaigns can generate novel proposals for tools and
> improvements to address needs in the Wikimedia projects to which you
> contribute:
>
> 
>
> You can offer feedback and add your own campaign topics through a survey
> conducted through AllOurIdeas <
> http://www.allourideas.org/idealab_campaigns>
> in addition to participating on the IdeaLab talk page.
>
> I’m looking forward to seeing your feedback and exploring potential
> directions we can take IdeaLab campaigns starting next year.
>
> Take care,
>
> Jethro
>
> --
> Chris "Jethro" Schilling
> I JethroBT (WMF) 
> Community Organizer, Wikimedia Foundation
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Procedural updates to the RFC process (Re: Objections to PHP 5.5 version requirement)

[Rob Lanphier]

On Wed, Dec 2, 2015 at 6:32 PM, Tim Starling  wrote:
> On [T118932], I proposed a process whereby the RFC will be reopened
> for review if any existing Phabricator user will second the motion. If
> you do object, please register your objection on Phabricator.
>
> In the meantime, please do not merge any changes which require PHP 5.4+.

Thanks for your caution here, Tim.  A large merge requiring PHP 5.5
might be messy to unravel.

Per our discussion earlier, I filed T120164 [1] proposing to institute
a "last call" period for MediaWiki RfCs.  As a result of this, we
might not to use RFC meetings as the final decision on approval.

I filed T120164 with a little hesitancy.  I believe that we've made
the RFC process more efficient these past few months, such that it
should be possible to *reverse* an RFC quite simply: write another
RFC.  The more process we layer onto each individual RFC, the harder
it is to use them for nimble decision making.

We also discussed having some sort of minimum discussion time on
wikitech-l prior to having the decision-oriented RFC meeting.  That
seems sensible, with the caveat that we discussed: we should ask that
those proposing RFCs announce their intention on wikitech-l, directing
the conversation toward the Phab ticket associated with the RFC.  The
Phab ticket should be the "discussion of record", whereas wikitech-l
can be "announcement of record" (torturing the "newspaper of record"
metaphor[2])

I think a "last call" period, if done correctly, can be a lightweight
safeguard that can maximize participation and provide for welcome
scrutiny.  Done incorrectly, and it's a new way for stubborn defenders
of the status quo to get everyone the hell off of their lawn.  ;-)

That's one of the things that worries me about making it too easy to
reopening RFCs.  It seems here in the U.S. we were able to repeal the
18th amendment with the 21st amendment.  Even with a process as
complicated as amending the U.S. constitution, the results were
reversible.  Our process (hopefully) isn't that complicated, but let's
avoid making it more complicated by handwringing over the approval
process.

Rob

[1] 
[2] https://en.wikipedia.org/wiki/Newspaper_of_record

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC Meeting on #wikimedia-office IRC channel (T118517)

[Rob Lanphier]

Hi folks,

RFC meeting this week - usual time and place:

   - Location: #wikimedia-office IRC channel
   - Time: 2015-12-02, Wednesday 22:00 UTC (2pm PST
   )
   - Agenda:
  - T118517: [RFC] Use  for media
  

See https://phabricator.wikimedia.org/E93 for more.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC meeting: Minimum PHP version

[Rob Lanphier]

On Sat, Nov 28, 2015 at 1:35 PM, Marcin Cieslak <sa...@saper.info> wrote:
> On 2015-11-24, Rob Lanphier <ro...@wikimedia.org> wrote:
> > [regarding discussion about <https://phabricator.wikimedia.org/T118932>]
> > The main task this week is to plan out what we will define the minimum
> > PHP version to be for MediaWiki 1.27 (the next LTS version).  The
> > viable choices seem to be:
> > *  PHP 5.3 (the status quo) - this version is no longer supported
> > upstream, and doesn't have widespread support even in conservatively
> > updated Linux distros.
> > *  PHP 5.4 - this version is no longer supported by The PHP Group, but
> > is still part of older supported Linux distros (e.g. Debian Wheezy)
> > *  PHP 5.5 - this is the lowest version with reliable LTS support in
>
> In one enterprise environment I am familiar with one is stuck
> with SLES 11.3/11.4 with they own enterprise repository, and the
> newest I've seen was 5.3.something.

As of Wednesday's meeting, PHP 5.5 is the new minimum for MediaWiki
1.27.  The resulting conversation on T118932 shows there is
frustration for how the decision was arrived at.

We need to figure out not only which Linux distros are supported, but
what "support" means and how we accomplish it.  If it turns out that
SLES 11.3 is very widely used, that points for the need for someone to
support that version.

That leaves a few questions:
*  What does "support" mean?  Where does this belong on the continuum
stretching from "continuing to offer security patches" to "require all
master commits to MediaWIki to interoperate with PHP 5.3"?
*  Who should provide support?  Is this something WMF needs to finance and lead?
*  How much analysis is a prerequisite to a PHP version jump?

I believe the conclusion on T118932 is a good one; it's time for us to
move to PHP 5.5 for MediaWiki 1.27+.  That said, we (the larger
community; not just WMF) clarify our LTS strategy, since it's not
entirely clear to me who is committed to supporting MediaWiki 1.23 all
of the way until May 2017.  Furthermore, there seems to be some
skepticism as to whether 1.27 should even be offered as the next "LTS"
version of MediaWiki.  Could someone clarify this for me?

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Ending RFC review meetings a little early

[Rob Lanphier]

Hi folks,

One idea that achieved consensus here at WMF, but was never discussed
publicly (that I'm aware of) is the idea that meetings should use the
Google Calendar speedy meeting option.[1]

Since we didn't have a public discussion of this, it's technically not
the standard for RFC review meetings.  However, this led to the
natural question "why not?"

Sowhy not?  Is there any opposition to us ending RFC meetings 5-10
minutes early?

Rob

[1]  http://getsolid.io/blog/enabling-speedy-meetings-google-calendar/

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC meeting: Minimum PHP version

[Rob Lanphier]

Hi folks,

This week's RFC review meeting is scheduled for Wednesday, November 25
at 2pm PST (22:00 UTC).  Event particulars can be found at


The main task this week is to plan out what we will define the minimum
PHP version to be for MediaWiki 1.27 (the next LTS version).  The
viable choices seem to be:
*  PHP 5.3 (the status quo) - this version is no longer supported
upstream, and doesn't have widespread support even in conservatively
updated Linux distros.
*  PHP 5.4 - this version is no longer supported by The PHP Group, but
is still part of older supported Linux distros (e.g. Debian Wheezy)
*  PHP 5.5 - this is the lowest version with reliable LTS support in
major Linux distros

The RFC additionally stipulates some coding standards, since even
though it upgrading our version of PHP would make use of some features
possible, that doesn't automatically make their use a good idea.  The
author broke up the feature set into "encouraged", "tolerated" and
"verboten".  Please read the RFC directly for more info on this:


Please comment on T118932 if you have further thoughts to share and/or
please attend the meeting on Wednesday.

Thanks
Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] WikiDev '16 working areas

[Rob Lanphier]

Hi everyone,

I mopped up a bunch of Brion's time and expertise earlier this week,
did some futzing, discussed it a little with ArchCom, and and came up
with a set of working areas that are reflected on Phab[1] and on
mediawiki.org[2]

Here's the list that's posted in Phab:
-   Content format [T119022] -
This is about the format of our data, with a primary emphasis on the
future of Wikitext & markup (or possibly, the future of eliminating
it). The central problem in this area: "how do we make manipulating
our data easier and more useful" (both for humans and computers)

-   Content access and APIs [T119029]
this is about getting our data in-and-out of the system (e.g.
rest.wikimedia.org). The central problem in this area: "how do we
make accessing and distributing our data easier and more useful?"

-   Collaboration [T119030]
this is about how we work together. Central problem: "how do we
scale editing our code up to populations similar to editing our
projects, proportionally increasing our positive impact and
productivity?"

-   Software engineering [T119032]
this is about building and delivering high quality code. Central
problem: "how do we build high-quality software that we can
dramatically increase the number of people that can understand it
while increasing the reliability and maintainability of Wikimedia
sites?"

-   User interface presentation [T119162]
improving our user interactions. Central problem: "how to we make
our software look and feel joyful to use?"

We have some initial nominees (mostly from ArchCom) to lead up the
selection process, but really, now is the time to demonstrate a
combination of volunteer spirit and leadership if you would like to
influence outcomes for the better.  My initial nominations were a
combination of gut feel and nominees not saying "no".  :-)

Please head to Phabricator and comment in the specific areas about
your vision about what we should emphasize at WikiDev 16.

Rob

[1] https://phabricator.wikimedia.org/T119018
[2] 
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Scope#Working_Areas

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] IRC office hour this Thursday: reconnecting with the shared hosting community

[Rob Lanphier]

Hi Gilles,

Thanks for leading this!  My reading of your agenda leads me to believe
that this is intended as a "problem solving" meeting, as described in
User:RobLa-WMF/Meetings#Taxonomy.  To quote that article:

*Problem-solving* - Discuss a problem that we don’t know how to solve.
> "Conversation for possibility" as described by 1999 article
> 
>
>- Successful outcome: an idea or a reasonably complete list of ideas
>for how to solve the problem
>
>
>- Successful outcome: consensus on the priority about the importance
>of solving this problem (or consensus that it isn’t a problem after all)
>
>
>- Non-goal: a decision for how to solve the problem
>
>
Does that seem like an accurate characterization for what you have planned
on Thursday?  I recommend structuring the conversation (and figure out
action items) to achieve your imagined goal.

Rob

On Mon, Nov 16, 2015 at 11:59 AM, Gilles Dubuc  wrote:

> As part of T113210 [1], which is a broader discussion on track for the
> developer summit, I am hosting an IRC office hour [2] this Thursday at
> 19:00 UTC.
>
> Since shared hosting is a broad topic, this session will focus
> specifically on brainstorming ways to reconnect with the shared hosting
> community. Shared hosting mediawiki users are currently underrepresented in
> the greater mediawiki community. We rarely run into them in phabricator, on
> gerrit or on the mailing lists. Which means that people often have to think
> on their behalf about their use cases and issues, instead of getting direct
> input.
>
> There must be practical ways to bring those thousands of mediawiki users
> back into the fold, so to speak. Hopefully we can come up with interesting
> ideas to achieve that.
>
> And if you happen to be a shared hosting user, by all means, please join
> this IRC office hour :)
>
> [1] https://phabricator.wikimedia.org/T113210
> [2] https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
>
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC meeting tomorrow about EventBus

[Rob Lanphier]

Hi folks,

I wanted to let everyone know about the ArchCom RFC discussions we're
having on IRC in the #wikimedia-office channel.  We're having both a
special one tomorrow, and the regularly scheduled one Wednesday UTC.

Tomorrow, we have Phab event E86 scheduled to discuss Task T88459
(Implementing the reliable event bus using Kafka).

Wednesday, we have Phab event E85 to discuss Task T105638
(Streamlining Composer usage)

Please don't wait for an RFC meeting to weigh in on either of these,
though.  If you have something to say, comment on the appropriate Phab
task.

Links for those that want 'em:
https://www.mediawiki.org/wiki/User:RobLa-WMF#2015-10-29

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RfC reviews meetings(!) this week:

[Rob Lanphier]

Hi everyone,

We have our usually scheduled RfC review meeting on IRC coming up
tomorrow.  At this meeting, we plan to discuss the following RfCs:
* T112553: Integrate the Virtual Rest Service (VRS) into core
* T90914: Provide semantic wiki-configurable styles for media display

We anticipate the first one will be relatively short, then we may run
out of time before feeling "done" with the second one.

Phab event link #1: https://phabricator.wikimedia.org/E68

We're also hoping to pull together an extra discussion later in the
day to discuss "T30085: Allow user login with email address in
addition to username".  That depends on devunt's availability, though,
so that may be postponed.

Phab event link #2: https://phabricator.wikimedia.org/E74

Hope to see y'all there!

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] WikiDev16: Problem-solving, field narrowing and consensus

[Rob Lanphier]

Hi folks,

As you saw, the initial call for participation for WikiDev16[1] calls
for session proposals to be in fairly early (due October 2).  Many
people have already submitted proposals.[2]  It's encouraging to see
this early activity for this.

Let's make sure we plan to talk about what needs to be discussed,
rather than merely what a presenter is comfortable presenting about.
In fact, the word "present" should be a bit of a red flag (where
"present" means "lecture" rather than "gift" and rather than "opposite
of absent")

I made several edits to the WikiDev16/Scope page today[3], where I
attempted to clarify what I think will be the best use of our
collective time.  In short, you'll see five different types of
collaborative engineering meetings: "Problem-solving", "Strawman",
"Field narrowing", "Consensus", and "Education".  While all types of
discussions are generally productive, for WikiDev16, we should
strongly bias "Problem-solving", "Field narrowing", and "Consensus"
meetings.  "Strawman" and "Education" meetings can happen online
and/or in the hallway track[4].

I think we could learn a lot from how the IETF does things, and I
would like to model the bulk of the first two days of WikiDev16 around
the IETF way of doing things.  The IETF sets the standard for basic
Internet infrastructure, meeting three times a year in meetings anyone
can register for and attend.  I’ve put in a request (T111306) to
purposefully scout the next IETF meeting to give us more knowledge of
their process.[5]

We should strive to show we can build great software in an inclusive,
consensus-oriented, open manner.  Let's use this opportunity to figure
out how to make Wikimedia software work better, and make it more
joyful to work with.

Rob

[1] https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016
[2] https://phabricator.wikimedia.org/tag/wikimedia-developer-summit-2016/
[3] https://www.mediawiki.org/wiki/WikiDev16/Scope
[4] 
http://sachachua.com/blog/2010/12/making-the-most-of-the-conference-hallway-track/
[5] https://phabricator.wikimedia.org/T111306

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Development policy around database/SQL use

[Rob Lanphier]

Hi folks,

Executive summary:
T108255 is the default option for our Wednesday RfC review (E66)[0].
As part of improving our database use, we need to start gating our
code review on better shared norms of SQL correctness.  We need to
enable strict mode, cleanup/enforce primary keys (T17441), and start
using row-based replication (T109179).  Let's talk about this on
Wednesday.

Details:
We're still not 100% decided what our topic for this week's RfC review
meeting will be, but I'm leaning pretty heavily toward T108255.  Jaime
Crespo (Jynus) asked me about it last week, which inspired me to turn
T108255 into an RfC.  After he cleared up my writeup, I think there's
something for us to talk about.

In particular, I originally thought this was merely about enabling
MariaDB's strict mode, and all of the rainbows and unicorns that would
result from that.  Jaime corrected me, pointing out that there is
other database related cleanup we would need to do to get the benefits
of this.

So, as of this writing, T108255 by title still appears to be about
merely enabling strict mode.  It's tempting to split this ticket into
two tickets:
1.  RfC: Write/enforce SQL correctness guidelines
2.  Enable MariaDB/MySQL's Strict Mode

I may make a separate ticket tomorrow unless someone convinces me that
kittens will die as a result.[1]

Regarding SQL correctness guidelines, we have a mess of stuff on
mediawiki.org, which doesn't seem to be very discoverable, and also
doesn't seem to have any teeth to it.  We have a modest number of
pages marked as "MediaWiki development policies"[2], but of the 5
pages that were there, only 1 of them was about specifically about
databases, which is weakly called [[Database optimization]][3].  Since
[[Database optimization]] didn't seem to have gotten the review that
[[Security for developers]] or [[Gerrit/+2]] had, I changed its status
to "{{draft}}"

We *do* have something that actually looks more policy-like, which is
the "#Database patches" section of the [[Development policy]] page[4]
 However, it's not clear that the "Development policy" page gets read,
and has gotten pretty crufty.  It's tempting to put "{{draft}}" on
that one too.

It seems there are a number of sources we could/should be pulling from
to make a database development policy[5]  T108255 (or some
database-related RfC) should be about pulling all of these together
into a coherent set of guidelines.  These guidelines should be
well-known to frequent committers, and should be well-written for a
beginning developer.

What we need to actually *do* is not merely enable strict mode, but
also cleanup/enforce primary keys (T17441), and start using row-based
replication (T109179). Before completing all of this, we need our code
review gated on actually making this work.

The fact that we have a mess of documentation and norms is the reason
why I'm leaning toward this topic for the E66 meeting this week.  If
you believe we should talk about this, please participate at T108255
and help get this as far along as possible so that we can wrap things
up at the E66 meeting,  If you believe we should be talking about
something else in our IRC meeting, please say so in E66 on Phab.

Rob

[0]  IRC meeting:

"RfC: Enable MariaDB/MySQL's Strict Mode"


[1]  if someone decides to jfdi, I would recommend using T108255 for
the "Write/enforce SQL correctness guidelines" RfC, and make a new
ticket for the less important "Enable MariaDB/MySQL's Strict Mode".
The comments on the ticket seem to relate more to the former than the
latter, and the subscribers will probably be more interested in the
former.

[2]


[3] 

[4] 

[5] Other database-related guidance for developers:





___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l