Re: [Wikitech-l] What would you like to see in gerrit?

[Gergo Tisza]

On Mon, Jan 28, 2019 at 4:26 PM Paladox via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

> Hi, what would you like to see in gerrit or improved?


Thanks for all your work on Gerrit! Some things that IMO would be useful:
* filtering out CI messages from Gerrit comments. This is something the
next version of Gerrit supports (the "Only comments" checkbox), but I
imagine something somewhere must be changed so that it can identify bots.
* making it clearer when CI fails. Currently it's hard to visually
differentiate failed tests from successful tests, and within failed test
logs the exact reason for failure from all the other logs. I guess this is
more of a Jenkins improvement...
* I really miss the Github feature of selecting a line range (as opposed to
a single line) from the gitiles plugin.
* again not really a Gerrit change but our mechanism for linking Gerrit
patches to related Phabricator tasks is rather crude. T95309 has some
related discussion but a nice solution would probably not include
comments/tags and use something more specialized like a custom Maniphest
field type instead. Or maybe a frontend hack like Pherrit [1].

[1]
https://chrome.google.com/webstore/detail/pherrit/polcefipbgcdfkpbmmbdjgkgfgjoebij
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes to the Block paradigm

[Pine W]

Hello 80hnhtv4agou,

I believe that any allegations of misconduct by admins or stewards should
be addressed in a separate thread, and most likely not on Wikitech-l unless
you a referring to an incident that happened in a location that focuses on
technical matters such as Phabricator. In most cases I would caution
against trying to address an allegation in multiple venues simultaneously
because many Wikimedians have heavy workloads and have limited willingness
to read about the same conflict multiple times. Some projects have clearly
defined routes for appealing certain administrative actions, but others do
not. If you would like information about how to make an appeal or report an
allegation of misconduct then those questions are probably better suited to
Wikimedia-l, an OTRS ticket, or to the Wikimedia Forum on Meta (
https://meta.wikimedia.org/wiki/Wikimedia_Forum).

Keeping threads on topic is courteous to others, so I request that if you
have further questions regarding allegations of misconduct then please
raise them at one of the places that I mentioned instead of in this thread.

Thanks,

Pine
( https://meta.wikimedia.org/wiki/User:Pine )


On Mon, Feb 4, 2019 at 11:02 PM 80hnhtv4agou--- via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

>
> what about abuse by administrators and stewards ?
>
> From: Moriel Schottlender
> Sent: Monday, January 7, 2019 7:53 PM
> To: Wikimedia developers ;  wikitech-ambassad...@lists.wikimedia.org
> Subject: [Wikitech-l] Changes to the Block
> paradigm
>
> Greetings,
>
> Have
> you written code that deals with or depends on user blocks? Read on.
>
> =
> TL;DR: =
>
> The new “Partial Blocks” feature has fundamentally changed the
> way MediaWiki
> considers what “block” means; any code that handles blocks
> should consider
> whether the questions it is asking are still valid or should
> adjust its
> expectations. Please read for more details.
>
> = Preamble
> =
>
> A couple of months ago, as part of the Anti Harassment Tools
> team’s
> continued work on improving the general experience of our users
> and
> providing more robust tools to administrators, an RFC to enable
> “Partial
> Blocks[1]” has passed and has been implemented in MediaWiki,
> affecting the
> way blocking users operates.
>
> While the actual feature,
> enabling the blocking of users for specific pages
> and namespaces, will be
> slowly rolled out as part of our rollout and
> testing plans, the change has
> resulted in a complete change of paradigm for
> what “block” means throughout
> our code.
>
> = Change of paradigm =
>
> Until recently, Block was fairly
> straight forward; whether a block was done
> on an IP range or a specific user,
> the question the code would ask is “is
> the user blocked from this action” and
> the answer will be a boolean yes or
> no, depending on whether the user was
> blocked from the wiki and whether the
> action was a blockable
> action.
>
> With the new Partial Blocks feature, that question is now more
> elaborate.
> We are giving admins and wikis in general much more robust options
> when
> deciding to block IPs or users. “Sitewide” block is no longer the
> only
> option. Now, a user can be blocked from editing a specific page, and
> soon
> from a specific namespace. There are also blocks that prevent a
> specific
> action, such as uploading files or creating new pages.
>
> This
> means that the question “is the user blocked” is no longer accurate.
> In most
> cases, the question should be “is the user blocked from the action
> on this
> page”, because users may receive a block that is not sitewide, but
> from a
> specific page or set of pages.
>
> = What we worked on =
>
> The Anti
> Harassment Tools team has been working diligently on making sure
> that the new
> blocking behavior does not produce obvious regressions in
> production, and
> does not add to any still existing inconsistencies. In
> cases where we
> identified a clear mismatch, we’ve tried to either fix it
> outright or alert
> the code owners to adjust.
>
> If we have missed any iteration or use-case,
> please open a Phabricator
> ticket and add the ‘anti-harassment’[2] tag to it.
> If the use-case is
> sensitive or identifies a current loop-hole in the way
> blocks work, please
> make it a security ticket and alert us and the relevant
> team immediately.
>
> = General steps forward =
>
> While the team is
> following up on making the code clear and robust and
> fixing what we’ve
> identified as paradigm-changes to deal with, there are
> still many instances
> where the changes required to the code are not
> straight-forward or clear.
> Some extensions ask whether a user is blocked
> and may need to change the way
> that the product’s “business logic” behaves.
>
> These are cases where we
> cannot make the decision for the codebase. We
> encourage you to look at your
> product and consider adjusting if necessary.
>
> = General guidance
> =
>
> We’ve identified some areas that may help code owners ad

Re: [Wikitech-l] Changes to the Block paradigm

[80hnhtv4agou--- via Wikitech-l]

what about abuse by administrators and stewards ?
 
From: Moriel Schottlender
Sent: Monday, January 7, 2019 7:53 PM
To: Wikimedia developers ;  wikitech-ambassad...@lists.wikimedia.org
Subject: [Wikitech-l] Changes to the Block 
paradigm
 
Greetings,

Have 
you written code that deals with or depends on user blocks? Read on.

= 
TL;DR: =

The new “Partial Blocks” feature has fundamentally changed the 
way MediaWiki
considers what “block” means; any code that handles blocks 
should consider
whether the questions it is asking are still valid or should 
adjust its
expectations. Please read for more details.

= Preamble 
=

A couple of months ago, as part of the Anti Harassment Tools 
team’s
continued work on improving the general experience of our users 
and
providing more robust tools to administrators, an RFC to enable 
“Partial
Blocks[1]” has passed and has been implemented in MediaWiki, 
affecting the
way blocking users operates.

While the actual feature, 
enabling the blocking of users for specific pages
and namespaces, will be 
slowly rolled out as part of our rollout and
testing plans, the change has 
resulted in a complete change of paradigm for
what “block” means throughout 
our code.

= Change of paradigm =

Until recently, Block was fairly 
straight forward; whether a block was done
on an IP range or a specific user, 
the question the code would ask is “is
the user blocked from this action” and 
the answer will be a boolean yes or
no, depending on whether the user was 
blocked from the wiki and whether the
action was a blockable 
action.

With the new Partial Blocks feature, that question is now more 
elaborate.
We are giving admins and wikis in general much more robust options 
when
deciding to block IPs or users. “Sitewide” block is no longer the 
only
option. Now, a user can be blocked from editing a specific page, and 
soon
from a specific namespace. There are also blocks that prevent a 
specific
action, such as uploading files or creating new pages.

This 
means that the question “is the user blocked” is no longer accurate.
In most 
cases, the question should be “is the user blocked from the action
on this 
page”, because users may receive a block that is not sitewide, but
from a 
specific page or set of pages.

= What we worked on =

The Anti 
Harassment Tools team has been working diligently on making sure
that the new 
blocking behavior does not produce obvious regressions in
production, and 
does not add to any still existing inconsistencies. In
cases where we 
identified a clear mismatch, we’ve tried to either fix it
outright or alert 
the code owners to adjust.

If we have missed any iteration or use-case, 
please open a Phabricator
ticket and add the ‘anti-harassment’[2] tag to it. 
If the use-case is
sensitive or identifies a current loop-hole in the way 
blocks work, please
make it a security ticket and alert us and the relevant 
team immediately.

= General steps forward =

While the team is 
following up on making the code clear and robust and
fixing what we’ve 
identified as paradigm-changes to deal with, there are
still many instances 
where the changes required to the code are not
straight-forward or clear. 
Some extensions ask whether a user is blocked
and may need to change the way 
that the product’s “business logic” behaves.

These are cases where we 
cannot make the decision for the codebase. We
encourage you to look at your 
product and consider adjusting if necessary.

= General guidance 
=

We’ve identified some areas that may help code owners adjust their 
products
to properly take advantage of the new feature and adjust to the 
new
paradigm change. This list is not exhaustive, but may help you spot 
areas
in your code that can easily be changed:

* User::isBlocked() has 
changed its meaning, and its use cases should be
re-examined depending on 
what your code intends to check.
For the most part, if there’s a Title object 
available,
User::isBlockedFrom() is a good option. Otherwise, consider 
using
User::getBlock() and Block::isSitewide()
* Block::prevents( ‘edit’ ) 
is an operation that doesn’t make sense
anymore, because a block on the 
‘edit’ action now depends on context (the
title).
* Determining whether a 
block prevents a user from editing their own user
talk page has 
changed.
For a sitewide block, if the $wgBlockAllowsUTEdit config is false, 
then the
block prevents the user editing their user talk page, but if it is 
true,
then whether they can edit their user talk page depends on 
the
ipb_allow_usertalk flag on the block. For a partial block to a page 
or
pages, these flags are not taken into account: if the user’s talk page 
is
specified as a blocked page, then they cannot edit their user talk page; 
if
it is not, then they can edit it. Block::prevents( ‘editownuserpage’ 
)
should therefore not be checked for a partial page block[3].  We plan 
to
deprecate that parameter officially, please consider if this affects 
your
code.
* Please check that any classe

Re: [Wikitech-l] [Commons-l] Sunsetting VP8 version of WebM for video playback

[Gergo Tisza]

On Mon, Jan 28, 2019 at 12:22 PM Brion Vibber via Commons-l <
common...@lists.wikimedia.org> wrote:

> IE 11 users will receive low-resolution, slow JavaScript-based video
> playback instead. If you find this is troublesome, the recommended solution
> is to switch to any other browser.
>

Will they get a warning that they should try another browser? This seems
like a sensible limitation, as long as the user has a chance of figuring
out why they are being limited.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The mw.ext construct in lua modules

[Eran Rosenthal]

> What is the problem with the ".ext" part?
1. It adds unnecessary complexity both in the extension (need to init
mw.ext if it doesn't exist) and more important - in its usage when the Lua
extension is invoked (longer names)
   (there is very small risk of name collision -  mw.ModuleA and mw.ModuleB
are unlikely to clash as different extensions, and mw.ModuleA and mw.FUNC
are unlikely to clash because function names

are usually verbs and extensions
 are usually nouns)
2. Practically the convention is to not use mw.ext - the convention (based
on most of the Lua code - e.g wikibase) is to not use mw.ext

> What is the benefit of moving existing code that is so heavily used?
consistency and alignment to some code convention (2). [keeping backward
compatibility can be with mw.wikibase=mw.ext.wikibase with deprecation
notice]
If we believe ext is good convention we should drive to align it and at
least to allow usages

to align to that convention.  (google counts 3K usages - if we don't fix
it, it will be much harder to fix it later)
if we don't believe this is good convention, we shouldn't impose it on new
Lua extensions.

Thanks,
Eran





On Mon, Feb 4, 2019 at 4:13 PM Thiemo Kreuz 
wrote:

> > […] I think mw.ext.EXTNAME should be avoided […]
>
> Can I ask to provide arguments that help others understand this
> opinion better? What is the problem with the ".ext" part?
>
> > […] or we should reject this proposal and open phab ticket to wikibase
> to change mw.wikibase to mw.ext.wikibase everywhere […]
>
> How is this an unavoidable consequence of deciding on a standard new
> code should follow? What is the benefit of moving existing code that
> is so heavily used?
>
> Kind regards
> Thiemo
>
> ___
> 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] Discovery Weekly Update for the week starting 2019-01-21

[Chris Koerner]

Hello,
This is the weekly update from the Search Platform team for the week
starting 2019-01-21 (acknowledging a little delay).

As always, feedback and questions welcome.

== Discussions ==

=== Search ===

* Trey did a write up about his ideas for the wrong keyboard
implementation and UI, and the new language models and parameter
optimization for TextCat for the wrong-keyboard and wrong-encoding
detection. [0]
* Trey also reviewed, updated and manually re-built the Hebmorph
plugin for ElasticSearch 6 with help from the rest of the Search team
[1]
* David double checked that chi to psi/omega indices are no longer
used and delete them. [2]
* David also worked on dropping the "archive" type in the general index [3]
* David wrapped up on moving the phrase suggest related code to its
FallbackMethod [4]
* Erik worked on modifying Wikidata entity completion search for
per-language tuning parameters [5]
* Erik also worked on a bug where we didn't retain cross-cluster
identifier in OtherIndexes [6]
* Erik fulfilled a feature request to add chronological sorting
by-page-creation-timestamp for search results [7]
* David also upgraded the Elasticsearch plugins extra, extra-analysis
and highlighter to elasticsearch 6.5.4 [8]
* Stas is working on separating ElasticSearch parts of Wikibase into a
separate extension [9]

[0] 
[https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Implementation_Design_and_Parameter_Optimization_for_Wrong_Keyboard_Detection_and_Suggestion
[1] https://phabricator.wikimedia.org/T214439
[2] https://phabricator.wikimedia.org/T214052
[3] https://phabricator.wikimedia.org/T200198
[4] https://phabricator.wikimedia.org/T213098
[5] https://phabricator.wikimedia.org/T213106
[6] https://phabricator.wikimedia.org/T214050
[7] https://phabricator.wikimedia.org/T195071
[8] https://phabricator.wikimedia.org/T214312
[9] https://phabricator.wikimedia.org/T190022



Subscribe to receive on-wiki (or opt-in email) notifications of the
Discovery weekly update.

https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly

The archive of all past updates can be found on MediaWiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

Interested in getting involved? See tasks marked as "Easy" or
"Volunteer needed" in Phabricator.

[1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R
[2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R

Yours,
Chris Koerner (he/him)
Community Relations Specialist
Wikimedia Foundation

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

Re: [Wikitech-l] Announcing zuul-status plugin for gerrit

[Paladox via Wikitech-l]

 Thank you both for the nice comments! The plugin will be coming soon to 
gerrit.wikimedia.org! (already plans for it)
On Wednesday, 30 January 2019, 21:16:10 GMT, Derick Alangi 
 wrote:  
 
 Hi,

Thanks a lot @Paladox for this wonderful plugin on the way. Sometimes, I
see myself on the zuul dashboard to know if something is wrong with my
patch by monitoring the build progress. With such a plugin, I'll reduce
hitting the zuul interface and monitor the build on Gerrit UI, nice!

I'm personally a fan of UI changes, I just have a thing for it, that's why
the recent changes on the UI (colors etc) are making me go crazy, nice nice
nice! Thanks for all your work and those you're working with to make these
all possible :)

We're grateful!

*--*
*Derick*


On Wed, Jan 30, 2019 at 7:08 PM Adam Wight  wrote:

> Yes!  That's awesome, and thank you Paladox for your tireless pushing
> towards modernity!  I'm looking forward to enjoying the plugin…
>
> -Adam
>
> On Wed, Jan 30, 2019 at 9:58 AM Paladox via Wikitech-l <
> wikitech-l@lists.wikimedia.org> wrote:
>
> > Hi, i am pleased to announce that the zuul-status plugin is now available
> > for gerrit 2.16+.
> > This plugin integrates the zuul status json response into gerrit
> > displaying the jobs lined up and running. It's similar to how you would
> see
> > it on  https://integration.wikimedia.org/zuul/ apart from it will only
> > show for your change only. This will improve the experience as you won't
> > need to leave your change to get a live feed of your change as it
> > progresses through checks.
> > You can see the demo at https://imgur.com/a/uBk2oxQ
> > Plugin at
> > https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-status
> > First commit:
> > https://gerrit-review.googlesource.com/c/plugins/zuul-status/+/212103
> > The plugin uses PolyGerrit's ui rather then GWTUI as GWTUI has been
> > removed upstream (from gerrit 3.0) and because PolyGerrit provides XSS
> > protection.
> > ___
> > 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] The mw.ext construct in lua modules

[Thiemo Kreuz]

> […] I think mw.ext.EXTNAME should be avoided […]

Can I ask to provide arguments that help others understand this
opinion better? What is the problem with the ".ext" part?

> […] or we should reject this proposal and open phab ticket to wikibase to 
> change mw.wikibase to mw.ext.wikibase everywhere […]

How is this an unavoidable consequence of deciding on a standard new
code should follow? What is the benefit of moving existing code that
is so heavily used?

Kind regards
Thiemo

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

[Wikitech-l] Wednesday: Technical Advice IRC Meeting

[Michael Schönitzer]

Reminder: Technical Advice IRC meeting this week **(Wednesday) 4-5 pm UTC**
on #wikimedia-tech.
Question can be asked in English & German.

The Technical Advice IRC Meeting is a weekly support event for volunteer
developers. Every Wednesday, two full-time developers are available to help
you with all your questions about Mediawiki, gadgets, tools and more! This
can be anything from "how to get started" over "who would be the best
contact for X" to specific questions on your project.

If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting

Hope to see you there!

Michi (for the Technical Advice IRC Meeting crew)


-- 
Michael F. Schönitzer


Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de

Unsere Vision ist eine Welt, in der alle Menschen am Wissens der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l