Re: [Wikitech-l] Allow HTML email

[Tim Starling]

OK done, and it seems to be working.

Sorry to pre-empt the discussion, but I really wanted to send that
triage email as HTML.

We still haven't heard from Faidon who, last I heard, still reads his
emails by piping telnet into less or something. But I think he can
make sense of multipart/alternative as long as it's not base-64
encoded. You should send the plain text as the first part so he
doesn't have to page down too far  ;)

-- Tim Starling

On 23/9/20 2:31 pm, Tito Dutta wrote:
> Yes, that would be helpful.
>
> বুধ, ২৩ সেপ্টেম্বর, ২০২০ ৯:০৫ AM তারিখে MusikAnimal
> mailto:musikani...@gmail.com>> লিখেছেন:
>
> Agreed! The word wrapping especially drives me nuts. My phone is
> just small
> enough that the last word or two of each line gets wrapped
> natively, on top
> of Mailman's wrapping, making any sizable email a difficult read.
>
> ~ MA
>
> On Tue, Sep 22, 2020 at 11:26 PM Gergő Tisza  > wrote:
>
> > Yes please. A mere fifty years after the invention of
> hyperlinks, it would
> > be great to adopt them here.
> > ___
> > 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] Allow HTML email

[ZI Jony]

Agreed, good idea.

On Wed, Sep 23, 2020, 10:31 AM Tito Dutta  wrote:

> Yes, that would be helpful.
>
> বুধ, ২৩ সেপ্টেম্বর, ২০২০ ৯:০৫ AM তারিখে MusikAnimal 
> লিখেছেন:
>
>> Agreed! The word wrapping especially drives me nuts. My phone is just
>> small
>> enough that the last word or two of each line gets wrapped natively, on
>> top
>> of Mailman's wrapping, making any sizable email a difficult read.
>>
>> ~ MA
>>
>> On Tue, Sep 22, 2020 at 11:26 PM Gergő Tisza  wrote:
>>
>> > Yes please. A mere fifty years after the invention of hyperlinks, it
>> would
>> > be great to adopt them here.
>> > ___
>> > 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] TechCom meeting 2020-09-23

[Tim Starling]

Resending in HTML format. Hopefully I've got the settings right now.

This is the weekly TechCom board review in preparation of our meeting
on Wednesday. If there are additional topics for TechCom to review,
please let us know by replying to this email. However, please keep
discussion about individual RFCs to the Phabricator tickets.

Activity since Monday 2020-09-13 on the following boards:

https://phabricator.wikimedia.org/tag/techcom/
https://phabricator.wikimedia.org/tag/techcom-rfc/

Committee inbox:

  * Two tasks have been sitting in there for multiple weeks

Committee board activity:

  * RFCs only, see below

New RFCs:

  * None

Phase progression:

  * Timo hid the "Old" column and moved old RFCs to P1. Some had
additional changes or comments.
  * Several were closed by Timo with status "declined", which James
Forrester changed to "invalid".
  * It is hard to find justification for these actions in the linked
RFC process document. There is no mention of it in the committee
meeting minutes for the last three weeks.
  * T157402  Provide a
reliable way to pass information between hook handlers, "hooked"
objects
  o An RFC that was stalled since 2019, closed "declined"
  * T487  Associated namespaces

  o Timo asks if it can be merged with something.
  * T96384 
  * T154675  Introduce a
listener interface for LinkRenderer hooks
  o Closed
  * T259771  Drop support
for database upgrade older than two LTS releases
  o Moved to P3
  * T252091 Site-wide edit
rate limiting with PoolCounter
  o Moved to P2. Timo asks who is stewarding it.
  * T240775  Support PHP
7.4 preload
  o Moved to P3
  * T128351 Notifications
should be in core
  o Some back and forth over the status of this, ending up with it
being P1 and "stalled"
  * T215046 Use Github
login for mediawiki.org
  o Timo closed "declined".
  * T105766 Dependency
