Re: [Wikitech-l] Collaboration team reprioritization

[Brian Wolff]

On 9/3/15, Brian Wolff  wrote:
>>>
>>>
>>> This sounds a lot like PageTriage, which at best was a mixed success.
>>> I hope the team is able to extract lessons from that extension and
>>> apply them to whatever they intend to work on.
>>>
>>
>> "at best was a mixed success" speaking as someone who has used it
>> extensively, that is not the case. If you mean there are lessons to be
>> learned around ensuring we have generalisable solutions to specific
>> workflows, rather than project-specific solutions to project-specific
>> workflows, I share your hope.
>>
>
> The fact that its almost impossible to use outside enwiki, would be
> one of the main factors of why I would call its success mixed (One of
> the goals even was "allow expansion and modification of the system to
> support different backend systems and logic screens."). I do hope we
> do not repeat that limitation with new systems.
>
> The other reason I would call it mixed, is that the majority of
> patrolling even on enwiki, still takes place through the other
> interface (I believe. I'm not very familiar with patrolling on enwiki,
> so I may be misunderstanding something here)
>
> Stats for this August:
> MariaDB [enwiki_p]> select log_type, log_action, count(*) from logging
> where log_type in ( 'pagetriage-curation', 'pagetriage-deletion',
> 'patrol' ) and log_timestamp > '201508' and log_timestamp <
> '2015089900' group by log_type, log_action order by count(*);
> +-++--+
> | log_type| log_action | count(*) |
> +-++--+
> | patrol  | NULL   |4 |
> | pagetriage-curation | unreviewed |  134 |
> | pagetriage-deletion | delete | 1132 |
> | pagetriage-curation | delete | 1132 |
> | pagetriage-curation | tag| 2170 |
> | pagetriage-curation | reviewed   |10913 |
> | patrol  | patrol |   184269 |
> +-++--+
> 7 rows in set (3.75 sec)
>
> I'm not sure what level of popularity was targeted, but 6% market
> share (4.6% if you count by unique users instead of total number of
> patrol actions) doesn't seem like a run away success.
>
> Its certainly not a failure. But I'm not sure I would call it a full
> success either due to its lack of flexibility and luke-warm adoption
> numbers.
>
> --
> bawolff
>

I just realized I was counting autopatrol entries in with the other
patrol log entries, which is rather unfair to PageTriage. If you
discount autopatrol, then you get about 34% of patrol actions being
done via page triage (18% if you count by number of unique users
instead of total patrol actions). Well perhaps still not taking over
the patrolling world, that's a much more respectable percentage of the
market share.

I still hope lessons, both positive and negative, can be extracted
from PageTriage, when embarking on similar projects, and in
particular, I hope that future solutions can be used by all wikis
where applicable, not just enwiki.

--
bawolff

p.s. For reference, in case anyone wants to dispute my numbers.

MariaDB [enwiki_p]> select log_type, log_action, count(distinct
log_user) from logging where log_type in ( 'pagetriage-curation',
'pagetriage-deletion', 'patrol' ) and log_timestamp > '201508'
and log_timestamp < '2015089900' and log_params not like
'%auto";i:1;%' group by log_type, log_action;
+-++--+
| log_type| log_action | count(distinct log_user) |
+-++--+
| pagetriage-curation | delete |   98 |
| pagetriage-curation | reviewed   |  230 |
| pagetriage-curation | tag|  123 |
| pagetriage-curation | unreviewed |   53 |
| pagetriage-deletion | delete |   98 |
| patrol  | patrol | 1252 |
+-++--+
6 rows in set (1.05 sec)

MariaDB [enwiki_p]> select log_type, log_action, count(*) from logging
where log_type in ( 'pagetriage-curation', 'pagetriage-deletion',
'patrol' ) and log_timestamp > '201508' and log_timestamp <
'2015089900' and log_params not like '%auto";i:1;%' group by
log_type, log_action;
+-++--+
| log_type| log_action | count(*) |
+-++--+
| pagetriage-curation | delete | 1132 |
| pagetriage-curation | reviewed   |10913 |
| pagetriage-curation | tag| 2170 |
| pagetriage-curation | unreviewed |  134 |
| pagetriage-deletion | delete | 1132 |
| patrol  | patrol |31802 |
+-++--+
6 rows in set (5.78 sec)

___
Wikitech-l mailing list
Wikitech-l@lists.wi

Re: [Wikitech-l] Collaboration team reprioritization

[David Gerard]

On 4 September 2015 at 01:38, Ricordisamoa  wrote:
> Il 04/09/2015 01:24, Brandon Harris ha scritto:
>>> On Sep 3, 2015, at 4:06 PM, Ricordisamoa
>>> wrote:

>>> I appreciate the acknowledgement of failure.

>> I don't think that's what was said at all.  You may wish to
>> re-read all of this.

> Putting "active development" on hold when the software is little used in
> production and even some features a MVP should have had are missing, really
> sounds like a failure to me, although Danny has been very good at not making
> it sound like it.
> "To better address the needs of our core contributors", "we shift the team's
> focus to these other priorities", "communities that are excited about Flow
> discussions will be able to use it"



It read to me and many others like a fairly standard set of euphemisms
for when a project is killed but nobody wants to say "killed". Perhaps
we're all reading it wrong.

So, non-euphemistically: could someone please detail what, precisely,
is and is not the level of resource commitment to Flow? (And how it
compares to e.g. the level of resource commitment to LQT.)


- d.

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

Re: [Wikitech-l] Collaboration team reprioritization

[Pine W]

Re-reading the original email, it sounds to me like Flow is being put into
maintenance mode, not killed. It also sounds to me like the resources that
were being invested in Flow are going to be redirected to "the curation,
collaboration, and admin processes that take place on a variety of pages.
Many of these processes use complex workarounds -- templates, categories,
transclusions, and lots of instructions -- that turn blank wikitext talk
pages into structured workflows..."

As those of us who have spent a lot of time with these workflows know, they
can be a time-consuming pain. (Does anyone else remember trying to track
the discussion about the MediaViewer deployments to Commons, DEWP and ENWP
over however many dozens of separate pages, at least three wikis, and
multiple email threads?)

I think that Flow was intended to help with these situations. I guess that
where it might be fair to say that Flow has been "killed" is in the sense
that WMF seems to have decided that there are better options than Flow for
addressing some of these workflow problems. It seems to me that the end
goals are similar; the tools to achieve those goals may be different, and
that's ok.

Pine


On Fri, Sep 4, 2015 at 12:24 AM, David Gerard  wrote:

> On 4 September 2015 at 01:38, Ricordisamoa 
> wrote:
> > Il 04/09/2015 01:24, Brandon Harris ha scritto:
> >>> On Sep 3, 2015, at 4:06 PM, Ricordisamoa
> >>> wrote:
>
> >>> I appreciate the acknowledgement of failure.
>
> >> I don't think that's what was said at all.  You may wish to
> >> re-read all of this.
>
> > Putting "active development" on hold when the software is little used in
> > production and even some features a MVP should have had are missing,
> really
> > sounds like a failure to me, although Danny has been very good at not
> making
> > it sound like it.
> > "To better address the needs of our core contributors", "we shift the
> team's
> > focus to these other priorities", "communities that are excited about
> Flow
> > discussions will be able to use it"
>
>
>
> It read to me and many others like a fairly standard set of euphemisms
> for when a project is killed but nobody wants to say "killed". Perhaps
> we're all reading it wrong.
>
> So, non-euphemistically: could someone please detail what, precisely,
> is and is not the level of resource commitment to Flow? (And how it
> compares to e.g. the level of resource commitment to LQT.)
>
>
> - d.
>
> ___
> 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] Collaboration team reprioritization

