Re: [Wikitech-l] MediaWiki 1.26 release blockers

[Federico Leva (Nemo)]

AFAICS, MediaWiki 1.26 ResourceLoader introduces a bunch of regressions, 
where JavaScript and CSS randomly fails loading. See for instance 
https://phabricator.wikimedia.org/T112047#1623903


I bet the regressions won't be fixed on time for the release, but we 
should at least provide sysadmins (and extension developers) with some 
instructions on how to debug the issues and hopefully work around them.


Nemo

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

Re: [Wikitech-l] RFC: Optional Travis integration for Jenkins

[Greg Grossmeier]

> * iOS Mobile app
> 
> --
> missing OS X platform

If you want the gory details about the iOS decision, see:
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Retrospectives/Retrospective-iOS-Github-2015-08-03

Summary: Ain't nobody got time for maintaining OSX machines.


> This RFC in Phabricator: https://phabricator.wikimedia.org/T114421

Related, but slightly different:
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Code_review_platform_guideline

Related in that its about code-review, which has implications for CI,
but different because code-review can happen one place (Differential)
while CI can happen somewhere else (Travis).

I still feel extremely strongly that having a 90/10 split of repos on
Gerrit/Github only hurts our engineering community health. You can read
more of that reasoning in the above (draft) guideline and in this
document describing why we want to migrate to Differential:
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Gerrit_migration_why


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

[Wikitech-l] RFC: Optional Travis integration for Jenkins

[C. Scott Ananian]

We currently have several projects which can not be tested with our current
Jenkins test infrastructure, and as a consequence are hosting their primary
code repositories on github:
* RESTBase  -- missing Cassandra
support
* iOS Mobile app

--
missing OS X platform

Other projects can only run a small portion of their test suite via Jenkins:
* mw-ocg-latexer

-- requires LaTeX from PPA, image utilities (`jpegtran`).

An alternative to allow these apps to be hosted on Wikimedia infrastructure
(gerrit, eventually phabricator) is to allow travis integration with
jenkins as an optional service.

