Re: [Wikitech-l] Allow HTML email

[Max Semenik]

On Thu, Sep 24, 2020 at 12:55 AM AntiCompositeNumber <
anticompositenum...@gmail.com> wrote:

> *HTML email is a scourge.*
>

Welcome to the future! Every new thing introduces new problems, but we
kinda can't stop the progress.

-- 
Best regards,
Max Semenik
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Allow HTML email

[AntiCompositeNumber]

*HTML email is a scourge.*

On Wed, Sep 23, 2020 at 9:35 AM Chris Danis  wrote:

> On Wed, Sep 23, 2020 at 9:22 AM Faidon Liambotis 
> wrote:
> > On behalf of the Mutt & other console email clients user club, we
> > approve of this change. We haven't formed consensus on it yet, but I
> > suspect we'd even be willing to go one step further and negotiate the
> > use of emojis as well (perhaps even emojis in subject lines). No
> > promises for responding in HTML, though; that's probably going to have
> > to wait another century.
>
>  
>
> In at least the past couple years of Linux distribution releases,
> graphical terminals generally do a good job of emoji rendering by default,
> for what it's worth. 
>
> If you find emoji rendering amiss on your Debian-like system, I recommend
> first
>
>   apt install fonts-noto-color-emoji
>
> and then installing this ~/.config/fontconfig/fonts.conf:
> https://phabricator.wikimedia.org/P12767
>
>
> Keep it ,
>
> --
> Chris Danis (he/him)
> Staff Site Reliability Engineer
> Wikimedia Foundation
> ___
> 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] Security pre-release announcement: 1.31.9 / 1.34.3 / 1.35.0

[Sam Reed]

Hi all,

Tomorrow we will be issuing a security and maintenance release to all
supported branches of MediaWiki.

The new releases will be:

- 1.34.3
- 1.31.9

This will resolve eight issues in MediaWiki core (two of which aren't
applicable to MediaWiki 1.31), and also includes some fixes previously
committed to git, including minor security and hardening patches along with
bug fixes included for maintenance reasons.

For those of you waiting on MediaWiki 1.35.0, this will also come either
tomorrow, or at latest Friday (depending on CI load), including the
security fixes applied to these other supported release branches. We thank
you for your patience; the current global situation means things have taken
longer than would have been expected, but it has meant more bug fixes being
incorporated from testing across the board. It also meant not having a
security 1.35.1 release followup only a couple of weeks after 1.35.0 coming
out. Which, for many people would mean extra work to upgrade again, and it
was decided to avoid this.

We will make the fixes available in these respective release branches, and
also master. Tarballs will be available for the above mentioned point
releases as well.

A summary of some of the security fixes that have gone into non-bundled
MediaWiki extensions will also follow.

As per the MediaWiki Version lifecycle [1], November 2020 is the scheduled
EOL date for the REL1_34. 1.34.3 will therefore potentially be the final
release of the MediaWiki 1.34 branch, barring any unforeseen issues. As per
above, MediaWiki 1.35.0 will be released this week, and will be supported
until at least September 2023, and would be the recommended upgrade path.

[1] https://www.mediawiki.org/wiki/Version_lifecycle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Production Excellence #23: July & August 2020

[Krinkle]

 Read on Phabricator at
https://phabricator.wikimedia.org/phame/post/view/204/
---

How’d we do in our strive for operational excellence last month? Read on to
find out!

##    *Incidents*

4 documented incidents in July, and 2 documented incidents in August. [1]
Historically, that's on average for this time of year. [5]

For more about recent incidents see Incident documentation
 on Wikitech,
or Preventive measures
 in Phabricator.

---

##    *Tre**nds*

Take a look at the workboard and look for tasks that could use your help.
→ https://phabricator.wikimedia.org/tag/wikimedia-production-error/