[Pine W]

Regarding specific resource-level commitments: I've always had a hard time
with getting project-level financial data from WMF. I'm still waiting for
replies to questions that I asked about the Annual Plan a couple of months
ago. I do think that information like that should be public, and it would
be nice if WMF would move toward more financial transparency that's at
least on par with what's provided by US government agencies. I'd like to
keep the financial transparency discussion a bit separate from the
discussion about Flow's status. If WMF starts to provide public details
about project-level accounting in general, I would welcome that.

Pine


On Fri, Sep 4, 2015 at 12:24 AM, David Gerard  wrote:

> On 4 September 2015 at 01:38, Ricordisamoa 
> wrote:
> > Il 04/09/2015 01:24, Brandon Harris ha scritto:
> >>> On Sep 3, 2015, at 4:06 PM, Ricordisamoa
> >>> wrote:
>
> >>> I appreciate the acknowledgement of failure.
>
> >> I don't think that's what was said at all.  You may wish to
> >> re-read all of this.
>
> > Putting "active development" on hold when the software is little used in
> > production and even some features a MVP should have had are missing,
> really
> > sounds like a failure to me, although Danny has been very good at not
> making
> > it sound like it.
> > "To better address the needs of our core contributors", "we shift the
> team's
> > focus to these other priorities", "communities that are excited about
> Flow
> > discussions will be able to use it"
>
>
>
> It read to me and many others like a fairly standard set of euphemisms
> for when a project is killed but nobody wants to say "killed". Perhaps
> we're all reading it wrong.
>
> So, non-euphemistically: could someone please detail what, precisely,
> is and is not the level of resource commitment to Flow? (And how it
> compares to e.g. the level of resource commitment to LQT.)
>
>
> - d.
>
> ___
> 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] Collaboration team reprioritization

[Brian Wolff]

On 9/4/15, Pine W  wrote:
> Re-reading the original email, it sounds to me like Flow is being put into
> maintenance mode, not killed. It also sounds to me like the resources that
> were being invested in Flow are going to be redirected to "the curation,
> collaboration, and admin processes that take place on a variety of pages.
> Many of these processes use complex workarounds -- templates, categories,
> transclusions, and lots of instructions -- that turn blank wikitext talk
> pages into structured workflows..."
>
> As those of us who have spent a lot of time with these workflows know, they
> can be a time-consuming pain. (Does anyone else remember trying to track
> the discussion about the MediaViewer deployments to Commons, DEWP and ENWP
> over however many dozens of separate pages, at least three wikis, and
> multiple email threads?)

I seriously doubt any form of technology will solve the problem of
independent groups with overlapping interests discussing things in
multiple venues.

My reading of the original email is that they want to work on things
that have rather fixed bureaucratic procedures (e.g. Discussions about
what content to delete). Relatively free-form discussion across many
locations, seems like the opposite of that imo. I would love to hear
in more detail what the team concretely plans to work on, although I
imagine that's still in the process of being planned.

--
-bawolff

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

Re: [Wikitech-l] Collaboration team reprioritization

[Brian Wolff]

I don't think putting a $$ value on it is necessary to answer David's
question (Or even sufficient from a user perspective). The core of it
is:

*Will anyone (from WMF) be coding any new features, that don't exist yet.
*Will features that half work or are currently in the process of being
developed, be completed (Assuming there are any, I'm not following
flow development that closely).
*Will someone be working on existing bugs during this time (Or at
least existing bugs at some level of seriousness. And if so, what
level of seriousness would be required for someone to do it)
*Will someone be triaging and fixing new bugs as they come in (And
again, how does the answer vary depending on the seriousness of the
bug).
*Is the team planning to come back to Flow at a later date in a
serious way, or is this the end of active development for the
foreseeable future.

--
bawolff

On 9/4/15, Pine W  wrote:
> Regarding specific resource-level commitments: I've always had a hard time
> with getting project-level financial data from WMF. I'm still waiting for
> replies to questions that I asked about the Annual Plan a couple of months
> ago. I do think that information like that should be public, and it would
> be nice if WMF would move toward more financial transparency that's at
> least on par with what's provided by US government agencies. I'd like to
> keep the financial transparency discussion a bit separate from the
> discussion about Flow's status. If WMF starts to provide public details
> about project-level accounting in general, I would welcome that.
>
> Pine
>>
>>
>> It read to me and many others like a fairly standard set of euphemisms
>> for when a project is killed but nobody wants to say "killed". Perhaps
>> we're all reading it wrong.
>>
>> So, non-euphemistically: could someone please detail what, precisely,
>> is and is not the level of resource commitment to Flow? (And how it
>> compares to e.g. the level of resource commitment to LQT.)
>>
>>
>> - d.
>>
>> ___
>> 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collaboration team reprioritization

[Pine W]

Yes and no on the first point. Aggregation tools would be helpful.
Admittedly it's rare to have discussions spill into so many venues, so ROI
is questionable on an investment like that.

On more structured discussions, yes, those could be made easier to handle.
Maybe it would be better to handle the easier cases first. I'm with you in
looking forward to hearing plans for more details. (Maybe there can be a
live discussion about this at WikiConference USA, with remote participation
as an option?)

Pine


On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff  wrote:

> On 9/4/15, Pine W  wrote:
> > Re-reading the original email, it sounds to me like Flow is being put
> into
> > maintenance mode, not killed. It also sounds to me like the resources
> that
> > were being invested in Flow are going to be redirected to "the curation,
> > collaboration, and admin processes that take place on a variety of pages.
> > Many of these processes use complex workarounds -- templates, categories,
> > transclusions, and lots of instructions -- that turn blank wikitext talk
> > pages into structured workflows..."
> >
> > As those of us who have spent a lot of time with these workflows know,
> they
> > can be a time-consuming pain. (Does anyone else remember trying to track
> > the discussion about the MediaViewer deployments to Commons, DEWP and
> ENWP
> > over however many dozens of separate pages, at least three wikis, and
> > multiple email threads?)
>
> I seriously doubt any form of technology will solve the problem of
> independent groups with overlapping interests discussing things in
> multiple venues.
>
> My reading of the original email is that they want to work on things
> that have rather fixed bureaucratic procedures (e.g. Discussions about
> what content to delete). Relatively free-form discussion across many
> locations, seems like the opposite of that imo. I would love to hear
> in more detail what the team concretely plans to work on, although I
> imagine that's still in the process of being planned.
>
> --
> -bawolff
>
> ___
> 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] Collaboration team reprioritization

[Pine W]

I'm speculating that an analogue for Flow's situation will be Echo's
situation: somewhat maintained, but on the back burner for feature
development. (Although I occasionally hear rumors of feature additions to
Echo, and I think Echo might play well with improved discussion tools. I'd
also like to see global watchlists and global notifications.) Hopefully
we'll get a reply from Danny in the near future with more definitive
answers about Flow's situation. (:

Pine


On Fri, Sep 4, 2015 at 1:34 AM, Brian Wolff  wrote:

> I don't think putting a $$ value on it is necessary to answer David's
> question (Or even sufficient from a user perspective). The core of it
> is:
>
> *Will anyone (from WMF) be coding any new features, that don't exist yet.
> *Will features that half work or are currently in the process of being
> developed, be completed (Assuming there are any, I'm not following
> flow development that closely).
> *Will someone be working on existing bugs during this time (Or at
> least existing bugs at some level of seriousness. And if so, what
> level of seriousness would be required for someone to do it)
> *Will someone be triaging and fixing new bugs as they come in (And
> again, how does the answer vary depending on the seriousness of the
> bug).
> *Is the team planning to come back to Flow at a later date in a
> serious way, or is this the end of active development for the
> foreseeable future.
>
> --
> bawolff
>
> On 9/4/15, Pine W  wrote:
> > Regarding specific resource-level commitments: I've always had a hard
> time
> > with getting project-level financial data from WMF. I'm still waiting for
> > replies to questions that I asked about the Annual Plan a couple of
> months
> > ago. I do think that information like that should be public, and it would
> > be nice if WMF would move toward more financial transparency that's at
> > least on par with what's provided by US government agencies. I'd like to
> > keep the financial transparency discussion a bit separate from the
> > discussion about Flow's status. If WMF starts to provide public details
> > about project-level accounting in general, I would welcome that.
> >
> > Pine
> >>
> >>
> >> It read to me and many others like a fairly standard set of euphemisms
> >> for when a project is killed but nobody wants to say "killed". Perhaps
> >> we're all reading it wrong.
> >>
> >> So, non-euphemistically: could someone please detail what, precisely,
> >> is and is not the level of resource commitment to Flow? (And how it
> >> compares to e.g. the level of resource commitment to LQT.)
> >>
> >>
> >> - d.
> >>
> >> ___
> >> 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 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] Holding our code to better standards.