graph storage; sketch: adjacency list in DB
  o Timo closed due to lack of owner
  * T484 Scoped language converter
  o Timo closed due to lack of owner
  * T114662 Per-language
URLs for multilingual wiki pages
  o Timo closed due to lack of owner
  * T120380 Allow JSON
values to be included in the API results
  o Timo closed due to lack of owner
  * T193690 How should we
fix the undeletion system?
  o Timo moved to P1 and stalled
  * T113034 Overhaul
Interwiki map, unify with Sites and WikiMap
  o Old -> P1
  * T119043
Graph/Graphoid/Kartographer
- data storage architecture
  o Timo closed due to lack of owner, Yurik's RFC superseded by
Dan's RFC
  * T196950 Pages do not
have stable identifiers
  o Timo closed due to lack of owner
  * T158360 Reevaluate
LocalisationUpdate extension for WMF
  o Old -> P1
  * T181451 WebAssembly and
compiled JS code best practices
  o Old -> P1
  * T114445 Balanced templates
  o Old -> P1
  * T213345 Spin off
(Parsoid) language variants functionality as a microservice?
  o Timo closed due to lack of owner
  * T202673 Multiblocks -
let admins create multiple, overlapping blocks on a single user
  o Old -> P1
  * T111588 API-driven web
front-end
  o Timo closed due to lack of owner
  * T117550 Content bundler
  o Timo closed due to lack of owner
  * T111604 : Split parser
tests info multiple files
  o Timo closed due to lack of owner
  * T106099 Page
composition using service workers and server-side JS fall-back
  o Timo closed due to lack of owner
  * T40010 Re-evaluate
librsvg as SVG renderer on Wikimedia wikis
  o Old -> P1
  * T347 CentralNotice Caching
Overhaul - Frontend Proxy
  o Timo closed due to lack 

Re: [Wikitech-l] Allow HTML email

[Tito Dutta]

Yes, that would be helpful.

বুধ, ২৩ সেপ্টেম্বর, ২০২০ ৯:০৫ AM তারিখে MusikAnimal 
লিখেছেন:

> Agreed! The word wrapping especially drives me nuts. My phone is just small
> enough that the last word or two of each line gets wrapped natively, on top
> of Mailman's wrapping, making any sizable email a difficult read.
>
> ~ MA
>
> On Tue, Sep 22, 2020 at 11:26 PM Gergő Tisza  wrote:
>
> > Yes please. A mere fifty years after the invention of hyperlinks, it
> would
> > be great to adopt them here.
> > ___
> > 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] TechCom meeting 2020-09-23

[Tim Starling]

This is the weekly TechCom board review in preparation of our meeting
on Wednesday. If there are additional topics for TechCom to review,
please let us know by replying to this email. However, please keep
discussion about individual RFCs to the Phabricator tickets.

Activity since Monday 2020-09-13 on the following boards:

https://phabricator.wikimedia.org/tag/techcom/
https://phabricator.wikimedia.org/tag/techcom-rfc/

Committee inbox:

  * Two tasks have been sitting in there for multiple weeks

Committee board activity:

  * RFCs only, see below

New RFCs:

  * None

Phase progression:

  * Timo hid the "Old" column and moved old RFCs to P1. Some had
additional changes or comments.
  * Several were closed by Timo with status "declined", which James
Forrester changed to "invalid".
  * It is hard to find justification for these actions in the linked
RFC process document. There is no mention of it in the committee
meeting minutes for the last three weeks.
  * T157402  Provide a
reliable way to pass information between hook handlers, "hooked"
objects
  o An RFC that was stalled since 2019, closed "declined"
  * T487  Associated namespaces

  o Timo asks if it can be merged with something.
  * T96384 
  * T154675  Introduce a
listener interface for LinkRenderer hooks
  o Closed
  * T259771  Drop support
for database upgrade older than two LTS releases
  o Moved to P3
  * T252091 Site-wide edit
