[Wikitech-l] Re: Universal Edit Button: Remove redundant rel="edit" link head

2021-09-21 Thread Thiemo Kreuz
> […] I myself have never understood why one would want a browser extension to 
> display an Edit button outside the viewport. It seems unappealing from a UX 
> perspective and for me personally would likely fade into "banner blindness" 
> and notice if it were detected and/or notice it too much if it tries to get 
> my attention on any editable page.

Have you been able to check if screenreader software possibly does
something useful with these rel="…" attributes?

For me this was always the main motivation to provide e.g. meaningful
 and  in addition to the pagination
links that can be found in the content of a page. Not necessarily to
"display buttons outside of the viewport". But for users with visual
impairments that can't use a mouse, but have dozens of keyboard
shortcuts memorized instead. The fact that these links are displayed
in a toolbar is more secondary. What matters is that they have the
same shortcuts assigned, no matter what the website is.

Even if it turns out that screenreaders are the only tools that do
something with a , and even if screenreaders only make
up zero point whatnot percent, I believe it's worth it.

Remember, accessibility is a process, not a state you can reach.

Best
Thiemo
___
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: Changes to Readers-Web-Backlog

2021-07-16 Thread Thiemo Kreuz
While I very much support the idea of closing old tickets (as well as
Gerrit patches) that don't look like they will ever be tackled – this
tends to be a delicate decision that benefits a lot from being as open
as possible. There is not much to add to what AntiCompositeNumber
already wrote.

1. While 61 tickets is not a small number, it's not a large number
either. People are typically not subscribed to all tickets the same
time. I, for example, would have received a single notification email.

2. I, personally, disabled almost all Phabricator emails. For example,
removing a tag it rarely something I care about. Feel free to suppress
such notifications, esp. if you own the tag. But having a ticket
declined is a relevant information for me, if not the most relevant.

Overall I think it would have created less irritation and stress to
just let Phabricator do what people expect it to do.

Here is another look at these 61 tasks, in case people are interested:
https://phabricator.wikimedia.org/maniphest/query/qJdT7nxCgmK3/#R

Kind regards
Thiemo
___
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/

Re: [Wikitech-l] Ethical question regarding some code

2020-08-06 Thread Thiemo Kreuz
I'm afraid I have to agree with what AntiCompositeNumber wrote. When
you set up infrastructure to fight abuse – no matter if that
infrastructure is a technical barrier like a captcha, a tool that
"blames" people for being sock puppets, or a law – it will affect
*all* users, not only the abusers. What you need to think about is not
if what you do is right or wrong, but if there is still an acceptable
balance between your intended positive effects, and the unavoidable
negative effects.

That said, I'm very happy to see something like this being discussed
that early. This doesn't always happen. Does anyone still remember
discussing "Deep User Inspector"[1][2] in 2013?

Having read what was already said about "harm", I feel there is
something missing: AI based tools always have the potential to cause
harm simply because people don't really understand what it means to
work with such a tool. For example, when the tool says "there is a 95%
certainty this is a sock puppet", people will use this as "proof",
totally ignoring the fact that the particular case they are looking at
could as well be within the 5%. This is the reason why I believe such
a tool can not be a toy, open for anyone to play around with, but
needs trained users.

TL;DR: Closed source? No. Please avoid at all costs. Closed databases? Sure.

Best
Thiemo

[1] https://ricordisamoa.toolforge.org/dui/
[2] https://meta.wikimedia.org/wiki/User_talk:Ricordisamoa#Deep_user_inspector

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

Re: [Wikitech-l] Gerrit v3.2.2 is live [was: Re: Gerrit upgrade on Saturday, 27th of June]

2020-07-01 Thread Thiemo Kreuz
Two thinks:

1. When following the instructions from
https://www.mediawiki.org/wiki/Gerrit/git-review, I got stuck with
git-review 1.26 being reported as the "latest version". Which isn't
true. I had to use `sudo pip install git-review` to get the current
version 1.28.