[Greg Grossmeier]

(I've put the TO: field as the QA list only, and put everyone else on
BCC now. If you're curious in this topic, please join the QA mailing
list and follow along. It's not a very high traffic list.)


> Dear Greg, and anyone else that is involved in deployment

Hi there :)

> 

Awesome :)

> The future!:
> Given this success:
> 1) I would like to see us run @integration tests on core, but I
> understand given the number of bugs this might not be feasible so far.

https://integration.wikimedia.org/ci/view/BrowserTests/view/Core/

Those are pretty stable, but limited (rightfully) in number. Looks like
the last run of the first job took 8 minutes. Not too bad.

> 2) We should run @integration tests prior to deployments to the
> cluster via the train and communicate out when we have failures (and
> make a decision to push broken code)

The way I hear this is: Run @integration tests on merge to wmfXX
branches. Is that an accurate rephrasing?

If not, then it mean what we're planning on doing with respect to the
"Staging" cluster work we started, paused (due to time constraints), and
will restart in Q3. tl;dr: The staging cluster will be a cluster that
runs nightly full blown tests against a git tag. In the morning we'll be
able to make a go/no-go decision on deploying that tag.

That "nightly" part can, of course, be modified to whatever frequency we
can support (which can probably be pretty fast).

> 3) I'd like to see other extensions adopt browser test voting on their
> extensions. Please feel free to reach out to me if you need help with
> that. The more coverage across our extensions we have, the better.

Thanks for the offer of help, Jon! That's awesome. I love the idea of
teams/groups helping other teams/groups! You, personally, have been
great this so far and I thank you for that.

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] Collaboration team reprioritization

[Risker]

Pine, given the questions at this point seem to be directed to the
Collaboration team, with the intention of clarifying what their plans are,
perhaps it would be best to encourage them to answer the questions rather
than continue the speculation.

Danny, perhaps you could take the lead on responding to David Gerard's
question?

On 4 September 2015 at 04:59, Pine W  wrote:

> I'm speculating that an analogue for Flow's situation will be Echo's
> situation: somewhat maintained, but on the back burner for feature
> development. (Although I occasionally hear rumors of feature additions to
> Echo, and I think Echo might play well with improved discussion tools. I'd
> also like to see global watchlists and global notifications.) Hopefully
> we'll get a reply from Danny in the near future with more definitive
> answers about Flow's situation. (:
>
> Pine
>
>
> On Fri, Sep 4, 2015 at 1:34 AM, Brian Wolff  wrote:
>
> > I don't think putting a $$ value on it is necessary to answer David's
> > question (Or even sufficient from a user perspective). The core of it
> > is:
> >
> > *Will anyone (from WMF) be coding any new features, that don't exist yet.
> > *Will features that half work or are currently in the process of being
> > developed, be completed (Assuming there are any, I'm not following
> > flow development that closely).
> > *Will someone be working on existing bugs during this time (Or at
> > least existing bugs at some level of seriousness. And if so, what
> > level of seriousness would be required for someone to do it)
> > *Will someone be triaging and fixing new bugs as they come in (And
> > again, how does the answer vary depending on the seriousness of the
> > bug).
> > *Is the team planning to come back to Flow at a later date in a
> > serious way, or is this the end of active development for the
> > foreseeable future.
> >
> > --
> > bawolff
> >
> > On 9/4/15, Pine W  wrote:
> > > Regarding specific resource-level commitments: I've always had a hard
> > time
> > > with getting project-level financial data from WMF. I'm still waiting
> for
> > > replies to questions that I asked about the Annual Plan a couple of
> > months
> > > ago. I do think that information like that should be public, and it
> would
> > > be nice if WMF would move toward more financial transparency that's at
> > > least on par with what's provided by US government agencies. I'd like
> to
> > > keep the financial transparency discussion a bit separate from the
> > > discussion about Flow's status. If WMF starts to provide public details
> > > about project-level accounting in general, I would welcome that.
> > >
> > > Pine
> > >>
> > >>
> > >> It read to me and many others like a fairly standard set of euphemisms
> > >> for when a project is killed but nobody wants to say "killed". Perhaps
> > >> we're all reading it wrong.
> > >>
> > >> So, non-euphemistically: could someone please detail what, precisely,
> > >> is and is not the level of resource commitment to Flow? (And how it
> > >> compares to e.g. the level of resource commitment to LQT.)
> > >>
> > >>
> > >> - d.
> > >>
> > >> ___
> > >> 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 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collaboration team reprioritization

[Antoine Musso]

Le 02/09/2015 21:10, Matthew Flaschen a écrit :

> Flow is not being killed.
> 
> In addition to maintaining and supporting it, we'll soon be working on
> rolling out a Beta feature to allow people to enable Flow on their user
> talk pages.

Thank you Matthew!  From Danny original mail I thought the whole Flow
was put on hold / postponed etc.

I will be VERY happy whenever my talk pages is finally a proper
discussion system and I have been waiting for that for more than a decade!

Kudos to you guys!

-- 
Antoine "hashar" Musso


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

[Wikitech-l] Jenkins upgrade Sep. 7th 8:00am UTC

[Antoine Musso]

Hello,

Zeljko and I will upgrade Jenkins on Monday Sept 7th at 8:00am UTC
(10:00am CET).

There will be roughly half an hour downtime. Zuul will keep queueing the
changes and trigger the jobs whenever Jenkins comes back up.