rate limiting with PoolCounter
  o Moved to P2. Timo asks who is stewarding it.
  * T240775  Support PHP
7.4 preload
  o Moved to P3
  * T128351 Notifications
should be in core
  o Some back and forth over the status of this, ending up with it
being P1 and "stalled"
  * T215046 Use Github
login for mediawiki.org
  o Timo closed "declined".
  * T105766 Dependency
graph storage; sketch: adjacency list in DB
  o Timo closed due to lack of owner
  * T484 Scoped language converter
  o Timo closed due to lack of owner
  * T114662 Per-language
URLs for multilingual wiki pages
  o Timo closed due to lack of owner
  * T120380 Allow JSON
values to be included in the API results
  o Timo closed due to lack of owner
  * T193690 How should we
fix the undeletion system?
  o Timo moved to P1 and stalled
  * T113034 Overhaul
Interwiki map, unify with Sites and WikiMap
  o Old -> P1
  * T119043
Graph/Graphoid/Kartographer
- data storage architecture
  o Timo closed due to lack of owner, Yurik's RFC superseded by
Dan's RFC
  * T196950 Pages do not
have stable identifiers
  o Timo closed due to lack of owner
  * T158360 Reevaluate
LocalisationUpdate extension for WMF
  o Old -> P1
  * T181451 WebAssembly and
compiled JS code best practices
  o Old -> P1
  * T114445 Balanced templates
  o Old -> P1
  * T213345 Spin off
(Parsoid) language variants functionality as a microservice?
  o Timo closed due to lack of owner
  * T202673 Multiblocks -
let admins create multiple, overlapping blocks on a single user
  o Old -> P1
  * T111588 API-driven web
front-end
  o Timo closed due to lack of owner
  * T117550 Content bundler
  o Timo closed due to lack of owner
  * T111604 : Split parser
tests info multiple files
  o Timo closed due to lack of owner
  * T106099 Page
composition using service workers and server-side JS fall-back
  o Timo closed due to lack of owner
  * T40010 Re-evaluate
librsvg as SVG renderer on Wikimedia wikis
  o Old -> P1
  * T347 CentralNotice Caching
Overhaul - Frontend Proxy
  o Timo closed due to lack of owner

IRC meeting request:

  * None

Other RFC activity:

  * 

Re: [Wikitech-l] Allow HTML email

[MusikAnimal]

Agreed! The word wrapping especially drives me nuts. My phone is just small
enough that the last word or two of each line gets wrapped natively, on top
of Mailman's wrapping, making any sizable email a difficult read.

~ MA

On Tue, Sep 22, 2020 at 11:26 PM Gergő Tisza  wrote:

> Yes please. A mere fifty years after the invention of hyperlinks, it would
> be great to adopt them here.
> ___
> 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] Allow HTML email

[Timo Tijhof]

+1 for both of these. This would save me some time in the drafting of
Wikitech-l emails.

You will of course still reserve the
right to insert line breaks at your
own discretion to achieve a
particular
visual
fit.-- Timo





On Wed, Sep 23, 2020 at 4:03 AM Tim Starling 
wrote:

> * Should Mailman collapse multipart/alternative to its first part content?
> * Should Mailman convert text/html parts to plain text? This
> conversion happens after MIME attachments have been stripped.
>
> These mailman options are both enabled for this list. I would argue
> that they should both be disabled. It is nice to write emails with
> cutting-edge features like client-side word wrapping and links.
>
> Are there any objections to this change?
>
> -- Tim Starling
>
>
> ___
> 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] Allow HTML email

[Gergő Tisza]

Yes please. A mere fifty years after the invention of hyperlinks, it would
be great to adopt them here.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Allow HTML email

[Tim Starling]

* Should Mailman collapse multipart/alternative to its first part content?
* Should Mailman convert text/html parts to plain text? This
conversion happens after MIME attachments have been stripped.

