Yes and you've probably received the same reply every time. Click the very
last link in the email (
), scroll to
unsubscribe, type your email, and click the button.
Negative24
On Thu, Jun 25, 2015 at 9:38 AM Lora Porter <lorkelley(a)gmail.com> wrote:
remove my email I've requested this multiple
times.
lora
On Jun 25, 2015 8:02 AM, <wikitech-l-request(a)lists.wikimedia.org> wrote:
Send Wikitech-l mailing list submissions to
wikitech-l(a)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(a)lists.wikimedia.org
You can reach the person managing the list at
wikitech-l-owner(a)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:
1. "Architecture meeting 2015" summary (Matthew Flaschen)
2. Barry the browser bot (Jon Robson)
3. Re: [Engineering] Modernizing our content platform: Kick-off
meeting on Tuesday (S Page)
4. Re: "Architecture meeting 2015" summary (MZMcBride)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Jun 2015 18:39:16 -0400
From: Matthew Flaschen <mflaschen(a)wikimedia.org>
To: EE List <ee(a)lists.wikimedia.org>rg>, Wikitech
<wikitech-l(a)lists.wikimedia.org>
Subject: [Wikitech-l] "Architecture meeting 2015" summary
Message-ID: <558B3194.7020302(a)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.20…
Log at
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
------------------------------
Message: 2
Date: Wed, 24 Jun 2015 16:55:59 -0700
From: Jon Robson <jrobson(a)wikimedia.org>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>rg>, Internal
communication for WMF Reading team <
reading-wmf(a)lists.wikimedia.org>gt;,
mobile-l
<mobile-l(a)lists.wikimedia.org>rg>, "QA (software
quality
assurance) for Wikimedia projects."
<qa(a)lists.wikimedia.org>
Subject: [Wikitech-l] Barry the browser bot
Message-ID:
<CALMndh=a-2PEAi+xENcNNCVG42yv4ZLPaCo0oDrt5qek8ww=
tg(a)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.c…
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
------------------------------
Message: 3
Date: Wed, 24 Jun 2015 17:19:13 -0700
From: S Page <spage(a)wikimedia.org>
To: Dan Garry <dgarry(a)wikimedia.org>
Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>rg>,
Development
and Operations Engineers
<engineering(a)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(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 23, 2015 at 10:01 PM, Dan Garry <dgarry(a)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.20…
starting at 21:21:05
[2] e.g.
https://www.mediawiki.org/wiki/Extension:Graph/Demo/Map?action=edit
https://www.mediawiki.org/wiki/Architecture_focus_2015#General_architectura…
[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(a)mzmcbride.com>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] "Architecture meeting 2015" summary
Message-ID: <D1B0F350.93021%z(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 143, Issue 48
*******************************************
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l