In case of crazy side effect, we will revert back to the current version.

Expected downtime is half an hour but I scheduled a two hours
maintenance window.


https://phabricator.wikimedia.org/T111326
https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=176205&oldid=176117


-- 
Antoine "hashar" Musso


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

Re: [Wikitech-l] Collaboration team reprioritization

[Jonathan Morgan]

On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff  wrote:
>
> I seriously doubt any form of technology will solve the problem of
> independent groups with overlapping interests discussing things in
> multiple venues.
>
> My reading of the original email is that they want to work on things
> that have rather fixed bureaucratic procedures (e.g. Discussions about
> what content to delete). Relatively free-form discussion across many
> locations, seems like the opposite of that imo. I would love to hear
> in more detail what the team concretely plans to work on, although I
> imagine that's still in the process of being planned.
>
>
You're correct, as far as I know. I can't/won't speak for Danny about the
product roadmap (I'm sure he will jump in here again), but one component of
what's planned is indeed support for these so-called "bureaucratic
procedures". I did some initial research before Wikimania (still-drafty
wikipage report[1], internal presentation[2]), and Danny incorporated some
of this into his Wikimania presentation.[3]

I've heard of several other components from the team, but "workflows" is
definitely part of it.

Thanks to you, Pine, Risker and others for the good-faith assessments, btw.

J

1.
https://www.mediawiki.org/wiki/Flow/Community_process_workflow_interviews_(June_2015)
2.
https://www.mediawiki.org/wiki/File:Flow_workflow_interviews_-_initial_findings_June_2015.pdf
3.
https://www.mediawiki.org/wiki/File:User(s)_Talk(ing)_-_Wikimania_2015.pdf


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



-- 
Jonathan T. Morgan
Senior Design Researcher
Wikimedia Foundation
User:Jmorgan (WMF) 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] QA: Holding our code to better standards.

[Greg Grossmeier]

> In the services team, we found that prominent coverage metrics are a very
> powerful motivator for keeping tests in order. We have set up 'voting'
> coverage reports, which fail the overall tests if coverage falls, and make
> it easy to check which lines aren't covered yet (via coveralls). In all
> repositories we enabled this for, test coverage has since stabilized around
> 80-90%.

We (RelEng), too, are interested in this. Given the nature of our
projects we'll probably need to start this on a case-by-case basis,
(un)fortunately. :)

There's two parts to this (as I see it): informational and enforcement.

Informational:
* "Generate code coverage reports for extensions"
** https://phabricator.wikimedia.org/T71685
* Add ^^^ to "QA Health scoreboard"
** https://phabricator.wikimedia.org/T108768

Enforcement:
* What Gabriel described above.
** There's no one ticket for tracking this cross repos right now, I'll
create one...
** https://phabricator.wikimedia.org/T111546

Greg

PS: I didn't mean to, but I forked this thread across wikitech-l and qa
lists (my bcc to wikitech-l didn't make it through mailman, I don't
think). See the other sub-thread on adding @integration test runs on wmf
deploy branch creation at:
https://lists.wikimedia.org/pipermail/qa/2015-September/thread.html

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

[Wikitech-l] Rotating pictures idea

[Ole Palnatoke Andersen]

I talked to Charlotte SH Jensen at the National Museum in Copenhagen yesterday.

We've been talking and doing stuff for several years, so we have a
huge backlog of ideas that didn't work, but we're still able to find
new things to do.

One idea that came up yesterday is rotating pictures on Wikipedia. We
hope to get people to do something at the #hack4dk hackathon in early
October.

See the idea at
https://hackdash.org/projects/55e99d6174d6ac1d21451575, and more about
#hack4dk at http://hack4.dk/


Regards,
Ole Palnatoke Andersen, Wikimedia Danmark

-- 
http://palnatoke.org * @palnatoke * +4522934588

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

Re: [Wikitech-l] Rotating pictures idea

[Brion Vibber]

Cool! This sort of thing can definitely be rigged up with some JavaScript,
with a fallback to showing just one base image.

-- brion

On Fri, Sep 4, 2015 at 11:25 AM, Ole Palnatoke Andersen  wrote:

> I talked to Charlotte SH Jensen at the National Museum in Copenhagen
> yesterday.
>
> We've been talking and doing stuff for several years, so we have a
> huge backlog of ideas that didn't work, but we're still able to find
> new things to do.
>
> One idea that came up yesterday is rotating pictures on Wikipedia. We
> hope to get people to do something at the #hack4dk hackathon in early
> October.
>
> See the idea at
> https://hackdash.org/projects/55e99d6174d6ac1d21451575, and more about
> #hack4dk at http://hack4.dk/
>
>
> Regards,
> Ole Palnatoke Andersen, Wikimedia Danmark
>
> --
> http://palnatoke.org * @palnatoke * +4522934588
>
> ___
> 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] "Try the free Wikipedia app" banners

[Brandon Harris]

> On Sep 2, 2015, at 3:53 PM, Toby Negrin  wrote:

> 1. We're moving people from an open platform to a closed platform: I think
> this is an oversimplification of the situation -- as has been noted before,
> the android app is 100% open source and while the data is not, in my
> opinion, comprehensive, it's inarguable that a large percentage of mobile
> traffic on the internet is from apps. It's not possible to fulfill our
> mission[4] if Wikipedia and sister project content is not available in
> widely used channels.