2. I would love to apply some minor user CSS to the Gerrit UI, just as
I did with the old version:
https://meta.wikimedia.org/wiki/User:Thiemo_Kreuz_(WMDE)/userContent.css.
Unfortunately the new UI heavily uses "shadow DOM", which means no
matter what CSS rules I introduce, the Gerrit UI just ignores it.
There must be a way. Please help.

Best
Thiemo

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

Re: [Wikitech-l] Backport and Config changes window (name change)

2020-06-17 Thread Thiemo Kreuz
I don't think we have the same idea of what the word "unspecific"
means. From my perspective – as a German native speaker who only knows
the abbreviation "SWAT" from bad TV series, and didn't even know what
it means until I looked it up recently – we could have it named
"lemon" as well, and that would not be more unspecific than "SWAT".
I'm happy it's gone. Now let's move on and do something that actually
makes a difference. The planet is still burning, after all.

Kind regards
Thiemo

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

Re: [Wikitech-l] Render with a slow process

2020-04-28 Thread Thiemo Kreuz
To be honest I don't fully understand the question. What you wrote
sounds like we have something like this already. Or did I get this
wrong?

On a very high "user experience" level unrelated to MediaWiki I do
have a suggestion: You could do it similar to how "like" features in
social media clients are implemented. Clicking such a "like" button
feels like it's immediately done. But in reality the job is not done
yet. There is still a request going on in the background, which might
even fail.

In other words: The client-side immediately gives the user a response
that is most likely to happen, without actually knowing if it happens.
In case of a later server-side error the visual response is updated to
let the user know.

When an element on a page is edited and the user clicks "save"; the
client-side already knows everything, doesn't it? It could update the
old rendering with the new information and present that as if it is
already saved.

That's more or less what React frameworks are about.

What you probably don't want to do is to re-implement complicated
rendering pipelines on the client-side. In this case you might need to
use a spinner or other kind of placeholder.

Best
Thiemo

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

Re: [Wikitech-l] Resource Loader messes up Leaflet CSS

2020-04-01 Thread Thiemo Kreuz
I tracked it down a bit, using the URLs
https://www.semantic-mediawiki.org/wiki/Help:Leaflet_format vs.
https://www.semantic-mediawiki.org/wiki/Help:Leaflet_format?debug=1

These weird "shadow" pointers are indeed shadows. The bug happens on
the "leaflet-shadow-pane" layer. The individual
"leaflet-marker-shadow"  elements on this layer are supposed to
show the image "marker-shadow.png", but for some reason show the image
"marker-icon.png" instead. This happens in the actual src="…" argument
of the  tag, not in CSS.

There is really something broken there:

src="…/marker-icon.png?2273e)marker-shadow.png"

I was not yet able to track it down further.

The code your demo
https://github.com/JeroenDeDauw/MediaWiki/commit/1713ccde9de7d59634b1a134c58ee3c84ba01642
happens to touch does not look like it should affect HTML, but only
CSS. I was not able to find any code in ResourceLoader that messes
with  tags or src="…" arguments.

Best
Thiemo

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

Re: [Wikitech-l] Storing some values in the DB

2020-01-27 Thread Thiemo Kreuz
Again. What exactly are you trying to store? How often is it suspected
to change? Who will be allowed to change it? Why not make it
configuration via LocalSettings.php? What is the problem with an extra
table?

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

Re: [Wikitech-l] Storing some values in the DB

2020-01-27 Thread Thiemo Kreuz
Jeroen, can you please provide more context? What exactly are you
trying to store? Why? How often? When will it be changed? By whom?

As of now the rather vague explanation provided make it sound like
it's a configuration flag, and should go into LocalSettings.php as a
$wgYourExtensionYourConfig = 23; variable.

https://www.mediawiki.org/wiki/Manual:Database_layout provides an
overview of the database tables that come with MediaWiki.