These mailman options are both enabled for this list. I would argue
that they should both be disabled. It is nice to write emails with
cutting-edge features like client-side word wrapping and links.

Are there any objections to this change?

-- Tim Starling


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

[Wikitech-l] [Data Release] Editors by Country in AQS

[Marcel Ruiz Forns]

Hi everyone!

We're announcing the *release of an API endpoint* that has been requested
for a long time: *Editors by country*.
This data set was already made public in the form of dumps last November
(see email
).
And now it's available via the Analytics Query Service API. Check it out:

   - Get *last month*'s breakdown of *active editors* (5-99 edits) for
*Portuguese
   Wikipedia*:

   
https://wikimedia.org/api/rest_v1/metrics/editors/by-country/pt.wikipedia/5..99-edits/2020/08

   - Get *last January*'s breakdown of *very active editors* (100+ edits)
   for *English Wikipedia*:

   
https://wikimedia.org/api/rest_v1/metrics/editors/by-country/en.wikipedia/100..-edits/2020/01

Two-letter ISO country codes
 are used for
breakdowns.
For more detailed information, refer to the full documentation of the API
endpoint
, or
the documentation of the underlying data

.

As a next step, we'll add the corresponding visualization to Wikistats2
.

Cheers!

On behalf of the Analytics team,
-- 
*Marcel Ruiz Forns** (he/him)*
Senior Software Engineer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l]  Wikimedia production errors help

[Ed Sanders]

Speaking specifically about the new JavaScript error logging, and
specifically to Alex's point about triaging these tasks, it would be very
helpful if the reports included some indication of how often the error is
occurring.

For example, VisualEditor is loaded several hundred thousands times per
day. If an error has occurred 4 times in the last 30 days (based on a
recent example) then it is probably very low priority.

On Thu, 17 Sep 2020 at 16:40, C. Scott Ananian 
wrote:

> ACN -- for what it's worth, I've been working for the foundation for a
> while now, and I can report from the inside that the trend is definitely in
> a positive direction.  There is a lot more internal focus on addressing
> code debt and giving maintenance a fair spot at the table.  (In fact, my
> entire team is now sitting inside 'maintenance' now, apparently; we used to
> be 'platform evolution'.)  This email thread is one visible aspect of that
> focus on code quality, not just features.
>
> That said, the one aspect which hasn't improved much in my time at the
> foundation has been the tendency of teams to work in silos.  This thread
> also seems to be a symptom of that: a bunch of production issues are being
> dropped on the floor ('not resolved in over a month') because they are
> falling between the silos and nobody knows who is best able to fix them.
> There are knowledge/expertise gaps among the silos as well: someone
> qualified to fix a DB issue might be at sea trying to track down a front
> end bug, and vice-versa---a number of generalists in the org could
> technically tackle a bug no matter where it lies, but it will take them
> much longer to grok an unfamiliar codebase than it would for someone more
> familiar with that silo.  So bug triage is an increasingly technical task
> in its own right.
>
> This thread, as I read it sitting inside the org, isn't so much asking for
> more attention to be paid to maintenance -- we're winning that battle,
> internally -- as it is a plea for those folks on the edges of their silos
> to keep an eye out for these things which are currently falling between
> them and help with the triage.
>   --scott, speaking only for myself and my view here
>
>
>
> On Wed, Sep 16, 2020 at 11:25 PM AntiCompositeNumber <
> anticompositenum...@gmail.com> wrote:
>
> > There is an impression among many community members, myself included,
> > that Foundation development generally prioritizes new features over
> > fixing existing problems. Foundation teams will sprint for a few
> > months to put together a minimum viable product, release it, then move
> > on to the new hotness, leaving user requests, bugfixes, and the like
> > behind. It often seems that the only way to get a bug fixed is to get
> > a volunteer developer to look at it. This is likely unintentional, but
> > it happens nonetheless.
> >
> > Putting a higher priority within the Foundation on cleaning up old
> > toys before taking out new ones is necessary for the long-term
> > stability of the projects.
> >
> > ACN
> >
> > On Wed, Sep 16, 2020 at 9:05 PM Dan Andreescu 
> > wrote:
> > >
> > > >
> > > > For example, of the 30 odd backend errors reported in June, 14 were
> > still
> > > > open a month later in July [1], and 12 were still open – three months
> > later
> > > > – in September. The majority of these haven't even yet been triaged,
> > > > assigned assigned or otherwise acknowledged. And meanwhile we've got
> > more
> > > > (non-JavaScript) stuff from July, August and September adding
> > pressure. We
> > > > have to do better.
> > > >
> > > > -- Timo
> > > >
> > >
> > > This feels like it needs some higher level coordination.  Like perhaps
> > > managers getting together and deciding production issues are a priority
> > and
> > > diverting resources dynamically to address them.  Building an awesome
> new
> > > feature will have a lot less impact if the users are hurting from
> growing
> > > disrepair.  It seems to me like if individual contributors and
> > maintainers
> > > could have solved this problem, they would have by now.  I'm a little
> > > worried that the only viable solution right now seems like heroes
> > stepping
> > > up to fix these bugs.
> > >
> > > Concretely, I think expanding something like the Core Platform Team's
> > > clinic duty might work.  Does anyone have a very rough idea of the time
> > it
> > > would take to tackle 293 (wow we went up by a dozen since this thread
> > > started) tasks?
> > > ___
> > > 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
> >
>
>
> --
> (http://cscott.net)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> 

Re: [Wikitech-l] [Wikimedia Tech Talks] (Modern) Event (Data) Platform, Tuesday 22 September 2020 at 17:00 UTC

[Sarah R]

Hi Everyone,

This starts in 30 minutes. Hope to see you there!

On Mon, Sep 21, 2020 at 8:49 AM Sarah R  wrote:

> It's time for Wikimedia Tech Talks 2020 Episode 8! This talk will take
> place Tuesday 22 September 2020 at 17:00 UTC.
>
> Title: (Modern) Event (Data) Platform
>
> Speaker: Andrew Otto, Staff Site Reliability Engineer
>
> Summary:
>
> Wikimedia's Event (Data) Platform provides a foundation for building
> loosely coupled event driven software systems. This talk will go over why
> we built Event Platform and give an overview of its components and how they
> work.
>
> The link to the Youtube Livestream can be found here:
> 
>
>
> https://www.youtube.com/watch?v=Tb_9gOYsWJQ
>
> During the live talk, you are invited to join the discussion on IRC at
> #wikimedia-office
>
> You can browse past Tech Talks here:
> https://www.mediawiki.org/wiki/Tech_talks
>
> If you are interested in giving your own tech talk, you can learn more
> here:
> https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Tech_talks
>
> Note: This is a public talk. Feel free to distribute through appropriate
> email and social channels!
>
> Kindly,
>
> Sarah R. Rodlund
> Senior Technical Writer, Developer Advocacy
> 
> srodl...@wikimedia.org
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Translatable modules

[Amir E. Aharoni]

Hi,

*Crossposting to Wikimedia-L, Wikitech-L, MediaWiki-L, and
Wikitech-Ambassadors. You can reply to the mailing list, but the ideal
place for further discussion is the talk pages of the wiki pages to which I
link below.*

There's a new proposal to localize Lua modules in a more modern, safe, and
convenient manner: https://www.mediawiki.org/wiki/Translatable_modules .

In the foreseeable future it will only affect multilingual sites, such as
Wikidata, Commons, Meta, and mediawiki.org, but at a later time it may also
be deployed on Wikipedias and other projects.

It will be great if experienced module developers could take a look at the
project page, https://www.mediawiki.org/wiki/Translatable_modules , and its
subpages, especially https://www.mediawiki.org/wiki/Translatable
modules/Proposed solutions . Your feedback will be very helpful in
implementing this project in a way that really benefits all the editors.

Thanks!

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l