I'm not sure this makes a lot of sense.  The widest, most-open content 
channel that the projects have is through the web interfaces:  all phones, all 
devices, all computers can access the same content in the same manner.  That is 
to say: 100% of our readers have the ability to use the web versions (either 
desktop or mobile web) where as only a subset can use the Android app, which is 
a different subset that can use iOS.  (They also end up having fragmented 
experiences, which is sub-optimal.)

So it seems to me that the apps are not required to fulfill the 
mission.  They feel like distractions, and - quite possibly - negatives to the 
mission (in that we can't convert Readers into Editors through the app).

(Which, by the way, this whole "focus entirely on readers" shift seems 
counter-intuitive to me.  Having a billion readers doesn't mean anything if 
there aren't any editors anymore. It's a complete failure at that point.)

> 2. The campaign was not publicized before launch: We notified the Finnish
> community on their Village pump before the campaign began[5] and the
> campaign is detailed on the central notice page[6]. We felt this was
> appropriate considering the scope of the test.

Restricting the conversation to two very small, almost impenetrable 
discussion areas seems unwise.  It seems obvious to me that this idea and 
action would cause friction with the community.  I don't think there's any 
bad-faith going on here, but this definitely feels like an oversight.

> 3. Banners/Interstitials don't work/suck/etc: There's a difference between
> a forced install and letting users know that an app exists and our
> designers have worked hard to make the banners effective without being
> excessively intrusive. You can see the designs on the Phab ticket above. I
> don't generally place a great deal of faith in blog posts or other
> company's data -- the google study showing the ineffectiveness of
> interstitials has already been challenged by other similarly reputable
> sources [7,8]. For this and other reasons, I believe that we need to gather
> our own data.

Is "our own data" more important than the goodwill of our users or 
developers?  I think that's a big part of why people might be upset about this: 
it's a step away from what had classically been the principles underlying the 
movement's activities.

Even that said, though:  this is the first anyone is saying "yes, we 
did some research about interstitials".  It seems to me that the Google study 
was something that could have been discussed ahead of time.   I also don't 
understand why we can't do the whole Open Source thing and make use of other 
people's research, unless this indicates a further shift into "not invented 
here" territory. 

> 4. We don't understand what success looks like: We are planning a meeting
> with our Research team[9] to assess the statistical validity of our
> results, but the basic question is if users read more content using the app
> than the mobile web. This information will help guide us on future product
> decisions and will be shared with the community.

An experiment without a box isn't an experiment.  

"We would like to determine if people read more through the 
apps than through the web interface" is a _great_ question (but also one that 
could probably be answered just by looking at squid logs).  I don't know that 
it needs an advertising campaign to create app users to do it (though I could 
be wrong, and often am, and would love to hear how if so).  It further seems 
that advertising the mobile apps would create a biases in the research (if only 
that "newish" app users are likely to use it more often earlier in their 

"We would like to determine if people download the app more 
often if they've been given an interstitial" is also an interesting question 
but it's got a secondary question that no one seems to care about: "How many 
readers have we put off from returning by showing them this interstitial?"  I 
know that I often immediately shut windows and tabs when I'm told "download our 
app!"  

If this were brought to the wider community in a different manner, 
there may have been a completely different response:

"We do not believe that people are aware that there are 
official Wikipedia apps. We would like to run an experiment to see how likely 
people are to switch to

Re: [Wikitech-l] "Try the free Wikipedia app" banners

[David Gerard]

On 4 September 2015 at 20:12, Brandon Harris  wrote:

> So it seems to me that the apps are not required to fulfill the 
> mission.  They feel like distractions, and - quite possibly - negatives to 
> the mission (in that we can't convert Readers into Editors through the app).


It's worth stressing here that our app is really good for reading. I
have kept a gaggle of 7-8yo children amused while they were playing
"guess the animal" by calling up the animal in question on Wikipedia
on my S4 Mini, complete with that picture in the header. It was better
than trying to do the same on the website has been on the same phone
in the past. So let's not forget to give the app at least some love
:-)


- d.

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

[Wikitech-l] Code of Conduct: Intro, Principles, and Unacceptable behavior sections

[Matthew Flaschen]

There is consensus at
https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Draft#Next_steps
that the best way to finalize the CoC draft is to focus on a few
sections at once (while still allowing people to comment on other
ones).  This allows progress without requiring people to monitor all
sections at once and lets us separate the questions of “what are our
goals here?” and “how should this work?”.  After these sections are
finalized, I recommend minimizing or avoiding later substantive
changes to them.

The first sections being finalized are the intro (text before the
Principles section), Principles, and Unacceptable behavior.  These
have been discussed on the talk page for the last two weeks, and
appear to have stabilized.

However, there may still be points that need to be refined. Please
participate in building consensus on final versions of these sections:

* https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Draft

* https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft

If you are not comfortable contributing to this discussion under your
name or a pseudonym, you can email your feedback or suggestions to
conduct-discuss...@wikimedia.org .  Quim Gil, Frances Hocutt, and
Kalliope Tsouroupidou will be monitoring this address and will
anonymously bring the points raised into the discussion at your
request.

Thanks,

Matt Flaschen

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

Re: [Wikitech-l] Collaboration team reprioritization

[Danny Horn]

Flow is going to be one of the extensions that the Collaboration team
maintains, along with Echo and Thanks. "Not in active development" means
that we're not going to build or change features, but we're going to fix
bugs and make sure that people who are using Flow have a good experience
with it.

It's a similar situation to Echo, which wasn't in active development for at
least eighteen months, but we fixed bugs and made some changes to connect
it up with Flow. We've recently started doing the prep work for global
cross-wiki Echo notifications, which is another project that we're going to
be working on in October.

We talked about the Workflows project at Wikimania, introducing it as
something that we were going to work on in early 2016. This priority change
basically means that Workflows moves from "3 to 6 months from now" to next
month.

As people have noted, the Foundation spent money developing Flow discussion
features, and we did the work in iterative stages, to make sure that there
was a useable (if incomplete) product at every stage. That gave us the
opportunity to get great feedback and see how people were using Flow, but
it also just provides value on its own. Shifting priorities happens with
product teams all the time, so you always want to be able to get to a
stable place, and still have something worthwhile.

Right now, there are several wikis that are enthusiastic about using Flow,
on user talk pages, help forums and village pump-style discussion pages.
Later this month, we're going to release the opt-in beta feature for wikis
that request it, so that people can turn Flow on for their own user talk
pages, and continue to get value out of the existing product. At that
point, it's our responsibility to fix bugs and maintain it, so that we're
not jerking the rug out from under the people who have been so helpful and
important to the team.

Danny



On Fri, Sep 4, 2015 at 9:07 AM, Jonathan Morgan 
wrote:

> On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff  wrote:
> >
> > I seriously doubt any form of technology will solve the problem of
> > independent groups with overlapping interests discussing things in
> > multiple venues.
> >
> > My reading of the original email is that they want to work on things
> > that have rather fixed bureaucratic procedures (e.g. Discussions about
> > what content to delete). Relatively free-form discussion across many
> > locations, seems like the opposite of that imo. I would love to hear
> > in more detail what the team concretely plans to work on, although I
> > imagine that's still in the process of being planned.
> >
> >
> You're correct, as far as I know. I can't/won't speak for Danny about the
> product roadmap (I'm sure he will jump in here again), but one component of
> what's planned is indeed support for these so-called "bureaucratic
> procedures". I did some initial research before Wikimania (still-drafty
> wikipage report[1], internal presentation[2]), and Danny incorporated some
> of this into his Wikimania presentation.[3]
>
> I've heard of several other components from the team, but "workflows" is
> definitely part of it.
>
> Thanks to you, Pine, Risker and others for the good-faith assessments, btw.
>
> J
>
> 1.
>
> https://www.mediawiki.org/wiki/Flow/Community_process_workflow_interviews_(June_2015)
> 2.
>
> https://www.mediawiki.org/wiki/File:Flow_workflow_interviews_-_initial_findings_June_2015.pdf
> 3.
> https://www.mediawiki.org/wiki/File:User(s)_Talk(ing)_-_Wikimania_2015.pdf
>
>
> > --
> > -bawolff
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Jonathan T. Morgan
> Senior Design Researcher
> Wikimedia Foundation
> User:Jmorgan (WMF) 
> ___
> 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] Collaboration team reprioritization