You are free to create a new table any time you want. Even if it's
only going to store 3 rows, that should be fine. I'm not aware of a
reason to not do this. Wikibase, for example, contains a table
wb_id_counters that is not meant to store new rows, but only a
strictly limited set of rows. You can copy the update mechanism
related to that table, if you like.

Kind regards
Thiemo

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

Re: [Wikitech-l] Reference group type

2020-01-08 Thread Thiemo Kreuz
The English Wikipedia edited the message
https://en.wikipedia.org/wiki/MediaWiki:Cite_references_link_many_format.
By default, this message is:

[[#$1|$2]]

You can edit your wiki's
[[MediaWiki:Cite_references_link_many_format]] (create it if it
doesn't exist) and change the $2 to $3. This replaces the numbers
(1.1, 1.2, and so on) with letters (a, b, and so on).

Best
Thiemo

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

Re: [Wikitech-l] Uploading new versions of other people's patches to gerrit

2019-04-10 Thread Thiemo Kreuz
> > I'm trying to think of a way to put this politely, but I can't, so: this is 
> > insane.
>
> Please try to remain civil and polite, even when things aren't as you want.

It always strikes me hard when people who fear for their mental sanity
are not allowed to call a situation like that. I'm with Isarra here.
At this point I'm not sure if I'm affected (luckily I have a few days
before I will find out). But if I am, I will tell my manager this is
identical to Gerrit being down, and refuse to work on stories that are
affected. Emailing diffs is not an option.

Best
Thiemo

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

Re: [Wikitech-l] Code sniff for verbose conditionals

2019-03-01 Thread Thiemo Kreuz
Sorry it took me so long to respond here.

In https://gerrit.wikimedia.org/r/486813 Gergő wrote:

> […] it adds some fairly complicated code for detecting a pattern that's 
> mostly harmless and can be dealt with during normal code review, so the value 
> is less than the maintenance cost.

Thanks! I think this sums it up really well.

> we should aim for a threshold which would only reject code that is clearly 
> wrong […]

See, that's the problem: I don't think a single of the examples I have
seen so far is "clearly wrong". I don't think there is anything
"wrong" with explicitly stating all possible return values. Yea, one
*might* consider some of the examples a little tooo expressive. Some
of them *can* be shortened. But when this is the case and when not is
more an opinion than anything, and needs to be talked about in a code
review.

> […] doesn't mean that we should avoid dealing with it without even trying.

I don't think this question was answered yet: What are we even trying
to solve here? How big of an issue is this? How often do we come
across such code during our code reviews and feel "I wish a sniff
would have found this before I did"? I do a ton of code reviews. Yes,
there is code like this. But from my personal experience this is so
rare and so much a matter of personal preference and opinion that it's
not worth dealing with the maintenance costs a fully-automated sniff
comes with.

> Could you provide specific examples where my proposed approach produces an 
> undesirable outcome? That is, an example of code you believe should be 
> acceptable but would be marked as fixable?

I'm sorry, but I believe it should not work this way around. I would
like to point to the examples in the test file. Sure, some of them
*can* be rewritten in a shorter way. But none of them *must* be
rewritten.

CodeSniffer rules are not to make suggestions (actually they are, but
that's not how we use them). The moment we make a sniff report certain
patterns, somebody will come and try to "fix" it, no matter how much
sense it makes. Not long ago a sniff complained about uncommented
@param tags, and people started adding cruft like `@param User $user
The user object`. I would like to avoid running into the same
situation again when we have much more pressing problems, e.g. bad
test coverage, or God objects with hundreds of static methods and
several thousand lines. *These* should make a sniff fail that forbids
making code too complex.

Kind regards
Thiemo

___
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

2019-02-04 Thread 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

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

2019-01-25 Thread Thiemo Kreuz
I meant half a decade. Thanks for assuming good faith.

> You use naming schemes to avoid name clashes […]

This is by far not the only reason to have a naming scheme. Probably
the least interesting one.

I don't think it makes sense for me to continue contributing to this
conversation, since the proposal we are discussing appears to be based
on that argument alone.

Kind regards
Thiemo

___
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

2019-01-25 Thread Thiemo Kreuz
"How it should be done" according to whom? This might be a dumb
question, but I had the impression you are speaking for a larger group
of people in your initial post. I would like to understand the context
better in which the proposed standard came to be.

Personally, I don't support the idea of an open-for-everything
"mw.randomStuff" naming scheme. It's half a century that I'm actively
working with code that contains the sequence "mw." literally thousands
of times: https://codesearch.wmflabs.org/search/?q=%5Cbmw%5C.%5Cb.
After all these years my expectation is that stuff is only put
directly in the "mw." namespace when it is general purpose utility
stuff. And people are even trying to reduce this.

I understand that "mw.ext." is not terribly different from using "mw."
directly. Both are places for all kinds of unrelated random stuff. But
I believe it is still useful to have both: "mw." exclusively for
random stuff that is part of MediaWiki itself, and a different one for
community code.

Kind regards
Thiemo

___
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

2019-01-24 Thread Thiemo Kreuz
Is there a question assigned with this long email? Is this a call for feedback?

Kind regards
Thiemo

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

Re: [Wikitech-l] Query

2019-01-23 Thread Thiemo Kreuz
You can link all your accounts via your user settings on Phabricator.

Except for a little confusion here and there I'm not aware of any
consequences of having different names on Wikitech (which includes
Gerrit) and Phabricator. I happen to have slightly different account
names myself.

Best
Thiemo

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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

2019-01-22 Thread Thiemo Kreuz
> […] "people who have worked on this code before" is an excellent metric by 
> which to find people to review your code.

Sure. But this is neither what I wrote, nor what the plugin does, nor
what can be done programmatically in the first place, as you
conveniently pointed out yourself:

> […] we can't possibly know what was a one-line typofix and what was a one 
> line that saved us 50% of execution time on all pages. At least not 
> programmatically.

Kind regards
Thiemo

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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

2019-01-22 Thread Thiemo Kreuz
> Fundamentally broken sounds like a bit of a stretch.

A process that annoys people based on nothing but the fact that they
happened to be the last one touching a file *is* fundamentally broken.
This is not how anyone should look for reviewers, neither manually nor
automatically.

Here is a thought experiment: We could send review requests to the
*least* active users that are still around, but *never* touched a
file. The positive effects of such an approach include:
* More people get familiar with the code.
* Knowledge gets spread more evenly.
* Bottlenecks and bus factors get reduced.
* These people probably have more time.
* Review requests are spread more evenly.
* Workload is spread more evenly.

Still sounds like a bad idea? Sure, because it is. Now tell me: How is
it more clever to do the *opposite* and dump review requests on people
that have to much workload already?

At this point I don't care any more if we are talking about a fully
automated process or a suggest button. Both are targeting the wrong
people.

> it was probably working quite well for our less-trafficked repositories.

What is the difference between being the last one fixing a typo in a
low-traffic vs. high-traffic repository? In both cases it's the wrong
person.

Thiemo

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

Re: [Wikitech-l] UserMerge extension on Wikimedia sites

2019-01-22 Thread Thiemo Kreuz
> Is the UserMerge extension actually used on Wikimedia sites?

I don't know if people *use* it, but according to
https://wikiapiary.com/wiki/Extension:UserMerge it is installed on
more than a thousand wikis, including all Wikimedia wikis.

Best
Thiemo

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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

2019-01-22 Thread Thiemo Kreuz
> […] im adding that functionality to reviewers-by-blame.

I'm afraid I don't understand. Does this mean all the issues that make
the plugin send passive-aggressive, misattributed spam will still be
in place, possibly hitting peoples inboxes again any time somebody
decides it would be a good idea to turn this feature set on again? My
impression was more that all the ideas that have been shared in this
email thread describe an *entirely* different approach, following
entirely different ideas, with an entirely different UI, and entirely
different setup. What's the point of stuffing this into the same,
fundamentally broken codebase?

Sysops, please, for our sanity, do not let anybody enable this toxic
plugin again.

Best
Thiemo

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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

2019-01-21 Thread Thiemo Kreuz
> […] i have a working prototype working ("Suggest Reviewer") button.

Ok, but that's another extension then. Can we kill the bad one, please?

Best
Thiemo

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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

2019-01-21 Thread Thiemo Kreuz
Can I please ask again to *ban* this bad plugin entirely from our
systems? Having it sit there for anybody to enable again is a ticking
time bomb. It will start sending out the same misattributed,
uncontrollable, aggressive fake request spam again. I don't want
anybody to experience something like this again.

Look for a plugin that makes suggestions, please.

Best
Thiemo

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

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

2019-01-18 Thread Thiemo Kreuz
> Gerrit no longer automatically adds reviewers […]

Thank you very much for reacting so fast.

> https://gerrit.wikimedia.org/r/485184

I'm not sure if the list of issues in this commit message is meant to
be complete. But I noticed it misses the bug I found the most
annoying: The plugin doesn't get activated once per patch, but for
every patch set, and ignores every human intervention that might have
been done to this point, most notably when reviewers have manually
been removed. There are many ways to fix this, but the current
behavior is unacceptable.

It is due to this bug that I wish we would revoke this bad plugin
entirely. I don't think anybody should be able to run it as this would
open the exact same issues again, just on a smaller scale, but still
hurting the same people.

Best
Thiemo

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

Re: [Wikitech-l] Gerrit now automatically adds reviewers

2019-01-18 Thread Thiemo Kreuz
So it turns out this addition is indeed the reason I get constantly
spammed with the same fake review request over and over again, no
matter how often I try to remove myself from a patch.

https://gerrit.wikimedia.org/r/484681

Not only that. The notification mails make it look like Matthias
Mullie went rogue. He is a wonderful person and definitely doesn't
deserve that such cyberbullying is misattributed to him.

With all the respect, but at this point this is just insane. Please
make this stop!

Thiemo

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

Re: [Wikitech-l] Gerrit now automatically adds reviewers

2019-01-18 Thread Thiemo Kreuz
> […] automatically add reviewers to your changes based on who previously has 
> committed changes to the file.

I'm already overwhelmed with review requests. I'm also one of the
latest contributors in sooo many files that I'm worried the plugin
will add me to dozens per day from now on. This surprising addition
makes me worry very much about my sanity and the usability of my inbox
and Gerrit dashboards. Please, please, tune it down heavily.

Until now, I had a process to find reviewers:

1. For planned changes, it's already obvious who needs to do the
review: my team members. Often they don't even need to be added as
reviewers, or don't want to, but use the "review" column on our
Phabricator board. Automatically adding random *other* people is not
only useless in this situation, it's counterproductive and frustrating
for everybody involved. Other people should not waste their time with
patches like this. When they do, it's frustrating for the one who was
supposed to do the review, as well as for the "auto-reviewer". His
review is not helpful and ultimately not appreciated.

2. For code cleanups in core and codebases my team does not own I open
the list of merged patches on Gerrit to see if I can tell the names of
one or two main contributors. Often, the list will contain nothing but
the Translatewiki bot and a few people doing cross-codebase
maintainance work. These highly active people should *not* be the
first pick as potential reviewers for multiple reasons. Most
importantly, just because someone is very productive it's not ok to
expect him to accept even more workload. This is
super-counterproductive and ultimately leads to people burning out.
Secondly, just because someone updated, let's say, a call to a
deprecated core function does not mean he is familiar with a codebase.

3. I look at the files my patch happens to touch in my PHPStorm IDE,
enable the blame column that shows who touched a line last, and see if
I can find the one who introduced the code I'm touching.

All steps in this process involve *reading* the commit messages and
considering what people did, when and why. This can't be automated.

I do not entirely oppose the idea of adding reviewers automatically,
as long as I (as a reviewer) have a chance to easily tell the
difference between being added manually vs. automatically. For my
sanity, I will most probably setup an email filter that auto-deletes
all automated requests, and only look at these auto-reviews once a
week via my Gerrit dashboard.

Based on all these arguments this is what I, personally, find acceptable:
* Make sure no emails are sent for being automatically added, or make
sure it's possible to turn them off (without also killing the wanted
emails about manually being added).
* Make sure tool accounts like the library-upgrader or Translatewiki
bot are never added as reviewers.
* Never automatically add reviewers if there are other reviewers
already. Most importantly, if people have been added via the reviewer
bot already, that's more than enough.
* Only add 2 reviewers. 2 people will more likely feel like a team. 3
people are much more likely to all think "the other 2 will do it" and
all ignore it.
* Don't just pick the "most recent" contributor. That's most certainly
not the person you want (probably one who fixed a typo, or updated a
library). Implement an algorithm that can either understand who
touched which places in the code, and assigns them to patches that
happen to touch the same place again. Or go for an algorithm that (for
example) analyzes the last year and picks the 2 people who did the
most changes to a file in that time span.

If more than one of these criteria is not met or not possible, the
only solution I see is to make the plugin opt-in per codebase, not
opt-out as of now (because you can't expect me to opt-out from
literally a thousand codebases).

Thank you for keeping my inbox sane.

Best
Thiemo

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

Re: [Wikitech-l] The ref tag parameter follow in non wikisource wikis

2018-12-13 Thread Thiemo Kreuz
> I expect from the parser to parse wiki markup before parsing html tags […]

As I said. As neither the wiki markup nor the XML tags in the given
example are valid, one can't expect anything. Seriously. Code like
{{cite|}} is just broken. It's like having two nested Klein
bottles. Both structural elements are inside and outside the same
time.

What do you even want to achieve?

Best
Thiemo

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

Re: [Wikitech-l] The ref tag parameter follow in non wikisource wikis

2018-12-13 Thread Thiemo Kreuz
The wikitext snippet you posted appears to be seriously broken. More
precisely: It is unbalanced. Technically, there is no such thing as
"broken" wikitext. The parser will always output something (as he does
in the example). However, this doesn't mean such wikitext is ok. Sure,
nobody is stopping anyone from writing unbalanced code. But it becomes
unpredictable (as the example shows), unreliable, and effectively
unmaintainable as it starts to heavily depend on quirky internal
details of the parsers implementation, how it approaches certain
aspects, and in which order they are processed.

The bigger problem here is this: Even if you figure out how the parser
works right now, it might change, as it already did many times. Have a
look at pages like https://www.mediawiki.org/wiki/Markup_spec to get
an idea of how complex this topic is, and how many people tried how
many times to nail it down, all failing for one or the other reason.
Code like the one you showed depends so much on the tiniest
implementation detail of the parsing process, it becomes so fragile
that it might break any day for reasons nobody could ever anticipate
without a warning.

Please balance your wikitext.

Best
Thiemo

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

Re: [Wikitech-l] The ref tag parameter follow in non wikisource wikis

2018-12-13 Thread Thiemo Kreuz
> […] why the  tag parameter follow= is not turned off in wiki sites that 
> are not wikisource?

As the Technical Wishes team at Wikimedia Germany is currently working
on the Cite extension, I had a look to find an answer to your
question.

The follow="…" feature was introduced in 2010[1] as part of the Cite
extension, the extension responsible for the  and 
tags. The feature was never designed to be turned on or off per wiki,
and can't be turned off.

In case a wiki does not want to use it, and make sure it isn't used, I
suggest to either use an "insource" search[2] on a regular basis, or
possibly talk to the users running the Check Wikipedia project[3] to
add a scan for the follow="…" parameter to their list.

Best
Thiemo

[1] 
https://phabricator.wikimedia.org/rECITb5883ddc36f8ee270f555ad73ac5fa00cf1bcbc9
[2] https://www.mediawiki.org/wiki/Help:CirrusSearch#Insource
[3] https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Check_Wikipedia

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

Re: [Wikitech-l] New Wikimedia password policy and requirements

2018-12-10 Thread Thiemo Kreuz
Oh my. These might be the most sensible password policies I have seen
implemented since, I think, ever:

1. Must have a certain length.
2. Can not be one of the most used passwords.
3. Ah, and don't be so silly to repeat your user name.
4. That's all.

No made up rules like "must contain at least one special character
from a set of actually not so special characters" that force users to
make their passwords actually less secure.

Thanks a lot to the team working on this, and the code that backs this up!

Best
Thiemo

PS: Now we just need to know what the 100,001st most used password is. ;-)

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

Re: [Wikitech-l] non-obvious uses of in your language

2018-10-04 Thread Thiemo Kreuz
Hey!

The syntax "[[Schnee]]reichtum" is quite common in the
German community. There are not many other ways to achieve the same:
 or  can be used instead.[1] The later is often the
better alternative, but an auto-replacement is not possible. For
example, "[[Bund]]estag" must become "[[Bund]]estag".

Not long ago  was often used. This became a problem with the
recent parser updates. All  got replaced with , as far
as I'm aware of.

> in German, shouldn't they be tweaking the "linktrail" setting on dewiki, 
> instead of using ``? What are cases where they *do* want the link to 
> include the entire word?

The software feature exists because of English [[word ending]]s. The
same exists in German ("viele [[Wiki]]s, viele [[Tisch]]e, viele
[[Arbeit]]en"), but is overshadowed by the fact that German is a
language with many composites. From my experience, the fact that all
linktrails, no matter how long, become part of the link is almost
always a problem. It enlarges the click region, which is good, but
surprises the reader when he ends at an unexpected article. I guess it
would actually be a net-gain when the feature gets turned off or tuned
down in German wikis. For example, we could limit the length of the
linktrail to 2 characters.

Is somebody interested in creating usage statistics for these
linktrails in the German Wikipedia main namespace?

Best
Thiemo

[1] 
https://de.wikipedia.org/wiki/Wikipedia:Verlinken#Verlinkung_von_Teilw%C3%B6rtern

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

Re: [Wikitech-l] Collecting UI feedback for PolyGerrit - Gerrit

2018-10-03 Thread Thiemo Kreuz
Paladox wrote:

> i am collecting feedback for Gerrit's New UI […]

You might want to check out the CSS tweaks I developed for the old
Gerrit UI. This stylesheet removes a lot of clutter, makes Gerrit
usable on smaller laptop screens, and increases critical click
regions. If the new Gerrit UI looks as clean as my tweaked version (or
when similar tweaks can be applied to the new UI), I'm happy.

https://meta.wikimedia.org/wiki/User:Thiemo_Kreuz_(WMDE)/userContent.css

Best
Thiemo

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

Re: [Wikitech-l] Translations on hold until further notice

2018-09-27 Thread Thiemo Kreuz
Hey,

I'm sorry to hear about such an issue. I can only assume it means
massive trouble for your team, Greg.

Unfortunately for me being one of the receivers of this message I must
say it does not make the slightest sense.

What happened? Is there a Phabricator ticket I can read up?

What is the issue with making further changes to any en.json file?
What trouble can a new entry in one of these files cause that you ask
everybody to stop editing them, instead of – let's say – stop the bot
that creates the corresponding entries on translatewiki.net? The
request effectively means everybody needs to stop working on UI
features. How do you plan to make sure such changes to the multiple
hundred en.json files we maintain are indeed not done any more? What
will happen if a patch gets merged by a team that relies on
translatewiki.net translations, but did not got your message, or did
not understood it? Nothing? If so, why can't we continue editing our
very own localization files, and solve the issue your team is working
on – whatever it is – independent from that?

TL;DR: What is going on?

Best
Thiemo

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

Re: [Wikitech-l] OOUI v0.28.0 released

2018-08-17 Thread Thiemo Kreuz
> Final code cleanup step after major icon refinement […]

Congratulations on that! I especially love how the identifiers for
many icons describe more how they look, and less what their intended
purpose is. E.g. "die" and "funnel" being called like this, and not
"random" and "filter".

However, one pair of icons still leaves me puzzled: There are two
settings cogs, one in a dark rectangle called "pageSettings", and one
without called "advanced". I never got what "advancements" the later
refers to. How is it meant to be used?

Best
Thiemo

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

Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role

2018-06-11 Thread Thiemo Kreuz
> Is there any historical evidence that sysops being able to edit JS / CSS 
> caused some serious issues?

Oh yes, this happens more often than I feel it needs to. I remember a
situation when I posted a fix for a script in the MediaWiki:…
namespace as an {{edit request}}, and a well-meaning administrator
tried to "improve" my line of code and forgot a comma, breaking all
JavaScript for all logged-in as well as not logged-in Wikipedia
editors and readers for some painful minutes.

I believe such can be avoided with more clear roles that are visible
for everybody. A separate "tech admin" role would also allow
volunteers to apply for exactly that, and not be asked why they don't
do enough "administrator actions" with their privileges.

Sure, this is anecdotal evidence. Please forgive me, but I currently
don't have the time to find the pages documenting these situation.

Best
Thiemo

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

Re: [Wikitech-l] FLIF for Wikimedia

2017-12-06 Thread Thiemo Kreuz
> Point was more: Get rid of this bloody Download a JPG, do some Stuff &
Upload a 3 Times locally saved JPG again […]

I'm afraid I did not made my point clear enough. With all respect to your
enthusiasm, but the scenario you describe is exactly what your suggestion
will not improve. How could it? We can not control what people do on their
local computers.

Even worse: FLIF is not even needed for the scenario you describe. We could
just convert all JPEG to PNG. But this will not happen for the reasons
collected in this thread.

> those images should never be saved as JPG in the first place.

Sure. Go and encourage people to upload RAW. That's very much welcome. But
converting their JPEG after they made them will make many scenarios worse.
Even including the one you aim for: What you want is to allow people to
download an image, open, edit and save it without ever thinking about the
file format. FLIF can not do that, yet.

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

Re: [Wikitech-l] FLIF for Wikimedia

2017-12-04 Thread Thiemo Kreuz
Hey,

I consider myself an image file format nerd, so thanks a lot for
sharing this! FLIF was new to me.

I would like to share two important notes:

1. Unfortunately the flif.info website does not say a word about the
CPU resources their current implementation burns when converting a,
let's say, PNG to FLIF. It's pretty important to realize that CPU
resources are even more valuable than storage space and network
bandwidth. Sure, It's not really possible to come up with an exact
threshold. But if, let's say, converting a PNG to FLIF saves 100 KiB,
but takes a minute, this minute will never pay off.

If you follow the discussions on Wikimedia Commons, you will find this
argument quite often: Downloading PNGs, optimizing them, and uploading
them again is practically never worth it. Think of all the resources
that are burned to do this: CPU time, download and upload, database
storage and time, disk storage for the new revision, and not to forget
the user doing all this.

Sure, your suggestion avoids a lot of this. But the CPUs involved will
experience heavy load, both on the server as well as clients that need
to recode FLIF files via a JavaScript library first.

2. Lossy file formats like JPEG should never be converted to lossless
formats. This will actually decrease quality (over time). The problem
is that the image data will still contain the exact same JPEG
artifacts, but the fact that it was a JPEG (and how it was encoded) is
lost. No tool specialized in squeezing the maximum quality out of
lossy JPEGs can work any more. And there are a lot of super-awesome
tools like this. Not only tools like JPEGCROP and such that can cut
and even combine JPEGs without actually recoding them. There are also
"JPEG repair" filters that know how to reverse the JPEG encoding
algorithm and can squeeze out a tiny little bit of extra information
regular JPEG decoders can't see.

This said, I'm all for adding FLIF to the list of allowed file formats!

Best
Thiemo

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