New subject: Wikitech-l Digest, Vol 143, Issue 48

25 Jun 2015

      remove my email I've requested this multiple times.
lora
On Jun 25, 2015 8:02 AM, wikitech-l-request@lists.wikimedia.org wrote:
...
Send Wikitech-l mailing list submissions to
        wikitech-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or, via email, send a message with subject or body 'help' to
        wikitech-l-request@lists.wikimedia.org
You can reach the person managing the list at
        wikitech-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wikitech-l digest..."
Today's Topics:

"Architecture meeting 2015" summary (Matthew Flaschen)
Barry the browser bot (Jon Robson)
Re: [Engineering] Modernizing our content platform: Kick-off
meeting on Tuesday (S Page)
Re: "Architecture meeting 2015" summary (MZMcBride)

Message: 1
Date: Wed, 24 Jun 2015 18:39:16 -0400
From: Matthew Flaschen mflaschen@wikimedia.org
To: EE List ee@lists.wikimedia.org,   Wikitech
        wikitech-l@lists.wikimedia.org
Subject: [Wikitech-l] "Architecture meeting 2015" summary
Message-ID: 558B3194.7020302@wikimedia.org
Content-Type: text/plain; charset=utf-8; format=flowed
Today's RFC meeting was regarding general priorities for the coming
months (https://www.mediawiki.org/wiki/Architecture_focus_2015).
One of the key issues discussed was the idea of widgets, which is a new
approach to representing and editing bundles of content (such as an
infobox or a graph).
We also talked about canonical formats, and whether content should be
stored in wikitext and extracted out (like a more sophisticated version
of https://www.mediawiki.org/wiki/Extension:TextExtracts), or stored
elsewhere (e.g. Wikidata) and assembled.  Gabriel Wicke noted the
importance of minimizing disruption for existing editors and tools, and
Bryan Davis suggested this could limit the flexibility editors now have.
  This led us to discuss further what areas likely made sense to be
generated.  I.E. graphs and data tables, probably not prose (but Daniel
Kinzler suggested possibly auto-generating prose if there was no
human-written prose).
We talked about some approaches to backend storage.  Timo Tijhof
suggested allowing a page to be built from multiple blobs that reference
each other.
We talked about some approaches to widgets like infoboxes and inline
editing of templates more generally.
We also talked about testing coverage and code architecture guidelines.
Daniel Kinzler plans to update the document in response to feedback.
Matt Flaschen

Minutes at
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.201...
...
Log at
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.201...
...

Message: 2
Date: Wed, 24 Jun 2015 16:55:59 -0700
From: Jon Robson jrobson@wikimedia.org
To: Wikimedia developers wikitech-l@lists.wikimedia.org,      Internal
        communication for WMF Reading team      <
reading-wmf@lists.wikimedia.org>,
...
    mobile-l <mobile-l@lists.wikimedia.org>,        "QA (software

quality
...
    assurance) for Wikimedia projects."     <qa@lists.wikimedia.org>

Subject: [Wikitech-l] Barry the browser bot
Message-ID:
        <CALMndh=a-2PEAi+xENcNNCVG42yv4ZLPaCo0oDrt5qek8ww=
tg@mail.gmail.com>
...
Content-Type: text/plain; charset=UTF-8
Some of you may have noticed a bot [1] providing reviews for the
Mobilefrontend and Gather extensions.
This is a grass routes experiment [2] to see if we can reduce
regressions by running browser tests against every single commit. It's
very crude, and we're going to have to maintain it but we see this as
a crude stop gap solution until we get gerrit-bot taking care of this
for us.
Obviously we want to do this for all extensions but we wanted to get
something good enough that is not scaleable to start exploring this.
So far it has caught various bugs for us and our browser test builds
are starting to finally becoming consistently green, a few beta labs
flakes aside [3].
Running tests on beta labs is still useful but now we can use it to
identify tests caused by other extensions. We were finding too often
our tests were failing due to us neglecting them.
In case others are interested in how this is working and want to set
one up themselves I've documented this here:
https://www.mediawiki.org/wiki/Reading/Setting_up_a_browser_test_bot
Please let me now if you have any questions and feel free to edit and
improve this page. If you want to jump into the code that's doing this
and know Python check out:
https://github.com/jdlrobson/Barry-the-Browser-Test-Bot
(Patches welcomed and apologies in advance for the code)
[1]
https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.co...
...
[2] https://phabricator.wikimedia.org/T100293
[3]
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFron...
...

Message: 3
Date: Wed, 24 Jun 2015 17:19:13 -0700
From: S Page spage@wikimedia.org
To: Dan Garry dgarry@wikimedia.org
Cc: Wikimedia developers wikitech-l@lists.wikimedia.org,
Development
...
    and Operations Engineers <engineering@lists.wikimedia.org>

Subject: Re: [Wikitech-l] [Engineering] Modernizing our content
        platform: Kick-off meeting on Tuesday
Message-ID:
        <CAJg1jJVrs8BM5w-z=9+eQO6cwpNvXU=
td6j0cZ2WFTvw0-7meA@mail.gmail.com>
...
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 23, 2015 at 10:01 PM, Dan Garry dgarry@wikimedia.org wrote:
...
My takeaway from this was that there are strong arguments both for and
against keeping the representation of an article as a single blob of
wikitext/HTML.
In the Architecture focus discussion, Krinkle, tgr, and others expressed a
more optimistic idea, that the wikitext of an article is "a sea of prose
with isles of non-prose content, which could come from structured data"
[1].
...
I wasn't properly aware that the <graph> [2] and <templatedata> [3] parser
tags are examples of this already. Their content is highly structured and
VisualEditor or dedicated code can provide a specialized editor for it. If
you edit source of a wiki page containing them and garble their content,
you get a syntax warning or fail.
Wiki pages need more of these, <drumroll> Structure Content Blobs™ (or
sPage Components? anything but "widget"). Are they necessarily parser
tags,
...
or is a parser function like {{#graph: *some parameters*}} equivalent?
To be concrete, does this mean the way forward for specifying lead images
[5] is a parser tag
<leadimage>{
    "imagepage":   "File:Einstein_1921_by_F_Schmutzer_-_restoration.jpg",
    "focalarea": {"rect": [0.20, 0.20, 0.12, 0.12]}
}
</leadimage>
in wikitext, with a MediaWiki API to add this to a document and a WYSIWYG
property editor in VisualEditor for humans?
AIUI, the *Architecture focus 2015* document discusses this under
"Generalized transclusion" [4] and comments:
Over the next months, the MediaWiki developer community and staff should
investigate how the different transclusion mechanism used with wikitext
content can be unified and extended to work with non-wikitext content.
Exciting stuff.
[1]
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.201...
...
starting at 21:21:05
[2] e.g.
https://www.mediawiki.org/wiki/Extension:Graph/Demo/Map?action=edit
...
[3] e.g. https://www.mediawiki.org/wiki/Template:Phabricator?action=edit
[4]
https://www.mediawiki.org/wiki/Architecture_focus_2015#General_architectural...
...
[5] https://phabricator.wikimedia.org/T91683
--
=S Page  WMF Tech writer

Message: 4
Date: Thu, 25 Jun 2015 00:00:05 -0400
From: MZMcBride z@mzmcbride.com
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject: Re: [Wikitech-l] "Architecture meeting 2015" summary
Message-ID: D1B0F350.93021%z@mzmcbride.com
Content-Type: text/plain;       charset="UTF-8"
Matthew Flaschen wrote:
...
Today's RFC meeting was regarding general priorities for the coming
months (https://www.mediawiki.org/wiki/Architecture_focus_2015).
[...]
Daniel Kinzler plans to update the document in response to feedback.
I just wanted to say thank you to you and to Dan for these recent e-mails
summarizing larger technical discussions. :-)  While I appreciate the
value of synchronous chats, supporting asynchronous communication is also
important and these notes are very helpful in understanding, at a high
level, what's being discussed and why. They also help ensure that everyone
is aligned and informed and they make jumping into the discussions easier.
MZMcBride

Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 143, Issue 48

Re: [Wikitech-l] Wikitech-l Digest, Vol 143, Issue 48