[Pine W]

Thanks for the expanded update.

I'm a big fan of Echo and am happy to hear that global notifications are
coming.

If you'll be at WikiConference USA, I'd appreciate a chance to talk with
you there in person, and others might as well!

Pine


On Fri, Sep 4, 2015 at 2:48 PM, Danny Horn  wrote:

> Flow is going to be one of the extensions that the Collaboration team
> maintains, along with Echo and Thanks. "Not in active development" means
> that we're not going to build or change features, but we're going to fix
> bugs and make sure that people who are using Flow have a good experience
> with it.
>
> It's a similar situation to Echo, which wasn't in active development for at
> least eighteen months, but we fixed bugs and made some changes to connect
> it up with Flow. We've recently started doing the prep work for global
> cross-wiki Echo notifications, which is another project that we're going to
> be working on in October.
>
> We talked about the Workflows project at Wikimania, introducing it as
> something that we were going to work on in early 2016. This priority change
> basically means that Workflows moves from "3 to 6 months from now" to next
> month.
>
> As people have noted, the Foundation spent money developing Flow discussion
> features, and we did the work in iterative stages, to make sure that there
> was a useable (if incomplete) product at every stage. That gave us the
> opportunity to get great feedback and see how people were using Flow, but
> it also just provides value on its own. Shifting priorities happens with
> product teams all the time, so you always want to be able to get to a
> stable place, and still have something worthwhile.
>
> Right now, there are several wikis that are enthusiastic about using Flow,
> on user talk pages, help forums and village pump-style discussion pages.
> Later this month, we're going to release the opt-in beta feature for wikis
> that request it, so that people can turn Flow on for their own user talk
> pages, and continue to get value out of the existing product. At that
> point, it's our responsibility to fix bugs and maintain it, so that we're
> not jerking the rug out from under the people who have been so helpful and
> important to the team.
>
> Danny
>
>
>
> On Fri, Sep 4, 2015 at 9:07 AM, Jonathan Morgan 
> wrote:
>
> > On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff  wrote:
> > >
> > > I seriously doubt any form of technology will solve the problem of
> > > independent groups with overlapping interests discussing things in
> > > multiple venues.
> > >
> > > My reading of the original email is that they want to work on things
> > > that have rather fixed bureaucratic procedures (e.g. Discussions about
> > > what content to delete). Relatively free-form discussion across many
> > > locations, seems like the opposite of that imo. I would love to hear
> > > in more detail what the team concretely plans to work on, although I
> > > imagine that's still in the process of being planned.
> > >
> > >
> > You're correct, as far as I know. I can't/won't speak for Danny about the
> > product roadmap (I'm sure he will jump in here again), but one component
> of
> > what's planned is indeed support for these so-called "bureaucratic
> > procedures". I did some initial research before Wikimania (still-drafty
> > wikipage report[1], internal presentation[2]), and Danny incorporated
> some
> > of this into his Wikimania presentation.[3]
> >
> > I've heard of several other components from the team, but "workflows" is
> > definitely part of it.
> >
> > Thanks to you, Pine, Risker and others for the good-faith assessments,
> btw.
> >
> > J
> >
> > 1.
> >
> >
> https://www.mediawiki.org/wiki/Flow/Community_process_workflow_interviews_(June_2015)
> > 2.
> >
> >
> https://www.mediawiki.org/wiki/File:Flow_workflow_interviews_-_initial_findings_June_2015.pdf
> > 3.
> >
> https://www.mediawiki.org/wiki/File:User(s)_Talk(ing)_-_Wikimania_2015.pdf
> >
> >
> > > --
> > > -bawolff
> > >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> >
> >
> >
> > --
> > Jonathan T. Morgan
> > Senior Design Researcher
> > Wikimedia Foundation
> > User:Jmorgan (WMF) 
> > ___
> > 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collaboration team reprioritization