Summary over recent months:

   - ⚠️ July 2019 (4 of 18 tasks left): One task closed.
   - ⚠️ August 2019 (1 of 14 tasks left): *no change.*
   - ⚠️ September 2019 (3 of 12 tasks left): Two tasks closed.
   - October (6 of 12 tasks left), *no change.*
   - November (3 of 5 tasks left): *no change.*
   - December (3 of 9 tasks left), Two tasks closed.
   - January 2020 (5 of 7 tasks lef), *no change.*
   - February (2 of 7 tasks left), Two tasks closed.
   - March (2 of 2 tasks left), *no change.*
   - April (10 of 14 tasks left): One task closed.
   - May (7 of 14 tasks left): Four tasks closed.
   - June (10 of 14 tasks left): Four tasks closed.
   - July 2020: 13 of 24 new tasks
   
   survived the month of July and remain open today.
   - August 2020: 37 of 53 new tasks
   
   survived the month of August and remain open today.

Recent tally:
72  open, as of Excellence #22

(Jul 23rd).
-16  closed, of the previous 72 recent tasks.
+13  opened and survived July 2020.
+37  opened and survived August 2020.
106  open, as of today (Sep 23rd).

Previously
,
we had 72 open production errors over the recent months up to June. Since
then, 16 of those were closed. But, the 13 and 37 errors surviving July and
August raise our recent tally to 106.

The workboard overall (including tasks from 2019 and earlier) held 192 open
production errors on July 23rd. As of writing, the workboard holds 296 open
tasks in total. [4] This +104 increase is largely due to the merged backlog
of JavaScript client errors, which were previously untracked. Note that we
backdated the majority of these JS errors under “Old”, and thus are not
amongst the elevated numbers of July and August.

---

   *Thanks!*

Thank you to everyone else who helped by reporting, investigating, or
resolving problems in Wikimedia production. Thanks!

Until next time,

– Timo Tijhof

---


Footnotes:
[1] Incidents. – https://wikitech.wikimedia.org/wiki/Incident_documentation

[2] Tasks created. – https://phabricator.wikimedia.org/maniphest/query…

[3] Tasks closed. – https://phabricator.wikimedia.org/maniphest/query…

[4] Open tasks. – https://phabricator.wikimedia.org/maniphest/query…

[5] Wikimedia incident stats. – https://codepen.io/Krinkle/full/wbYMZK
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Coolest Tool Award 2020: Call for nominations!

[Joaquin Oltra Hernandez]

Dear all,

We’re really happy to announce the second edition of the Coolest Tool Award
!

Tools play an essential role at Wikimedia, and so do the many volunteer
developers who experiment with new ideas, develop & maintain local & global
solutions and enhance the experience for Wikimedia communities.

There are incredible many great tools out there. It’s time to celebrate
this & to make the great work volunteer developers do more visible to
everyone :-)

The Coolest Tool Award ceremony will take place virtually this year, given
the current circumstances around events and travel. We will provide more
details soon about the specific logistics and dates.

The award is organized & selected by the *Coolest Tool Academy 2020*
.
We plan to recognize the greatest tools in a variety of categories, for
examples you can look at last year’s categories
.

As no one can possibly know all the cool tools out there, we’re looking for
some help & inspiration: Please point us to the tools that you think are
great - out of any reason you can think of!

Please use this form:
https://docs.google.com/forms/d/e/1FAIpQLSf5ZmXXamn9sRsagEiiZcUZDn1Ga0sF3XmdPf0OjZWtILZvdQ/viewform
to recommend tools *by October 14, 2020*. You can nominate as many tools as
you want by filling out the form multiple times.

This survey will be conducted via a third-party service, which may subject
it to additional terms. For more information on privacy and data-handling,
see the survey privacy statement:
https://foundation.wikimedia.org/wiki/Coolest_Tool_Award_2020_Survey_Privacy_Statement

Thank you very much for your ideas & recommendation(s)!

We will continue to spread the word over the next 1-2 days, but if you get
the chance, please feel welcome to share this information with others too!

Thanks :-)
Joaquin, for the Coolest Tool Academy 2020

-- 
Joaquin Oltra Hernandez
Developer Advocate - Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Spell4Wiki App - Audio Upload Tool for Wikimedia Commons

[Manimaran_K]

Hello all,


Happy to invite you to contribute your voice for wiktionary words using
Spell4Wiki android application.

