[Wikitech-l] Sign up for the Toolhub's quality signal sessions

2021-07-27 Thread Srishti Sethi
Hello all,

We invite you all to sign up for Toolhub's Quality Signal sessions!

Toolhub  [1] is a
community-authored catalog of Wikimedia tools. On Toolhub, you will be able
to discover new tools in the Wikimedia ecosystem, promote their use in your
wiki community, and help improve them by contributing data. Toolhub's first
release is planned around Wikimania 2021.

The Toolhub team is currently working on identifying quality indicators
through conversations with tool users and developers. As a tool user, how
do you know which tool is reliable, useful, and safe to use? As a tool
maintainer, what makes it attractive to you to contribute to an existing
tool? What information are you looking for to decide whether to join a tool
project? We hope that these sessions will help gather quality indicators
for tools and provide valuable insight toward developing new features to
convey the quality.

Want to organize a quality signal session in your community in August/early
September? Please get in touch on the talk page or sign-up for an already
planned session by adding your name below it: <
https://meta.wikimedia.org/wiki/Toolhub/The_Quality_Signal_Sessions> [2].
Your feedback, thoughts, ideas would be valuable!

If you are attending Wikimania, we are running a few introductions and a
feedback session as part of the unconference. Learn more here: <
https://wikimania.wikimedia.org/wiki/2021:Unconference/Toolhub> [3].

Cheers,
Srishti

On behalf of the Toolhub team

[1] https://meta.wikimedia.org/wiki/Toolhub

[2] https://meta.wikimedia.org/wiki/Toolhub/The_Quality_Signal_Sessions

[3] https://wikimania.wikimedia.org/wiki/2021:Unconference/Toolhub

*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation 
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] New experimental backend for the Wikimedia Debug browser extension: what to expect

2021-07-27 Thread Giuseppe Lavagetto
Hi all,

This email is of interest to you only if you're a user of the "Wikimedia
Debug" browser extension. If you're not, you can safely skip it.

As the more attentive might have noticed, the Wikimedia Debug browser
extension started offering a new option in the drop-down menu, besides the
usual mwdebug servers, labeled "k8s-experimental". That is, as the name
suggests, a very experimental setup of mediawiki running on kubernetes and
is not *yet* a place where you will be able to test your releases.

Right now, that installation is a work in progress, but nonetheless it
seemed important to us to have a way to browse the wikis from the
installation running on kubernetes while we iron out bugs in preparation
for the actual migration of production traffic.

This installation can thus:
- run on outdated versions of mediawiki (although we're trying to follow
train releases).
-  be down for extended periods of time while we debug something, without
warning.
It also doesn't support (yet) profiling via xhprof.

So while we welcome the curious to poke around at the performance and bugs
of the installation, it is not a suitable tool (yet) to debug your releases
on.

I will add filters where appropriate to avoid logs from this installation
from polluting your dashboards in the coming days, but in the meantime, if
you see a log line coming from a server with a strange name like
"mediawiki-pinkunicorn"... that's mediawiki running on kubernetes and you
can mostly ignore it!

You can follow our progress at https://phabricator.wikimedia.org/T283056

Cheers,

Giuseppe

-- 
Giuseppe Lavagetto
Principal Site Reliability Engineer, Wikimedia Foundation
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: [MediaWiki-l] Replacing jQuery's hasClass() in MW extension JS code

2021-07-27 Thread James Forrester
[Moving to wikitech-l; mediawiki-l is a little off-topic.]

On Mon, 26 Jul 2021 at 21:27, Yaron Koren  wrote:

> Hi,
>
> I've been trying to get rid of the ESLint warnings for the JavaScript code
> in some of my extensions, when they go through Jenkins validation. One
> warning that appears fairly often is this one:
>
> Where possible, maintain application state in JS to avoid slower DOM
> queries
> no-jquery/no-class-state
>
>
> I'm not sure if this is a warning that's specific to Wikimedia code, but
> doing a web search on it brings up this Wikimedia help page as the only
> real result:
>
>
> https://github.com/wikimedia/eslint-plugin-no-jquery/blob/master/docs/rules/no-class-state.md
>

Yes, we forked the dead "jquery" upstream eslint plugin and have expanded
it significantly. In general, the plugin's purpose
 is to discourage
use of jQuery functions, especially where the functions are deprecated or
have faster native equivalents. (Almost all uses of jQuery are no longer
necessary given that the vast majority of the Web only runs on
modern-enough browsers.)


This page is rather confusing. It says that the warning comes when calling
> either hasClass() or toggleClass() on a jQuery element. That part makes
> sense, but then the suggested alternatives are strange. The page says that
> the following are some examples of bad code:
>
> $( 'div' ).hasClass();
> $div.hasClass();
>
> In their place, it suggests the following:
>
> hasClass();
> [].hasClass();
> div.hasClass();
>

No, it doesn't. It says that our code is clever enough to not think that
these false positives are issues that you need to fix. It's not saying you
should use a method called hasClass(); it's saying that you should maintain
state inside JS; this is principally a performance/code smell test.

If your code is triggered from a non-JS DOM (e.g. painted from PHP), the
first time you grab state from the DOM is unavoidable (and so you'd use an
inline disable), but thereafter you should keep track of such details in
JS. An example of this is in the initialisation code for Notifications
("Echo"), where it has to grab the state from the DOM

for a couple of items, but does so only once.

Sorry that this is confusing! We could put together a narrow JS tips and
tricks page and link to that from the linter, but most of these have been
fixed over the years since we introduced this in Wikimedia production code
so there's not been much call.

J.
-- 
*James D. Forrester* (he/him  or they/themself
)
Wikimedia Foundation 
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/