npm-travis  (
https://github.com/cscott/npm-travis) is a tool which will trigger Travis
builds from NPM by pushing to a throwaway branch, which is then cleaned up
after the tests complete.  It integrates well with the Gerrit access
control mechanism: the "Travis Bot" user can be granted push access only,
and only to branches prefixed with `npm-travis/`, so it cannot be used to
push changes to the master or deployment branches.

This isn't a replacement for our jenkins test infrastructure, but it allows
us to accommodate oddball repositories without taxing our infrastructure
team or resorting to offsite repository hosting.

There are WIP patches for integrating `npm-travis` with our jenkins
infrastructure (https://gerrit.wikimedia.org/r/173045,
https://gerrit.wikimedia.org/r/173046) but they seem to be blocked on
policy disagreements.  This RFC aims to resolve the policy issues.

This RFC in Phabricator: https://phabricator.wikimedia.org/T114421
  --scott
-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [RFC] Hygienic template arguments

[C. Scott Ananian]

As described in my Wikimania 2015 talk

 (starting at slide 31
),
the existing template argument syntax offers a number of traps for the
unwary (for example, with the characters `=`, `|`, etc).  As a result, it
is difficult to easily move large blocks of text into templates.

As a result, we often have constructs such as:
```
{{tablestart|class="shiny"}}
| Hello || world
{{tableend}}
```
which pose a number of issues:

   1. There is no mechanism to ensure `{{tablestart}}` and `{{tableend}}`
   are properly matched.
   2. Both `{{tablestart}}` and `{{tableend}}` emit unbalanced HTML, which
   complicates work on efficiently updating the parser cache after template
   changes.
   3. Due to the tag matching issues, this whole block is uneditable by
   Visual Editor.


***Hygienic arguments*** provide a new form of template invocation which
avoids these issues.

The above example would be written as:
```
{{>Table|class="shiny"}}
| Hello || world
{{< Table}}
```
and the contents between the template start `{{>...}}` and template end `
{{<...}}` are passed as (WLOG) the first positional argument of the
template.  Named arguments (like `class` in this example) can be passed
using the existing argument syntax as before.  The new `Template:Table` can
now emit properly balanced HTML, with both `` and ``
generated by the same template (instead of by two separate templates).
Visual Editor can now edit this block as a single template invocation,
invoking itself recursively to edit the template arguments as it does now.

Further, there are no special characters or odd escape rules in the
argument when expressed this way.  The only "special" construct inside the
argument is `{{<...}}` and any of those characters can be replaced by an
html entity to allow that character sequence to be included literally if
needed.  That is, we don't need special `{{!}}`, `{{=}}`, etc escapes.

Another example, from Brion Vibber's talk on citations

:
```
{{>cite|id=“32412”}}
First person plural pronouns in Isthmus-Mecayapan Nahuat:

:''nejamēn'' ({{IPA|[nehameːn]}}) "We, but not you" (= me & them)
:''tejamēn'' ({{IPA|[tehameːn]}}) "We along with you" (= me & you & them)
{{ which
have a similar construct
 (well, actually with
the spacebars

equivalent,
which shares a concern that template contents be well-balanced), it seems
that a large number of use cases can be satisfied with only one or two
"block arguments".

But let's say we want to allow more generality.  We could support:
```
{{>Foo|namedArg=bar|anotherNamedArg=bat}}
This first block goes in argument "1".
{{else}}
Now this goes in argument "2".
{{else}}
Now this goes in argument "3".  It's a little more natural if there are
only one or two arguments,
but we could keep going if we wanted.
{{...}}` and `{{<...}}` tags must be alone on their line, and that the
newline following the `{{>...}}` and `{{<...}}` tags is not copied into the
output.

We could enforce start-of-line context on the result to avoid the
T14974/T2529 hacks and make behavior consistent.  (More thought welcome
here.)

***Migrating template use***
We might allow configuring details of the parameter name(s) used for the
block argument(s) via `TemplateData`, to more easily use the new syntax
with existing templates.

Phabricator task for this RFC: https://phabricator.wikimedia.org/T114432
  --scott

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [RFC] Hygienic templates

[C. Scott Ananian]

*(Not to be confused with hygenic template arguments
.)*

As described in my Wikimania 2015 talk

 (starting at slide 27
),
there are a number of reasons to mark certain templates as "hygienic".
Among them: to allow high-performance incremental update of page contents
after templates are modified, and to allow safe editing of template uses
using HTML-based tools such as Visual Editor or jsapi
.

This means that the output of the template is a complete DocumentFragment
: every
open tag is closed and there are no nodes which the HTML adoption agency
algorithm
 will
reorder.

This can be enforced in practice by running tidy (or something like it:
T89331 ) on the template output
before it is inserted into the document.  We are likely to be doing
something like this already for T114072
.

The purpose of this RFC is to settle the bikeshed-color questions about how
templates will be marked hygienic/unhygienic.  There are two main scenarios:

***Opt-in Hygiene***

In this scenario, unmarked templates are assumed "dirty", and will render
correctly (as before), just more slowly.  Some of the unmarked templates
(the "actually dirty" ones) may be uneditable in VisualEditor.

In the opt-in scenario, it is expected that profiling the "costliest"/"most
frequently used/changed" templates on wikimedia projects will be done, and
opt-in tags will be added first to those templates where the greatest
potential performance gain may be achieved.  (Opting in will enable
incremental update of the parser cache after template modifications.)

Proposals:

   1. An explicit tag surrounding "hygienic" contents; this tag will
   exactly encapsulate the content which will be run through tidy.  Proposed
   names:
   1. `...`
  2. `...`
  3. `...`
   2. A magic word, present in templates known to be hygienic.  Proposed
   names:
   1. `__SAFE__`
  2. `__HYGIENIC__`
  3. Some `TemplateData
   ` property?
   4. Others?

***Opt-out Hygiene***

In this scenario, all templates are assumed "hygienic", and an explicit
marker of some kind is required to opt-out of the usual tidy of the
contents.  Templates which opt-out are not editable in Visual Editor, but
all other templates are (because the contents will have been automatically
cleaned to close any stray open tags).

In the opt-out scenario, it is expected that Parsoid (or other tools) will
be run against the wikimedia projects to automatically add opt-out tags
where possible; perhaps based on logging during the parse process.

Proposals:

   1. Magic word, present in unhygienic templates
   1. `__UNSAFE__`
  2. Others?

Phabricator task for this RFC: https://phabricator.wikimedia.org/T114445
  --scott

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Announcing Danny Horn's move to Community Tech

[Ryan Kaldari]

Howdy (my apologies for cross-posting),

I'm pleased to announce that the Community Tech team has a new Product
Manager – Danny Horn, who will be moving from the Collaboration team to
join this new initiative. The Community Tech team is focused on building
improved curation and moderation tools for experienced Wikimedia
editors.[1] Danny will be working with the team to develop the upcoming
Community Wishlist Survey, which will help the team define and prioritize
future projects.[2] We're excited to have someone with Danny's product
management experience as well as extensive wiki community experience
working with this team.

Danny’s role on the Collaboration team will be filled by a new Product
Manager which the Foundation is hiring for now. There’s an open job posting
on the WMF job board.[3]

Looking forward to working with Danny to build some awesome tools for the
community!

1. https://www.mediawiki.org/wiki/Community_Tech_team
2.
https://www.mediawiki.org/wiki/Community_Tech_team/Community_Wishlist_Survey
3. https://boards.greenhouse.io/wikimedia/jobs/104264?t=k7xsjm

Ryan Kaldari
Engineering Manager, Community Tech
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Collaboration Team Update

[Trevor Parscal]

Hi (and sorry for cross-posting)

I’d first like to say that I’m excited about Danny’s new role and the
positive impact I know he will have on the relatively new Community Tech
team, and that he will be missed in the Editing group. This change now
leaves an open position, which we are in the process of hiring a new
Product Manager to fill. There’s an open position posted.[1]

The Collaboration team, meanwhile, will continue their work to provide Flow
as an opt-in Beta feature, allowing contributors to use Flow on their user
talk page. This feature is currently available on MediaWiki.org, and will
be enabled on other wikis upon request. Especially as more users enable
Flow, the team will continue supporting users of the product by promptly
triaging and resolving bugs.

This quarter, which began yesterday, The Collaboration team will be
focusing on the development of cross-wiki notifications and other Echo
improvements. They’re also continuing to advance efforts to research and
prototype solutions for advanced editor workflows. Further feature
development on Flow discussion tools will be based on an assessment
following the 'workflows' research work, and on editor feedback at the
wikis already using Flow.[2]

Please ask any questions you may have on-wiki at
https://www.mediawiki.org/wiki/Talk:Flow to reduce fragmentation.

- Trevor

[1] https://boards.greenhouse.io/wikimedia/jobs/104264?t=k7xsjm
[2] https://www.mediawiki.org/wiki/Flow/Rollout
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcing Danny Horn's move to Community Tech

[Matthew Flaschen]

On 10/01/2015 07:05 PM, Ryan Kaldari wrote:

Howdy (my apologies for cross-posting),

I'm pleased to announce that the Community Tech team has a new Product
Manager – Danny Horn, who will be moving from the Collaboration team to
join this new initiative. The Community Tech team is focused on building
improved curation and moderation tools for experienced Wikimedia
editors.[1]


Danny, we're going to miss you a lot on the Collaboration team.

But I'm also excited about the work that the Community Tech team is 
doing.  These are important areas that WMF hasn't always spent enough 
resources on.


Matt Flaschen

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

[Wikitech-l] Phabricator monthly statistics - 2015-09

[communitymetrics]

Hi Community Metrics team,

this is your automatic monthly Phabricator statistics mail.

Number of accounts created in (2015-09): 363
Number of active users (any activity) in (2015-09): 863
Number of task authors in (2015-09): 477
Number of users who have closed tasks in (2015-09): 268

Number of projects which had at least one task moved from one column
 to another on their workboard in (2015-09): 209

Number of tasks created in (2015-09): 3351
Number of tasks closed in (2015-09): 2981

Number of open and stalled tasks in total: 25811

Median age in days of open tasks by priority:
Unbreak now: 11
Needs Triage: 125
High: 164
Normal: 301
Low: 660
Lowest: 528
(How long tasks have been open, not how long they have had that priority)

TODO: Numbers which refer to closed tasks might not be correct, as described in 
T1003.

Yours sincerely,
Fab Rick Aytor

(via community_metrics.sh on iridium at Thu Oct  1 00:00:08 UTC 2015)

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