'Spell4Wiki' a GPLv3 licensed app to record and upload audio for Wiktionary
words to Wikimedia Commons. The app is also a multilingual dictionary based
on Wiktionary. This app was developed collaboratively by Kaniyam
Foundation, Villupuram GNU/Linux Users Group, various FOSS activists and
the Tamil Wiki Community.

App Link :
https://play.google.com/store/apps/details?id=com.manimarank.spell4wiki

Note : Shortly release on F-Droid also. We started the process.

You can look here : https://gitlab.com/fdroid/rfp/-/issues/1490

Below I shared links that have a detailed working process and development
history of Spell4Wiki app. Everyone please look into this. That helps to
understand how this FOSS tool made possible.


Release and History of Development

Tamil :
https://manimaran96.wordpress.com/2020/06/26/spell4wiki-app-release-and-history-of-development/

English :
https://manimaran96.wordpress.com/2020/09/11/spell4wiki-app-release-history-of-development-en/

More details : https://commons.wikimedia.org/wiki/Commons:Spell4Wiki

Source code : https://github.com/manimaran96/Spell4Wiki

Videos :

Introduction - https://youtu.be/IMku3FL7s3I

How to Use[Tamil] - https://youtu.be/4y5I1sUW1ys

How to Use[English] - https://youtu.be/Fu4kQcv04kA

Credits goes to