[Amir Ladsgroup]

Also Corss-wiki watchlists  are
good place to start.

Best

On Sat, Sep 5, 2015 at 2:35 AM Pine W  wrote:

> Thanks for the expanded update.
>
> I'm a big fan of Echo and am happy to hear that global notifications are
> coming.
>
> If you'll be at WikiConference USA, I'd appreciate a chance to talk with
> you there in person, and others might as well!
>
> Pine
>
>
> On Fri, Sep 4, 2015 at 2:48 PM, Danny Horn  wrote:
>
> > Flow is going to be one of the extensions that the Collaboration team
> > maintains, along with Echo and Thanks. "Not in active development" means
> > that we're not going to build or change features, but we're going to fix
> > bugs and make sure that people who are using Flow have a good experience
> > with it.
> >
> > It's a similar situation to Echo, which wasn't in active development for
> at
> > least eighteen months, but we fixed bugs and made some changes to connect
> > it up with Flow. We've recently started doing the prep work for global
> > cross-wiki Echo notifications, which is another project that we're going
> to
> > be working on in October.
> >
> > We talked about the Workflows project at Wikimania, introducing it as
> > something that we were going to work on in early 2016. This priority
> change
> > basically means that Workflows moves from "3 to 6 months from now" to
> next
> > month.
> >
> > As people have noted, the Foundation spent money developing Flow
> discussion
> > features, and we did the work in iterative stages, to make sure that
> there
> > was a useable (if incomplete) product at every stage. That gave us the
> > opportunity to get great feedback and see how people were using Flow, but
> > it also just provides value on its own. Shifting priorities happens with
> > product teams all the time, so you always want to be able to get to a
> > stable place, and still have something worthwhile.
> >
> > Right now, there are several wikis that are enthusiastic about using
> Flow,
> > on user talk pages, help forums and village pump-style discussion pages.
> > Later this month, we're going to release the opt-in beta feature for
> wikis
> > that request it, so that people can turn Flow on for their own user talk
> > pages, and continue to get value out of the existing product. At that
> > point, it's our responsibility to fix bugs and maintain it, so that we're
> > not jerking the rug out from under the people who have been so helpful
> and
> > important to the team.
> >
> > Danny
> >
> >
> >
> > On Fri, Sep 4, 2015 at 9:07 AM, Jonathan Morgan 
> > wrote:
> >
> > > On Fri, Sep 4, 2015 at 1:25 AM, Brian Wolff  wrote:
> > > >
> > > > I seriously doubt any form of technology will solve the problem of
> > > > independent groups with overlapping interests discussing things in
> > > > multiple venues.
> > > >
> > > > My reading of the original email is that they want to work on things
> > > > that have rather fixed bureaucratic procedures (e.g. Discussions
> about
> > > > what content to delete). Relatively free-form discussion across many
> > > > locations, seems like the opposite of that imo. I would love to hear
> > > > in more detail what the team concretely plans to work on, although I
> > > > imagine that's still in the process of being planned.
> > > >
> > > >
> > > You're correct, as far as I know. I can't/won't speak for Danny about
> the
> > > product roadmap (I'm sure he will jump in here again), but one
> component
> > of
> > > what's planned is indeed support for these so-called "bureaucratic
> > > procedures". I did some initial research before Wikimania (still-drafty
> > > wikipage report[1], internal presentation[2]), and Danny incorporated
> > some
> > > of this into his Wikimania presentation.[3]
> > >
> > > I've heard of several other components from the team, but "workflows"
> is
> > > definitely part of it.
> > >
> > > Thanks to you, Pine, Risker and others for the good-faith assessments,
> > btw.
> > >
> > > J
> > >
> > > 1.
> > >
> > >
> >
> https://www.mediawiki.org/wiki/Flow/Community_process_workflow_interviews_(June_2015)
> > > 2.
> > >
> > >
> >
> https://www.mediawiki.org/wiki/File:Flow_workflow_interviews_-_initial_findings_June_2015.pdf
> > > 3.
> > >
> >
> https://www.mediawiki.org/wiki/File:User(s)_Talk(ing)_-_Wikimania_2015.pdf
> > >
> > >
> > > > --
> > > > -bawolff
> > > >
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > >
> > >
> > >
> > >
> > > --
> > > Jonathan T. Morgan
> > > Senior Design Researcher
> > > Wikimedia Foundation
> > > User:Jmorgan (WMF)  >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > ___
> > Wi