- Kaniyam Foundation(http://www.kaniyam.com/) ,

- VGLUG(https://vglug.org/) ,

- All FOSS activists who have contributed (
https://github.com/manimaran96/Spell4Wiki#credits-to) and

- Tamil Wiki Community(https://en.wikipedia.org/wiki/Tamil_Wikipedia)


Also, Thanks to FSHM(https://fshm.in/) for recommending the Spell4Wiki App
to their circle.

Install, Use and share your feedback.

Contribution guidelines details :
https://github.com/manimaran96/Spell4Wiki/blob/master/docs/CONTRIBUTING.md

Communication details :

https://github.com/manimaran96/Spell4Wiki/blob/master/docs/CONTRIBUTING.md#communication

Thanks

Manimaran K


-- 
Manimaran K
https://manimaran96.wordpress.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Require tag for API writes

[Hogan (US), Michael C]

Hi, is there an example that shows how to reject writeapi edits made using 
scripts unless the edit has a required tag? For example, changes made using 
Visual Editor are labeled with “(Tag: Visual edit)”.

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

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

[Jon Robson]

Id be careful about using numbers in triage right now. The numbers are a
little misleading as the error logging is only enabled on smaller wikis.
Also if an error results in data loss but only impacts a small amount of
people I would say that's worse than a benign error that occurs for lots.

We rolled out to Spanish, German and Japanese wikipedia yesterday so these
numbers will start becoming more useful, but English Wikipedia will
severely skew these numbers when we finally enable it.

On Tue, Sep 22, 2020, 9:59 AM Ed Sanders  wrote:

> 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 <
> dandree...@wikimedia.org>
> > > 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.
> > > >
> > > > 

Re: [Wikitech-l] Allow HTML email

[Chris Danis]

On Wed, Sep 23, 2020 at 9:22 AM Faidon Liambotis 
wrote:
> On behalf of the Mutt & other console email clients user club, we
> approve of this change. We haven't formed consensus on it yet, but I
> suspect we'd even be willing to go one step further and negotiate the
> use of emojis as well (perhaps even emojis in subject lines). No
> promises for responding in HTML, though; that's probably going to have
> to wait another century.

 

In at least the past couple years of Linux distribution releases, graphical
terminals generally do a good job of emoji rendering by default, for what
it's worth. 

If you find emoji rendering amiss on your Debian-like system, I recommend
first

  apt install fonts-noto-color-emoji

and then installing this ~/.config/fontconfig/fonts.conf:
https://phabricator.wikimedia.org/P12767


Keep it ,

-- 
Chris Danis (he/him)
Staff Site Reliability Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Allow HTML email

[Roy Smith]

As long as you guys keep the B-News  
bi-directional gateway functioning, I'm fine.  And, please, make sure you strip 
any leading whitespace so as not to tickle the line-eater.

> On Sep 23, 2020, at 9:21 AM, Faidon Liambotis  wrote:
> 
> On Wed, Sep 23, 2020 at 02:45:37PM +1000, Tim Starling wrote:
>> 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  ;)
> 
> On behalf of the Mutt & other console email clients user club, we
> approve of this change. We haven't formed consensus on it yet, but I
> suspect we'd even be willing to go one step further and negotiate the
> use of emojis as well (perhaps even emojis in subject lines). No
> promises for responding in HTML, though; that's probably going to have
> to wait another century.
> 
> Faidon
> 
> ___
> 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

[Faidon Liambotis]

On Wed, Sep 23, 2020 at 02:45:37PM +1000, Tim Starling wrote:
> 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  ;)

On behalf of the Mutt & other console email clients user club, we
approve of this change. We haven't formed consensus on it yet, but I
suspect we'd even be willing to go one step further and negotiate the
use of emojis as well (perhaps even emojis in subject lines). No
promises for responding in HTML, though; that's probably going to have
to wait another century.

Faidon

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

Re: [Wikitech-l] Allow HTML email

[Steve Summit via Wikitech-l]

Tim Starling wrote:
> 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...

I'm not Faidon, and I'm not even a regular contributor to this list,
but as a data point of almost vanishingly possible interest, I can
say that the above isn't even much of an exaggeration for the
suitably old-guard set.  Me, I read mail using a shell script
'mshow', which boils down to a selective cat from $MAIL into more,
and gratuitous base-64 encoding is indeed an issue, causing me to
pretty regularly have to type

mshow | mailbody | b64 -d | more

I have really got to automate that some day.

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

Re: [Wikitech-l] Allow HTML email

[Federico Leva (Nemo)]

It's fine to allow HTML email, but doing so shifts on the users the
burden of fixing their clients so that they produce suitable multipart
emails before sending them to the list. With some common email clients
and providers (e.g. Gmail webmail) it's surprisingly easy to produce
utterly unreadable HTML which wouldn't pass even the most lenient
accessibility scrutiny.

Federico

___
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

[Daniel Kinzler]

Thanks Tim! And thanks to Timo for going through the old RFCs. We haven't done
that in a while.

Besides the RFCs, I'd like to talk about the GitLab consultation in our meting
tomorrow: https://www.mediawiki.org/wiki/GitLab_consultation

TechCom is listed under "consulted", so I suppose we should form an opinion.

Am 23.09.20 um 06:37 schrieb Tim Starling:
> Two tasks have been sitting in there for multiple weeks

Ah, I guess that'S why they didn't show up under "activity". One is the Parsoid
Extension API RFC mentioned below. The other one is T239742
: "Should npm packages maintained by
Wikimedia be scoped or unscoped?"

>   * T157402  Provide a reliable way
> to pass information between hook handlers, "hooked" objects
>   o An RFC that was stalled since 2019, closed "declined"
>
Probably obsolete due to the new hook system.
>
>   * T487  Associated namespaces
> 
>   o Timo asks if it can be merged with something.
>
I think we can close this, the intended use cases are covered by MCR.
>
>   * T114662 Per-language URLs for
> multilingual wiki pages
>   o Timo closed due to lack of owner
>
I'd like to  come back to this eventually. But I don't see anyone driving it
right now.
>
>   * T193690 How should we fix the
> undeletion system?
>   o Timo moved to P1 and stalled
>
This does need fixing, but is entangled with UX and producty questions. Nothing
is going to happen unless the community pushes on it. Which will probably only
happen once something breaks badly.
>
>   * T196950 Pages do not have
> stable identifiers
>   o Timo closed due to lack of owner
>
Page IDs are "mostly" stable these days, right?
>
>   * T260714  Parsoid Extension API
>   o Prior to last week's meeting, Subbu described the consultation work
> that has been done.
>   o Suggest last call
>
Yea, let's.

-- 
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation

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

Re: [Wikitech-l] Allow HTML email

[Daniel Kinzler]

Thanks Tim.

This prompted me to finally switch to composing mails in HTML per default, like
it's the 21st century.

Am 23.09.20 um 06:45 schrieb Tim Starling:
> OK done, and it seems to be working.
>
-- 
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation

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