[Wikitech-l] Re: APIi page generator namespace order

[Lucas Werkmeister]

For Special:UnconnectedPages in particular, we designed the underlying page
property so that it can be efficiently sorted or filtered by namespace (see
T300770 <https://phabricator.wikimedia.org/T300770> for details), so the
fact that it starts with main namespace pages is intentional and guaranteed
by the current code; I’d say this is unlikely to change soon, but I also
don’t think we consider it covered by the Wikidata Stable Interface Policy
<https://www.wikidata.org/wiki/Wikidata:Stable_Interface_Policy>.

For other query pages, it depends on the particular page; for
instance, Special:PagesWithProp
sorts by page_id
<https://gerrit.wikimedia.org/g/mediawiki/core/+/5fc28ecc5b/includes/specials/SpecialPagesWithProp.php#207>
and Special:ShortPages by page_len
<https://gerrit.wikimedia.org/g/mediawiki/core/+/5fc28ecc5b/includes/specials/SpecialShortPages.php#158>,
if I’m reading the code correctly.

Am Do., 22. Feb. 2024 um 06:36 Uhr schrieb Bináris :

> Hi,
> I query special pages through API (concretely Special:UnconnectedPages),
> and I noticed that main namespace articles are yielded first.
> It seems that pages are ordered by namespace numbers.
> Is it a guaranteed behaviour?
>
> (If so, I can break from the loop at te first page not in 0 namespace
> which would be nice.)
>
>
> --
> Bináris
> ___
> 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/



-- 
Lucas Werkmeister (he/er)
Software Engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de

Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 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
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: PhpStorm + PHPUnit Integration Tests

[Lucas Werkmeister]

For me this has mostly worked (except for tests that access the service
container in data providers, which is discouraged anyway
<https://phabricator.wikimedia.org/T332865>) for a few months now –
probably since Daimona’s work on phpunit:entrypoint
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/QT7G4CRKZG4VEUR2SXIMYGHDSKIFUS5D/>.
(I didn’t have to do any special IDE configuration, it Just Worked™ for
me.) Are you using the master branch or some released version of MediaWiki?

(I’m using IntelliJ IDEA Ultimate, but I assume PHPStorm should work very
similarly.)


Am Mi., 29. Nov. 2023 um 15:32 Uhr schrieb Daniel Riedmueller via
Wikitech-l :

> Hello!
>
> Did someone successfully configured PhpStorm to run integration tests in
> the GUI?
>
> To make integration tests work,
>
> tests/phpunit/phpunit.php
>
> has to be used. But that seems not possible to integrate with PhpStorm.
>
> Many regards,
> Daniel Riedmüller
>
>
> ___
> 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/
>


-- 
Lucas Werkmeister (he/er)
Software Engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de

Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 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
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: New developer feature: $wgUseXssLanguage / x-xss language code

[Lucas Werkmeister]

I’d also like to discourage the Mustache “.” feature (“current context”, as
in {{#html-items}}{{{.}}}{{/html-items}}), at least in unescaped HTML (i.e.
{{{.}}}) but perhaps also in escaped HTML ({{.}}) – it made one of the
related issues much harder to debug for me, because I couldn’t even find
the template that was using the unescaped variable. (Admittedly, part of
this was just because I didn’t know this feature existed.)

Am Fr., 29. Sept. 2023 um 21:55 Uhr schrieb Bartosz Dziewoński <
matma@gmail.com>:

> On 2023-09-29 19:55, bawolff wrote:
> > This is clearly yielding some interesting results.
> >
> > One of the patterns i've noticed is that several of the examples seem to
> > involve mustache templates. I think there are two reasons for this:
> >
> > * mustache templates cannot currently be checked by phan-taint-check
> > * Because they are a separate file, the escaping is now fairly far away
> > from the context where the variable is used. Its easy to lose track of
> > if a specific variable is supposed to be escaped between the template
> > file and the call into TemplateProcessor.
>
> Let's not go too easy on Mustache, there are several more reasons why
> these templates are full of security gaps:
>
> * Escaping or failing to escape HTML is the difference between {{ }} and
> {{{ }}}, and unless you spent your whole life writing Mustache
> templates, you won't remember which is which.
>
> * Mustache has no concept of HTML structure, or any structure, or
> variable types; it just concatenates strings, so it's difficult to
> automatically detect any problems.
>
>
> > Anyways, i'd like to propose a naming convention. Any mustache variable
> > that is used as raw html should have some sort of easily identifiable
> > prefix so it is easy to keep track of which parameters are escaped and
> > which are not. e.g. instead of naming the parameter foo, it would be
> > named something like HTMLFoo.
>
> We already do this, at least! Most Mustache variables used as raw HTML
> are prefixed with 'html-'. Vector is pretty consistent about this [1],
> but even it has some exceptions. Other code is not all so good.
>
> [1]
>
> https://codesearch.wmcloud.org/search/?q={{{=\.mustache%24==Skin%3AVector
> <https://codesearch.wmcloud.org/search/?q=%7B%7B%7B=%5C.mustache%24==Skin%3AVector>
>
>
> --
> Bartosz Dziewoński
> ___
> 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/



-- 
Lucas Werkmeister (he/er)
Software Engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de

Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 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
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 developer feature: $wgUseXssLanguage / x-xss language code

[Lucas Werkmeister]

Hi all! This is an announcement for a new developer feature in MediaWiki.
If you don’t develop MediaWiki core, extensions or skins, you can stop
reading :)

MediaWiki interface messages are generally “safe” to edit: when they
contain markup, it is either parsed (as wikitext), sanitized, or fully
HTML-escaped. For this reason, administrators are allowed to edit normal
messages on-wiki in the MediaWiki: namespace, while editing JS code (which
is more dangerous) is restricted to interface administrators. (A few
exceptions, messages that are not escaped and which can only be edited by
interface administrators, are configured in $wgRawHtmlMessages
.)
Occasionally, a bug in the software means that a message isn’t properly
escaped, which can in theory be abused by administrators to effectively
gain interface administrator powers (by editing a MediaWiki: page for a
message to contain 

[Wikitech-l] Codex now available on Toolforge CDNjs

[Lucas Werkmeister]

Hi all,

Tool developers may be interested to know that Codex [1], the design 
system for Wikimedia, is now available on the Toolforge CDNjs Mirror [2] 
(and on upstream CDNjs [3], but you should prefer the Toolforge mirror 
:P). This means you can relatively easily use the Codex components, 
icons, and/or design tokens in your tools if you want, just like e.g. 
Bootstrap. See [4] for an example in one of my tools. (The most 
important technical bits are the importmap, import statements, createApp 
call, and `components: codex` and `...codexIcons`, if you want to search 
for those parts in particular.)


The Codex maintainers would probably like me to remind you that Codex 
has not reached version 1.0 yet ;) I gather that it’s coming up (and 
not, like, years away), but until then you should probably be ready for 
breaking changes to happen. Once version 1.0 is out, CDNjs and the 
Toolforge mirror should pick it up automatically, but you’ll need to 
adjust the URLs in your tools like for any version upgrade (since the 
version number is part of the URL – CDNjs doesn’t offer auto-updating 
“latest” URLs).


The Phabricator task for Codex being available on CDNjs is T338834 [5]; 
if you experience any issues, you can bring them up there.


Enjoy!
Lucas

[1]: https://doc.wikimedia.org/codex/latest/
[2]: https://cdnjs.toolforge.org/
[3]: https://cdnjs.com/
[4]: 
https://gitlab.wikimedia.org/toolforge-repos/wd-image-positions/-/commit/0e0deb1a494aeb2e498357330d0a23bd833c38e5

[5]: https://phabricator.wikimedia.org/T338834
___
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] +2 for Lucas Werkmeister [volunteer] in mediawiki/

[Lucas Werkmeister]

Hi all,

at the ongoing Hackathon, Legoktm made me nominate myself for +2 in mediawiki/* 
repositories ^^ see .

Cheers,
Lucas
___
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: Python requests broken by urllib3 version 2.x

[Lucas Werkmeister]

For the general case of Python projects, I’d argue that a better solution
is to adopt the lockfile pattern (package-lock.json, composer.lock,
Cargo.lock, etc.) and pin *all* dependencies, and only update them when the
new versions have been tested and are known to work. pip-tools
<https://pypi.org/project/pip-tools/> can help with that, for example (
requirements.in specifies “loose” dependencies; pip-compile creates a
pinned requirements.txt; pip-sync installs it; pip-compile -U upgrades
requirements.txt later; you check both requirements.in and requirements.txt
into version control.) But I don’t know if that applies in your
integration/config case.

Am Do., 4. Mai 2023 um 18:08 Uhr schrieb Antoine Musso :

> Hello,
>
> This is for python projects.
>
> Today, May 4th, urllib3 <https://pypi.org/project/urllib3/#history> has
> released a new major version 2.0.2 which breaks the extremely popular
> requests <https://pypi.org/project/requests/> library.
>
> The fix is to pin urllib3<2 to prevent the new major version from being
> installed (example
> <https://gerrit.wikimedia.org/r/c/integration/config/+/915736/1/tox.ini>).
>
> https://phabricator.wikimedia.org/T335977
>
> Upstream issue: https://github.com/psf/requests/issues/6432
>
>
> Antoine "hashar" Musso
> Wikimedia Release Engineering
> ___
> 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/



-- 
Lucas Werkmeister (he/er)
Software Engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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
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] Two new test base classes for extensions: ExtensionServicesTestBase and ExtensionJsonTestBase

[Lucas Werkmeister]

Hi all,

I wanted to quickly announce two new classes I added to MediaWiki core the
other day: ExtensionServicesTestBase
<https://gerrit.wikimedia.org/g/mediawiki/core/+/master/tests/phpunit/integration/includes/ExtensionServicesTestBase.php>
and ExtensionJsonTestBase
<https://gerrit.wikimedia.org/g/mediawiki/core/+/master/tests/phpunit/integration/includes/ExtensionJsonTestBase.php>.
Both are abstract base classes for PHPUnit tests; by adding a test class
extending one of these base classes, an extension can *opt into* additional
tests, with very little extra code in the extension itself. If you don’t
want to do that, nothing will change for you :)

ExtensionServicesTestBase can be used to test “ExtensionServices” classes
(e.g. CognateServices or WikibaseRepo). These classes are described on
mw:Dependency
Injection § Service registration in extensions
<https://www.mediawiki.org/wiki/Dependency_Injection#Service_registration_in_extensions>;
basically, they’re a bunch of boilerplate code that makes an extension’s
services in the service container easier to work with (
CognateServices::getStore() is equivalent to $services->getService(
'CognateStore' ), but the former can be autosuggested by the IDE and also
has a known return type). An ExtensionServicesTestBase subclass tests that
this boilerplate code looks like you’d expect it to: the methods are
static, their name matches the service name, etc. Nothing exciting, but
nice to have if you use this “ExtensionServices” pattern.

ExtensionJsonTestBase is more exciting. The tests in this class read your
extension.json, and try to create the various API modules, special pages,
etc. that are specified in there, according to their factory
specifications. This ensures, for instance, that the list of services
specified in extension.json actually matches what the configured
constructor or factory method expects (e.g. in case you added a service to
the constructor and your unit test, but forgot to add it to
extension.json), which might otherwise only be caught by browser tests
(even integration tests don’t usually use the extension.json factories).
More importantly, the tests also ensure that no HTTP or database
connections are made when all these things are created. Services that make
network requests as soon as they’re created, rather than only when they’re
used, have been a performance issue in Wikibase in the past (T243729
<https://phabricator.wikimedia.org/T243729>), and these tests are meant to
prevent such a thing from happening again.

(In theory, all of this might work more or less well for skins as well as
extensions. I have no reason to try that, since I don’t work on skins, but
if you’re interested in it, feel free to experiment with it and see if it
works out. I’ll point out that MediaWiki’s ExtensionJsonValidationTest,
which “Validates all loaded extensions and skins using the
ExtensionRegistry against the extension.json schema in the docs/ folder”,
could be a precedent for an “ExtensionSomething” class actually covering
both extensions and skins, so I don’t think the two new TestBase classes
would necessarily need to be renamed.)

A minimal example of using both of these tests in an extension might look
like this:

class EntitySchemaServicesTest extends ExtensionServicesTestBase {
   protected string $className = EntitySchemaServices::class;
   protected string $serviceNamePrefix = 'EntitySchema.';
}

class EntitySchemaExtensionJsonTest extends ExtensionJsonTestBase {
   protected string $extensionJsonPath = __DIR__ .
'/../../../../extension.json';
}

Cheers,
Lucas

-- 
Lucas Werkmeister (he/er)
Software Engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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
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: Feedback wanted: PHPCS in a static types world

[Lucas Werkmeister]

I uploaded some Gerrit changes for the code sniffer: chain starts at change
865650
<https://gerrit.wikimedia.org/r/c/mediawiki/tools/codesniffer/+/865650>.
Reviews welcome!

With those changes combined, *fully* typed functions (all parameters +
return type) and typed properties are allowed (but not required, of course)
to have no doc comment, or to have doc comments without @param / @return.
However, partial @param are not allowed, since I think that would be too
confusing – if some parameter can’t have a static type yet,¹ then the
phpdoc has to list all the params (with their types).

¹: incidentally, PHP 8.2 was released today
<https://www.php.net/archive/2022.php#2022-12-08-1> (h/t Reedy), with
support for the types true, false, and null.


Am Mi., 16. Nov. 2022 um 17:17 Uhr schrieb Lucas Werkmeister <
lucas.werkmeis...@wikimedia.de>:

> What Timo writes sounds good to me. I don’t think we need to enforce
> removal of existing code blocks – that can happen gradually as the code is
> touched for other reasons instead.
>
> Regarding performance, I think we should limit micro-optimizations like
> omitting static types to code that we know is hot; for most of our code, I
> think the benefit of avoiding bugs that can be caught or prevented by
> static types is more important. We already have some hot code that uses a
> more performance-oriented code style (e.g. RemexHtml “sometimes use[s]
> direct member access instead of going through accessors, and manually
> inline[s] some performance-sensitive code”), but we don’t use that code
> style everywhere.
>
> Aside: I would also hope that PHP will eventually learn some optimizations
> that are taken for granted in many other languages, such as inlining
> setters/getters and other short methods, or (more relevant to this thread)
> eliminating runtime type checks when they can be statically proven. But I
> definitely don’t have the skills to push that forward, so I won’t complain
> about it too much.
>
> I’ll try to find some time soon-ish to look into MediaWiki CodeSniffer and
> see if some improvements can be implemented without too much trouble.
>
>
> Am Mi., 16. Nov. 2022 um 01:00 Uhr schrieb Krinkle :
>
>>
>>
>> On Tue, 15 Nov 2022, at 11:41, Daniel Kinzler wrote:
>>
>> Am 10.11.2022 um 03:08 schrieb Tim Starling:
>>
>> Clutter, because it's redundant to add a return type declaration when the
>> return type is already in the doc comment. If we stop requiring doc
>> comments as you propose, then fine, add a return type declaration to
>> methods with no doc comment. But if there is a doc comment, an additional
>> return type declaration just pads out the file for no reason.
>>
>> I agree that we shouldn't have redundant doc tags and return type
>> declarations. I would suggest that all methods should have a return type
>> declaration, but should not have a @return doc tag unless there is
>> additional info […]
>>
>>
>> The performance impact is measurable for hot functions. In gerrit 820244
>> <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/820244> I removed
>> parameter type declarations from a private method for a benchmark
>> improvement of 2%.
>>
>> This raises an interesting issue, one that has bitten me before: How do
>> we know that a given method is "hot"? Maybe we should establish a @hot or
>> @performance tag to indicate that a given method should be optimized for
>> speed. […]
>>
>>
>> I think the enforced and automated codesniffer could remain fairly
>> simple: As today, the sniff encourages all methods to have parameter and
>> return types documented in a way that humans, Phan, and IDEs can understand
>> for static analysis to avoid and catch mistakes.
>>
>> What I propose we change is that instead of enforcing this solely through
>> a mandatory doc comment, enforce it by requiring at least one of them to be
>> present. Either parameters and returns are typed, or a doc block exists.
>> Both may exist, of course.
>>
>> We've established in this email thread that it can be cluttering (and
>> waste of effort) to require repeating of information when doing so adds no
>> value. It is also my understanding that Phan and IDEs already understand
>> either and both so we don't need them to be aware of which "should" exist.
>>
>> Is there value in enforcing removal of existing doc blocks after someone
>> has written it? This seems to me like potentially a significant time sink
>> with no return on that other because we enforced it as a new rule. If we
>> agree there is no urgency in removing existing doc blocks or actively
>> blocking CI when

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

[Lucas Werkmeister]

What Timo writes sounds good to me. I don’t think we need to enforce
removal of existing code blocks – that can happen gradually as the code is
touched for other reasons instead.

Regarding performance, I think we should limit micro-optimizations like
omitting static types to code that we know is hot; for most of our code, I
think the benefit of avoiding bugs that can be caught or prevented by
static types is more important. We already have some hot code that uses a
more performance-oriented code style (e.g. RemexHtml “sometimes use[s]
direct member access instead of going through accessors, and manually
inline[s] some performance-sensitive code”), but we don’t use that code
style everywhere.

Aside: I would also hope that PHP will eventually learn some optimizations
that are taken for granted in many other languages, such as inlining
setters/getters and other short methods, or (more relevant to this thread)
eliminating runtime type checks when they can be statically proven. But I
definitely don’t have the skills to push that forward, so I won’t complain
about it too much.

I’ll try to find some time soon-ish to look into MediaWiki CodeSniffer and
see if some improvements can be implemented without too much trouble.


Am Mi., 16. Nov. 2022 um 01:00 Uhr schrieb Krinkle :

>
>
> On Tue, 15 Nov 2022, at 11:41, Daniel Kinzler wrote:
>
> Am 10.11.2022 um 03:08 schrieb Tim Starling:
>
> Clutter, because it's redundant to add a return type declaration when the
> return type is already in the doc comment. If we stop requiring doc
> comments as you propose, then fine, add a return type declaration to
> methods with no doc comment. But if there is a doc comment, an additional
> return type declaration just pads out the file for no reason.
>
> I agree that we shouldn't have redundant doc tags and return type
> declarations. I would suggest that all methods should have a return type
> declaration, but should not have a @return doc tag unless there is
> additional info […]
>
>
> The performance impact is measurable for hot functions. In gerrit 820244
> <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/820244> I removed
> parameter type declarations from a private method for a benchmark
> improvement of 2%.
>
> This raises an interesting issue, one that has bitten me before: How do we
> know that a given method is "hot"? Maybe we should establish a @hot or
> @performance tag to indicate that a given method should be optimized for
> speed. […]
>
>
> I think the enforced and automated codesniffer could remain fairly simple:
> As today, the sniff encourages all methods to have parameter and return
> types documented in a way that humans, Phan, and IDEs can understand for
> static analysis to avoid and catch mistakes.
>
> What I propose we change is that instead of enforcing this solely through
> a mandatory doc comment, enforce it by requiring at least one of them to be
> present. Either parameters and returns are typed, or a doc block exists.
> Both may exist, of course.
>
> We've established in this email thread that it can be cluttering (and
> waste of effort) to require repeating of information when doing so adds no
> value. It is also my understanding that Phan and IDEs already understand
> either and both so we don't need them to be aware of which "should" exist.
>
> Is there value in enforcing removal of existing doc blocks after someone
> has written it? This seems to me like potentially a significant time sink
> with no return on that other because we enforced it as a new rule. If we
> agree there is no urgency in removing existing doc blocks or actively
> blocking CI when someone choose to write a doc block, then afaik we do not
> need new annotations like "hot" or "performance" or some other tag to
> surpress warnings about doc blocks.
>
> I do think it is important to preserve author intent when it comes to
> performance optimisations. However these are by no means limited to this
> new notion of saving native type overhead. There are all sorts of code
> optimisations. I believe we typically document these through an inline
> comment like "Optimization: ..." next to the code in question, in which the
> need for optimisation and sometimes (if non-obvious) how that optimisation
> is achieved, are mentioend. That should suffice I think in preserving the
> use case and e.g. prevent someone from re-introducing typing where it was
> previously removed for perf reasons.
>
> In other words: Codesniffer helps us avoid unknown types (in docblock
> and/or native type), and inline comments remind us about past performance
> optimisations. Do we need more? If so, what is the benefit/usecase for
> more? What do we risk if we don't?
>
> -- Timo
>
> 

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

[Lucas Werkmeister]

>
> We have already disabled some of these rules for new code in the Translate
> extension (ref
> <https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Translate/+/refs/heads/master/.phpcs.xml#27>
> )
>

Interesting – we do something similar in some Wikibase codebases (ref
<https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/0a3b07a195/.phpcs.xml#8>),
but I didn’t know there were other extensions doing the same thing.

Note that doc comments for properties are actually not required, as far as
> I can tell
>

I think that’s specific to MediaWiki core (ref
<https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/.phpcs.xml#8>),
and possibly other extensions that disable the
MediaWiki.Commenting.PropertyDocumentation.MissingDocumentation(Public|Protected|Private)
sniff – out of the box, I believe mediawiki-codesniffer requires property
documentation at the moment.


Am Fr., 28. Okt. 2022 um 17:51 Uhr schrieb Bartosz Dziewoński <
matma@gmail.com>:

> I agree, a lot of the doc comments become redundant when types are
> specified in type hints.
>
> Note that doc comments for properties are actually not required, as far
> as I can tell – you could replace:
>
>/** @var LinkRenderer */
>private $linkRenderer;
>
> …with:
>
>private LinkRenderer $linkRenderer;
>
> …today!, and no lint checks are going to stop you. I've been suggesting
> this for new code since we moved to PHP 7.4, which allows these type
> hints on properties.
>
> --
> Bartosz Dziewoński
> ___
> 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/



-- 
Lucas Werkmeister (he/er)
Software Engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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
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] Feedback wanted: PHPCS in a static types world

[Lucas Werkmeister]

ivate UserFactory $userFactory

  ) {

 parent::__construct( $page, $context );

  }

(Again, I’m not saying that all code should look like this – but I think we
have plenty of existing code that effectively carries no additional
information in its documentation, and which could be converted into this
form without losing anything.)

Cheers,
Lucas

-- 
Lucas Werkmeister (he/er)
Software Engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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
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: TDF is looking for community representatives

[Lucas Werkmeister]

 who appear to have no experience in
>> Wikimedia technical spaces. This is not a commentary on the people who
>> applied, but rather the TDF process.
>>
>> > If anyone out there is willing to contribute to the Technical
>> > Decision Forum process, please add your name to the list
>> > <
>> https://www.mediawiki.org/wiki/Technical_decision_making/Community_rep_nomination
>> >.
>>
>> I am fine with saying the quiet part out loud. Most volunteer developers
>> aren't interested in participating in the TDF because it treats them as
>> second-class participants. Contrasting to TechCom, which for all its
>> faults at least had public meetings that volunteers could participate in
>> as equals, the implementation of the TDF literally left volunteers as an
>> afterthought.
>>
>> At this point joining the TDF would only add the appearance of
>> legitimacy to a closed, non-transparent system that is antithetical to
>> Wikimedia development principles.
>>
>> > Brian and everyone else, if you have ideas on how we can have more
>> > community representation, please feel free to contact us at
>> > tdfsupp...@wikimedia.org <mailto:tdfsupp...@wikimedia.org>.  We need
>> to
>> > come together with ideas and solutions and remove negativity from the
>> > process.
>>
>> The negativity mostly exists because people (WMF staff and volunteers)
>> having spent months asking questions about TDF composition and decisions
>> and then were entirely ghosted.
>>
>> I currently count about 33 out of 40 TDF members being WMF Staff. Over
>> the past 90 days, only 49.4% of Gerrit patches came from WMF Staff[1].
>> My straw-dog proposal is that representation should be proportional,
>> i.e. WMF Staff should make up less than half of the TDF, or whatever
>> decision-making body replaces it.
>>
>> [1] https://wikimedia.biterg.io/
>>
>> -- Kunal / Legoktm
>> ___
>> 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 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/



-- 
Lucas Werkmeister (he/er)
Software Engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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
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:  Deploying MediaWiki at Wikimedia just got easier!

[Lucas Werkmeister]

I also have a question. The majority of my deployments are config changes,
not backports – can scap backport deploy those as well? I wouldn’t assume
so based on the name, but Tyler’s email mentions
operations/mediawiki-config…

Am Di., 27. Sept. 2022 um 23:51 Uhr schrieb Jeena Huneidi <
jhune...@wikimedia.org>:

> Hi Martin, thanks for the feedback!
>
> I often +2 all backports at the start of the window (or even prior the
>> window), because I want to save time. It enables me to deploy more patches
>> than I would be able to deploy with scap backport +2'ing it each patch
>> separately. I also parallelize some of the steps (such as, +2'ing a config
>> patch during the sync step), which also saves a bit of time. How would I do
>> this with scap backport? By +2'ing the patch manually, and then letting
>> scap backport figure out its magic?
>>
>
> Yes, you can do a +2 ahead of time and still use scap backport to do the
> remainder of the process, just be aware that if you do this and a patch
> ends up getting merged before the patch you are in the process of
> backporting with scap backport gets merged, then scap backport would end up
> syncing both patches at the same time (you will be given a warning and
> asked if you want to proceed).
>
> Also, I'd like to mention that many ordinary deployments currently require
>> a script to run. How would that work in scap backport world? When it asks
>> me for confirmation, I will wait, run the script, and then finish it, to
>> ensure the script runs at the right time
>>
>
> Good question...Do you mean the confirmation after syncing to debug
> servers? I assume you'd need to run the scripts right after pulling the
> changes to the deploy server. If so we would need to add an additional step.
>
> Jeena
>
> On Tue, Sep 27, 2022 at 2:23 PM Martin Urbanec <
> martin.urba...@wikimedia.cz> wrote:
>
>> Hi,
>>
>> Thanks for all the work on this project! I have some thoughts.
>>
>> I often +2 all backports at the start of the window (or even prior the
>> window), because I want to save time. It enables me to deploy more patches
>> than I would be able to deploy with scap backport +2'ing it each patch
>> separately. I also parallelize some of the steps (such as, +2'ing a config
>> patch during the sync step), which also saves a bit of time. How would I do
>> this with scap backport? By +2'ing the patch manually, and then letting
>> scap backport figure out its magic?
>>
>> Also, I'd like to mention that many ordinary deployments currently
>> require a script to run. How would that work in scap backport world? When
>> it asks me for confirmation, I will wait, run the script, and then finish
>> it, to ensure the script runs at the right time
>>
>> Martin
>>
>> út 27. 9. 2022 v 23:05 odesílatel Tyler Cipriani 
>> napsal:
>>
>>> *tl;dr*: use `scap backport ` to deploy MediaWiki backports
>>> 
>>>
>>> There’s now a *single step* to deploy changes to Wikimedia’s production
>>> MediaWiki.
>>>
>>> 勞 An 85% reduction in command remembering!
>>>
>>> On the deployment host run:
>>>
>>> scap backport 
>>>
>>> This works for any change to a live branch for mediawiki/core,
>>> extensions, skins, or operations/mediawiki-config.
>>> 
>>>
>>> More details (and a demo) inside Jeena Huneidi’s excellent write up
>>> <https://phabricator.wikimedia.org/phame/post/view/297/scap_backport_makes_deployments_easy/>
>>> .
>>>
>>> <3
>>>
>>> – Tyler Cipriani (on behalf of the RelEngers <https://releng.team> who 
>>> really
>>> do make dreams come true)
>>> Engineering Manager, Release Engineering
>>> 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 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/
>
>
>
> --
> Jeena Huneidi
> Software Engineer, Release Engineering
> Wikimedia Foundation
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> T

[Wikitech-l] Re: Phabricator monthly statistics - 2022-02

[Lucas Werkmeister]

The second month in a row with more closed than created tasks, nice! :)

Am Di., 1. März 2022 um 01:04 Uhr schrieb :

>
> Hi Community Metrics team,
>
> This is your automatic monthly Phabricator statistics mail.
>
> Accounts created in (2022-02): 251
> Active Maniphest users (any activity) in (2022-02): 1078
> Task authors in (2022-02): 516
> Users who have closed tasks in (2022-02): 293
>
> Projects which had at least one task moved from one column to another on
> their workboard in (2022-02): 295
>
> Tasks created in (2022-02): 2163
> Tasks closed in (2022-02): 2285
> Open and stalled tasks in total: 48923
> * Only open tasks in total: 48013
> * Only stalled tasks in total: 910
>
> Median age in days of open tasks by priority:
>
> Unbreak now: 3
> Needs Triage: 747
> High: 1084
> Normal: 1624
> Low: 2279
> Lowest: 2349
>
> (How long tasks have been open, not how long they have had that priority)
>
> Active Differential users (any activity) in (2022-02): 6
>
> To see the names of the most active task authors:
> * Go to https://wikimedia.biterg.io/
> * Choose "Phabricator > Overview" from the top bar
> * Adjust the time frame in the upper right corner to your needs
> * See the author names in the "Submitters" panel
>
> TODO: Numbers which refer to closed tasks might not be correct, as
> described in https://phabricator.wikimedia.org/T1003 .
>
> Yours sincerely,
> Fab Rick Aytor
>
> (via community_metrics.sh on phab1001 at Tue 01 Mar 2022 12:00:22 AM UTC)
> ___
> 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/
>


-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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
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] Deployment calendar format change

[Lucas Werkmeister]

Yes

I don’t personally care much about using VE on this page (yet), but having
section-edit links for each day seems much better than having to find the
right slot in a whole week’s worth of wikitext.

Am Fr., 26. März 2021 um 23:32 Uhr schrieb Zoran Dori <
zorandori4...@gmail.com>:

> It looks interesting and modern. I can say that I like it.
>
> Best regards,
> Zoran
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] How are value node IRIs generated?

[Lucas Werkmeister]

.protection.outlook.com/?url=https%3A%2F%2Fwww.wikidata.org%2Fw%2Fapi.php%3Faction%3Dwbgetclaims%26entity%3DQ232113%26property%3DP570%26formatversion%3D2=04%7C01%7Csteve.baskauf%40vanderbilt.edu%7C797bb01c807541e0427e08d89cef8134%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C1%7C637431899766406507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=m1N0TUImMZKjSYtuN7K%2B2kRtw6iVmR4tMPcyDE6SCHE%3D=0>
>
> 2:
> https://www.wikidata.org/wiki/Special:EntityData/Q42352198.ttl?flavor=dump
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wikidata.org%2Fwiki%2FSpecial%3AEntityData%2FQ42352198.ttl%3Fflavor%3Ddump=04%7C01%7Csteve.baskauf%40vanderbilt.edu%7C797bb01c807541e0427e08d89cef8134%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C1%7C637431899766406507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=m83NmCpSBZWff6dIyccNzoihvNf2eVW2yqYAPYHMPUQ%3D=0>
>
> -
>
> The difference between the snak and the value makes sense to me now. I was
> obtaining the hash from the JSON that is returned from the API as a
> response to a write operation. I wanted to use the hash as a way to record
> that the value had been written to the API. The problem with using the
> Query Service to get the value node IRI is the delay in the Query Service
> updater -- the value node IRI would not be immediately available from the
> Query Service but the response JSON from the API is available immediately
> after writing. Is the RDF output [2] also dependent on the Query Service
> Updater, or is it immediately available without the lag?
>
>
>
> Thanks for taking the time to answer my question.
>
>
>
> Steve
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] How to get total number of proofread and validated pages in any wikisource via api?

[Lucas Werkmeister]

https://ta.wikisource.org/wiki/*Mediawiki:Proofreadpage_quality0_category*
<https://ta.wikisource.org/wiki/Mediawiki:Proofreadpage_quality0_category>
tells you that the “quality 0” category on that wiki is named “*உரை
இல்லாமல்*”; you can then find that category at
https://ta.wikisource.org/wiki/Category:*உரை இல்லாமல்*
<https://ta.wikisource.org/wiki/%E0%AE%AA%E0%AE%95%E0%AF%81%E0%AE%AA%E0%AF%8D%E0%AE%AA%E0%AF%81:%E0%AE%89%E0%AE%B0%E0%AF%88_%E0%AE%87%E0%AE%B2%E0%AF%8D%E0%AE%B2%E0%AE%BE%E0%AE%AE%E0%AE%B2%E0%AF%8D>.
I hope that makes it clearer how the category names work?

Cheers, Lucas

Am Fr., 15. Mai 2020 um 14:34 Uhr schrieb Shrinivasan T <
tshriniva...@gmail.com>:

> > Extension:Proofread_Page uses categories to sort pages by quality, so
> > it would be easiest to use that system. The category names are defined
> > in Mediawiki:Proofreadpage_quality0_category through
> > MediaWiki:Proofreadpage_quality4_category, and you can query those
> > categories using the Categoryinfo or Categorymembers APIs. There is
> > also a `proofread` query property that returns the proofreading status
> > of a specified page.
>
> Hi,
>
> I dont see such category here.
>
> https://ta.wikisource.org/
>
> Checked here
> https://ta.wikisource.org/w/index.php?title=special:Categories=500
>
> Please give any live example.
>
> Thanks.
> Shrini
>
> --
> Regards,
> T.Shrinivasan
>
>
> My Life with GNU/Linux : http://goinggnu.wordpress.com
> Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com
>
> Get Free Tamil Ebooks for Android, iOS, Kindle, Computer :
> http://FreeTamilEbooks.com
>
> _______
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] First prototypes of possible technical improvements of templates

[Lucas Werkmeister]

https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Templates, I assume :)

Am Do., 26. März 2020 um 18:04 Uhr schrieb Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il>:

> Thanks! Do you have a link for the project page?
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
>
> ‫בתאריך יום ה׳, 26 במרץ 2020 ב-18:59 מאת ‪Michael Schönitzer‬‏ <‪
> michael.schoenit...@wikimedia.de‬‏>:‬
>
> > Hi,
> >
> >
> > In the german Technical Wishes survey 2019, the subject area "Working
> more
> > easily with templates" was chosen as the main focus. This means that the
> > Technical Wishes team of Wikimedia Deutschland will be working on this
> > topic for two years and tackle various problems in it.
> >
> > Since then, research into which improvements could be implemented has
> been
> > conducted. Over the coming weeks, a series of ideas for possible projects
> > will be published regularly on the project page. Everyone is invited to
> > evaluate and comment on them. For a balanced picture, feedback is sought
> > from Wikimedians with different levels of experience, working methods and
> > fields of work.  Based on this feedback, the Technical Wishes team will
> > consider whether to implement the ideas, revise them, or discard them in
> > favor of others. Depending on the outcome of this prototyping phase,
> there
> > might be another round of new ideas to provide feedback on later in the
> > year.
> >
> > Important: Since we want to present new prototypes regularly in the
> coming
> > weeks and we don't want to flood users' inboxes, we ask all interested
> > people to watch the project page.
> >
> > Cheers,
> >  Michael for the team technical Wishes @ Wikimedia Deutschland
> >
> > --
> > *M. F. Schönitzer*
> > Community Communication
> >
> > 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 Wissen der
> Menschheit
> > teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
> >
> > https://spenden.wikimedia.de
> >
> > Imagine a world in which every single human being can freely share in the
> > sum of all knowledge. Help us to achieve our vision!
> >
> > 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
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] Javascript Parse error on MW while using spread syntax

[Lucas Werkmeister]

Spread syntax and other ES6 syntax are not available in MediaWiki: see
T75714 <https://phabricator.wikimedia.org/T75714>.

Am Mi., 18. Dez. 2019 um 11:39 Uhr schrieb Egbe Eugene <
agboreug...@gmail.com>:

> Hi All,
>
> I am using spread syntax on a array in javascript and it works fine on
> command line but when I paste the code in a MW js file, I get the
> error *'JavaScript
> parse error: Parse error: Missing ) in parenthetical' *on the line where I
> used the where I used the spread syntax. Please I need some help on this
> because I don't know how to go about it. Thanks,
>
> --
> Eugene
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] Composer does not know mediawiki/mediawiki on dry-runs

[Lucas Werkmeister]

That was six years ago, predating extension registration – I would assume
that nowadays extensions are supposed to declare their compatible MediaWiki
versions in extension.json
<https://www.mediawiki.org/wiki/Manual:Extension_registration#Requirements_(dependencies)>
(details
<https://www.mediawiki.org/wiki/Manual:Extension.json/Schema#requires>).

Cheers,
Lucas

Am Fr., 15. Nov. 2019 um 16:38 Uhr schrieb Stephan Gambke via Wikitech-l <
wikitech-l@lists.wikimedia.org>:

> See
> https://github.com/wikimedia/mediawiki/commit/3307d4957925df319df2b84cfc3e6f1680d0632a
>
> "This change allows extensions to specify they depend on a specific
> version or version range of MediaWiki. This is done by adding the package
> mediawiki/mediawiki in their composer.json require section."
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, November 15, 2019 4:15 PM, David Barratt <
> dbarr...@wikimedia.org> wrote:
>
> > as far as I know, extensions shouldn't be declaring a dependency on
> MediaWiki in composer.json and if one is, it should probably be fixed.
> >
> > On Fri, Nov 15, 2019 at 9:50 AM Stephan Gambke via Wikitech-l <
> wikitech-l@lists.wikimedia.org> wrote:
> >
> >> When running `composer update` MediaWiki injects a mediawiki/mediawiki
> package, so extensions can declare a dependency on a particular MW version
> range.
> >> However, when doing a `composer update --dry-run` this package gets not
> injected causing the dry run to fail.
> >>
> >> Does anybody know a solution/workaround?
> >>
> >> Stephan
> >>
> >> ___
> >> 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



-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] OOUI v0.34.0 released - update to OOjs v3.0.0 & jQuery v3.4.1 (breaking changes), frameless buttons hover/active states, iOS Safari ProcessDialog scrolling fix & more

[Lucas Werkmeister]

Am Do., 5. Sept. 2019 um 02:59 Uhr schrieb Volker E. :

> Hello everyone,
> I'm excited to announce that we've released OOUI v0.34.0 today.
>
> Key highlights of this release are (summarizing since v0.33.0):
> - Update to OOjs v3.0.0, up from v2.2.2
>
> - Update to jQuery v3.4.1, up from v3.3.1
> Both updates above are considered breaking changes. Please carefully
> test if they affect your code.
>

Some links for convenience:
OOjs history:
https://gerrit.wikimedia.org/r/plugins/gitiles/oojs/core/+/v3.0.0/History.md
jQuery 3.4.0: https://blog.jquery.com/2019/04/10/jquery-3-4-0-released/
jQuery 3.4.1:
https://blog.jquery.com/2019/05/01/jquery-3-4-1-triggering-focus-events-in-ie-and-finding-root-elements-in-ios-10/
For what it’s worth, jQuery claim that “[t]here should be no compatibility
issues if upgrading from jQuery 3.0+.”

Cheers,
Lucas

-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] Declaring methods final in classes

[Lucas Werkmeister]

 someone wants to
> > >> volunteer to try to get it working, then we won't need to have this
> > >> discussion. But until someone does, the question remains.
> > >
> > > IMHO this would be a perfect compromise. I've filed T231419 for that,
> > and I
> > > also think that before discussing any further, we should try to see if
> we
> > > can install that tool.
> >
> > If I understand correctly, this would break as soon as the mock object
> > hits a
> > type hint of instanceof check. That won't fly.
> >
> >
> > --
> > 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
>
>
>
> --
> https://meta.wikimedia.org/wiki/User:Daimona_Eaytoy
> "Daimona" is not my real name -- he/him
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] Dealing with composer dependencies in early MediaWiki initialization

[Lucas Werkmeister]

Am Fr., 19. Juli 2019 um 18:18 Uhr schrieb Martin Urbanec <
martin.urba...@wikimedia.cz>:

> I vote for the first option (--server required), or simply set it to
> localhost by default, anyone capable of using a CLI installer can change
> this trivially IMO.
>

Anyone who’s using the CLI installer *manually* can do that, sure, but how
many scripts would be broken by making --server required? A lot of Travis
CI scripts, at least, judging by code search…
<https://codesearch.wmflabs.org/search/?q=maintenance%2Finstall\.php=travis>

Defaulting to localhost seems sensible to me.

-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] browser microphone audio upload gadgets?

[Lucas Werkmeister]

The LinguaLibra project <https://lingualibre.fr/wiki/LinguaLibre:Main_Page>
built the RecordWizard <https://github.com/lingua-libre/RecordWizard>
extension to record many pronunciation audio clips in-browser – it’s a bit
more specialized than a general audio recorder, but might still be useful
to you.

Am Mo., 8. Juli 2019 um 12:00 Uhr schrieb Andre Klapper <
aklap...@wikimedia.org>:

> On Sat, 2019-07-06 at 21:31 -0700, James Salsman wrote:
> > Is there a standard MediaWiki audio recorder, e.g. something from
> >
> https://developer.mozilla.org/en-US/docs/Web/API/MediaStream_Recording_API#See_also
> > which is working in some javascript gadget?
>
> AFAIK no.
>
> > My 2017 Google Summer of Code student made one for Wiktionary, but
> > I'm
> > not sure whether it is still working:
> > http://youtube.com/watch?v=8Euhu4Q7HF4=38m
>
> Where to find the recorder of your student?
>
> > It's based on less cross-platform technology than
> > https://www.npmjs.com/package/react-mic
>
> Also see https://phabricator.wikimedia.org/T166929 and
>
> https://strategy.wikimedia.org/wiki/Proposal:Record_and_upload_sound_clips_in_web_application
> which you've commented on.
>
> > What is the MediaWiki state of the art for cross-platform microphone
> > audio upload?
>
> For the records, a speech-to-text gadget for WikiEditor exists at
> https://meta.wikimedia.org/wiki/User:Urvaxhi/speechToText.js and e.g.
> https://stackoverflow.com/questions/16413063/html5-record-audio-to-file
> might provide you some hints that you could experiment with.
>
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
>
> _______
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] Thank You Tuesday

[Lucas Werkmeister]

I’m pretty sure I’ve said this before, even in another Thank you Tuesday
thread, but once again thank you to Legoktm and everyone else working
on MediaWiki
code search <https://codesearch.wmflabs.org/search/>! It continues to be an
invaluable tool when planning refactorings on code that might be used
elsewhere.

Thank you also to the Foundation’s Trust and Safety team, and the Code of
Conduct Committee.

Cheers,
Lucas

Am Di., 25. Juni 2019 um 16:13 Uhr schrieb Zppix :

> I wanted to restart the thank you Tuesday thread for this week. So heres
> my list of thanks:
>
> Paladox, and releng, for all you do for maintaining Gerrit, Phabricator,
> and CI so we can keep making so many needed changes to mediawiki and other
> software/projects.
>
> Andre, for sorting through hundreds if not thousands of tickets every day,
> without him, I’m sure phab would be a mess of unsorted tasks!
>
> Finally, thanks to all the volunteers and staff that are constantly
> deploying, and creating patches to make MediaWiki and related projects as
> bug-free and user friendly as possible.
>
>
>
> --
> Devin “Zppix” CCENT
> Volunteer Wikimedia Developer
> Africa Wikimedia Developers Member and Mentor
> Volunteer Mozilla Support Team Member (SUMO)
> Quora.com Partner Program Member
> enwp.org/User:Zppix
> **Note: I do not work for Wikimedia Foundation, or any of its chapters. I
> also do not work for Mozilla, or any of its projects. **
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister (he/er)
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] 1.34.0-wmf.6 status and cawikinews outage

[Lucas Werkmeister]

You can see a full list on the Wikimedia MediaWiki versions tool
<https://tools.wmflabs.org/versions/>.

Am Mi., 22. Mai 2019 um 18:30 Uhr schrieb RhinosF1 Wikipedia <
rhino...@gmail.com>:

> Looks like IRCCloud is having issues for me, would have asked in -tech but
> what's on Group 1
>
> On Wed, 22 May 2019 at 17:14, Antoine Musso  wrote:
>
> > Hello,
> >
> > When promoting group1 to MediaWiki 1.34.0-wmf.6, cawikinews has been
> > unreachable for roughly half an hour.
> >
> > The reason is that very early in the process of loading the wiki, a PHP
> > fatal error occurred.  I thus roll backed cawikinews to 1.34.0-wmf.5
> > which fixed it:
> >   https://phabricator.wikimedia.org/T224116
> >
> > Then eventually other wikis have been found to be missing localisation
> > strings indicating FlaggedRevs has other issues:
> > https://phabricator.wikimedia.org/T224124
> >
> >
> > I am thus rolling back group1 to 1.34.0-wmf.5 until FlaggedRevs is fixed.
> >
> >
> > The root cause is the conversion of MediaWiki extension FlaggedRevs to
> > the extension registry system. Apparently some settings are loaded later
> > than they used to and cause a Fatal when trying to interact with an
> > unset variable.
> >
> > The task is https://phabricator.wikimedia.org/T224116  If you are
> > familiar with operations/mediawiki-config load order and extension
> > registry loading, your help will be more than appreciated.
> >
> >
> > --
> > Antoine "hashar" Musso
> >
> >
> >
> > ___
> > 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



-- 
Lucas Werkmeister
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

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

[Lucas Werkmeister]

FYI, the improvement suggested in this thread back in January –

I wonder if it would be possible to allow comments with “recheck” commands?
>

+1 to Lucas' proposal, it should be possible to blame Jenkins within recheck
> comments.
>

– has now been implemented. You can add additional comments after the word
“recheck”, as long as “recheck” is the beginning of the comment and a word
on its own (e. g. “rechecking because of…” will not work, and neither will
“you need to wait until Txx is done and then recheck”). Working
examples would be:

recheck, T222131 was fixed
>
recheck to see if this happens consistently or not
>
recheck, SomeOtherExtension was broken and has been fixed in the meantime
>

Cheers,
Lucas


Am Mi., 27. Feb. 2019 um 19:34 Uhr schrieb Kosta Harlan <
khar...@wikimedia.org>:

> It would be nice to be able to add screenshots / images in comments. As it
> is, I put a screenshot in phab and link to that from Gerrit, but it’s
> cumbersome.
>
> Kosta
>
> > On Feb 26, 2019, at 7:25 PM, Paladox via Wikitech-l <
> wikitech-l@lists.wikimedia.org> wrote:
> >
> > PolyGerrit now supports cherry picking changes onto of other changes (as
> of 2.16.6 (not released yet)) (i did that change!).
> > PolyGerrit is also gaining support for cherry picking changes even with
> merge conflicts (also done by me)!
> > Also we are making CI comments pretty in PolyGerrit, see
> https://phabricator.wikimedia.org/F28291464 (this work was done by
> thcipriani for blubber, which i have worked on to roll it out to all jobs
> (if you use the new UI)).
> >
> >
> >
> >On Saturday, 9 February 2019, 03:08:34 GMT, Gergo Tisza <
> gti...@wikimedia.org> wrote:
> >
> > Here's a quickie: Alt-Shift+F (or Alt-F or whatever your browser uses
> for accesskeys) works in MediaWiki and Phabricator but not in Gerrit.
> > On Fri, Feb 8, 2019 at 11:35 AM Daniel Kinzler 
> wrote:
> >
> > * clicking on the name of a repo in a change should take me to a place
> where i
> > can browse that repo. It currently takes me to a list of tasks on that
> project,
> > which is quite useless. Same for the target branch.
> >
> >
> > You can click on the commit ID (in the new UI it's next to where you
> select the patchset version).If you want the gerrit admin page of the repo
> (which is fortunately a lot less often needed), you can switch back to old
> UI in the footer, and then click on the cog icon after the project name,
> instead of the project name itself.
> > * git review: a nice shortcut for "rebase on change number ". Same
> as the
> > rebase button in gerrit, but allowing me to resolve conflicts locally.
> >
> >
> > check out the commit to rebase on (git review -d if you really want to
> rebase on another changese, although that's almost never needed), then git
> review -x -X instead of -x if it's going to be a cherry-pick. On Fri,
> Feb 8, 2019 at 1:07 PM Stas Malyshev  wrote:
> >
> > One thing still missing for me is better ability to indicate which kind
> > of attention the item needs from me.
> >
> >
> > Yeah, that view is not great. Besides review scores, it would be super
> nice to be able to see in the list view the number of unresolved comments
> by me and by the changeset owner.
> > Couple of things for git review command too:
> >
> >
> > On that note (although I think that's a completely different universe,
> maintained by the OpenStack community, not the Gerrit one), two small
> annoyances I had with git-review:- When it generates the "multiple changes,
> Y/N" list, it compares HEAD with origin/master instead of the actual remote
> state of master. That can fail in a number of ways (shows already merged
> patches, sometimes shows all the changes which have been merged into core
> since I last did a git fetch), and performance-wise it is entirely
> pointless all the commands which trigger it involve heavy network traffic
> anyway.- When submitting multiple changes from a new repo, it sets up the
> commit hook for adding change IDs and adds a change ID to the last patch,
> but not the previous ones, so the submit will fail.
> > One useful command for me would be "check out a change and put it in a
> > branch named after topic of that change, overriding it if it existed".
> > This allows easy syncing of patches where more than one person
> > contributes to them.
> >
> >
> > Isn't that what git review -d does? The branch name is less useful, but
> usually the change id is at hand anyway.
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@list

Re: [Wikitech-l] Read access to patrolled flag in wikimedia API

[Lucas Werkmeister]

As far as I know Brian is right, the patrol status in recentchanges is not
public. However, the patrol log
<https://en.wikipedia.org/wiki/Special:Log/patrol> is, so with a bit of
effort you should be able to mostly reconstruct whether a revision is
patrolled or not. (I thought about reporting this as a [very minor]
security bug when I noticed it some months ago, but according to
Phabricator people seem to be well aware of this. I’m not sure why we don’t
make the patrol status public on recentchanges, to be honest.)

Cheers,
Lucas


Am Di., 5. März 2019 um 17:33 Uhr schrieb bawolff :

> Are you sure that patrol status is shown as colour coding on history pages?
> I'm pretty sure its not.
>
> If you mean kind of the dim yellow colour (like in
>
> https://en.wikipedia.org/w/index.php?title=List_of_programs_broadcast_by_Adult_Swim=history
> for the moment, but that will likely change soon), that means a pending
> change, which is a different system from patrolling.
>
> Note, on enwikipedia (but not other projects) RC patrolling is disabled,
> and only new page patrol is enabled (so only the first revision can have a
> patrol status).
>
> --
> Brian
>
> On Tue, Mar 5, 2019 at 4:13 PM Сибирев Кирилл 
> wrote:
>
> > Hi, we are using wikimedia http api for getting pages recent changes [1].
> > We'd like to be able to distinguish patrolled and unpatrolled revisions
> and
> > this feature is supported according to docs, but we still can't use it
> > because of access permissions. For example if i making requests like [2]
> or
> > [3] i am getting {"code": "permissiondenied", "info": "You need the
> > \"patrol\" or \"patrolmarks\" right to request the patrolled flag."}
> error.
> >
> > This API behaviour looks inconsistent to me, because anyone can see
> > patrolled/unpatrolled colored markup at wikipedia revision history web
> > pages. I think patrol right should be checked only at write (ones that
> mark
> > revisions patrolled or not) API requests and not for read requests.
> >
> > Is this behaviour really inconsistent and implemented that way due to
> > technical restrictions or am i missing something? Can it be changed, so
> we
> > can get patrolling information for revisions or maybe there are some
> > workarounds exist?
> >
> >
> > [1] https://www.mediawiki.org/wiki/API:RecentChanges
> > [2]
> >
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=title|patrolled=3
> > [3]
> >
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=title=patrolled=3
> >
> > ___
> > 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



-- 
Lucas Werkmeister
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

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

[Lucas Werkmeister]

Thanks for the guidance! I’ve submitted a config change at
https://gerrit.wikimedia.org/r/487037. (And also thanks for all your other
Gerrit work of course!)

Cheers,
Lucas

Am Di., 29. Jan. 2019 um 13:32 Uhr schrieb Paladox via Wikitech-l <
wikitech-l@lists.wikimedia.org>:

>  I believe that requires a regex  change in layout.yaml of
> integration/config.
> Also second thing that’s likely a bug in the zuul plugin.
> On Tuesday, 29 January 2019, 10:38:54 GMT, Daimona <
> daimona.w...@gmail.com> wrote:
>
>  +1 to Lucas' proposal, it should be possible to blame Jenkins within
> recheck comments. There's also another minor bug I encountered several
> times, and I'm unsure if it's already been fixed in 2.16. Have 2 different
> changes, A and B. If I write A's change ID in the commit message of B, then
> the UI will show that A is "needed-by" B, and this could lead to confusion
> especially if the dependency is the other way around, i.e. A depends-on B.
> And, BTW, thanks for your work on gerrit!
>
> Daimona
>
> Example A:
>
> https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/481549/
> Example B: https://gerrit.wikimedia.org/r/#/c/integration/config/+/481570/
>
> Il giorno mar 29 gen 2019 alle ore 11:21 Lucas Werkmeister <
> lucas.werkmeis...@wikimedia.de> ha scritto:
>
> > I wonder if it would be possible to allow comments with “recheck”
> commands?
> > Often I want to do something like “recheck because CI failed due to
> T”,
> > but if I send it as one review then it will not be recognized as a
> recheck.
> > Triggering a recheck any time the word “recheck” appears anywhere in a
> > review would probably cause too many false positives, but I think
> accepting
> > any review beginning with that word could be a good middle ground. (I’m
> not
> > sure if this would also be useful with other commands like “check
> > experimental”.)
> >
> > Am Di., 29. Jan. 2019 um 01:26 Uhr schrieb Paladox via Wikitech-l <
> > wikitech-l@lists.wikimedia.org>:
> >
> > > Hi, what would you like to see in gerrit or improved? I've been working
> > > been working on developing a plugin that pull's in zuul's status into
> > > PolyGerrit. See the running demo at https://imgur.com/a/uBk2oxQ . Im
> > also
> > > planning on adding "recheck" and "check experimental" as buttons to
> > > PolyGerrit's ui to improve CI. This will help new users who can recheck
> > > (and existing users that either forgot they can type this or haven't
> > > learned yet).
> > > Note that i cannot promise that anything suggested in this thread will
> be
> > > worked on, but i can try my best.
> > > See tasks https://phabricator.wikimedia.org/T214068 and
> > > https://phabricator.wikimedia.org/T214631 .
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> >
> > --
> > Lucas Werkmeister
> > Full Stack Developer
> >
> > Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> > Phone: +49 (0)30 219 158 26-0
> > https://wikimedia.de
> >
> > Imagine a world in which every single human being can freely share in the
> > sum of all knowledge. Help us to achieve our vision!
> > 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
> ___
> 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



-- 
Lucas Werkmeister
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

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

[Lucas Werkmeister]

I wonder if it would be possible to allow comments with “recheck” commands?
Often I want to do something like “recheck because CI failed due to T”,
but if I send it as one review then it will not be recognized as a recheck.
Triggering a recheck any time the word “recheck” appears anywhere in a
review would probably cause too many false positives, but I think accepting
any review beginning with that word could be a good middle ground. (I’m not
sure if this would also be useful with other commands like “check
experimental”.)

Am Di., 29. Jan. 2019 um 01:26 Uhr schrieb Paladox via Wikitech-l <
wikitech-l@lists.wikimedia.org>:

> Hi, what would you like to see in gerrit or improved? I've been working
> been working on developing a plugin that pull's in zuul's status into
> PolyGerrit. See the running demo at https://imgur.com/a/uBk2oxQ . Im also
> planning on adding "recheck" and "check experimental" as buttons to
> PolyGerrit's ui to improve CI. This will help new users who can recheck
> (and existing users that either forgot they can type this or haven't
> learned yet).
> Note that i cannot promise that anything suggested in this thread will be
> worked on, but i can try my best.
> See tasks https://phabricator.wikimedia.org/T214068 and
> https://phabricator.wikimedia.org/T214631 .
>
>
>
>
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] Unsubscription Request

[Lucas Werkmeister]

There’s an “unsubscribe” section on this link (which should be in the
footer of each email, though your client may hide it or make it less
prominent, not sure):
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Cheers,
Lucas

Am Di., 22. Jan. 2019 um 14:18 Uhr schrieb Ayushi Jain via Wikitech-l <
wikitech-l@lists.wikimedia.org>:

> I want to unsubscribe. Can't find any link on the emails sent by you.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

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

[Lucas Werkmeister]

Am Di., 22. Jan. 2019 um 13:25 Uhr schrieb Chad :

> Dumb straw man.
>

can we avoid this tone? thanks

Who said these people have too much workload?


Um, Thiemo himself has said this? Are you going to tell him that he’s wrong
about his own workload?

The blame attribution has zero insight into how
> busy someone is.
>

Correct, which is why it’s a bad idea to let it run loose and add people
who are already busy enough as reviewers.


> If it's a low-traffic repository there's likely to be fewer overall
> contributors.
> Fewer contributors increases the likelihood of people being qualified to
> review--whereas a high-traffic repo is more likely to have drive-by
> contributor less capable.
>

Well, many drive-by contributions are tree-wide: they are applied to a
large set of repositories collectively, e. g. all Wikimedia-deployed
extensions or even all repositories. If a repository has generally low
traffic, then these tree-wide drive-by contributions will make up a larger
ratio of its commits than in repositories with more repository-specific
commits.

I’m not sure if I phrased this well, but if repository A has 1000 specific
commits and 10 drive-by commits, and repository B has 20 specific commits
and the same 10 drive-by commits, then the drive-by commits will be ⅓ of
all commits in repository B but less than .1% in repository A.


> And if it's just one-line typofixing it'd be ideal to exclude those from
> the
> blame list--but 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.
>

True to some extent, but then we should err on the side of not adding the
reviewer, no? Otherwise we run the risk of overwhelming them with changes
they’re not even qualified to review, even if they had the time.


> Honestly, if you think "people who've edited the code in the past" are a
> poor
> person to ask for review then you do not understand how code review works.
>

Suggesting that Thiemo doesn’t understand how code review works is… bold,
in my opinion, let’s put it that way. May I point out that he’s one of the
top +2ers across all MediaWiki extensions
<https://lists.wikimedia.org/pipermail/wikitech-l/2019-January/091340.html>?

Cheers,
Lucas


-- 
Lucas Werkmeister
Full Stack Developer

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

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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

Re: [Wikitech-l] Thank you Tuesday

[Lucas Werkmeister]

I would like to thank our Code of Conduct committee
<https://www.mediawiki.org/wiki/Code_of_Conduct/Committee/Members>: Amir
Sarabadani, Tony Thomas, Lucie-Aimée Kaffee, Nuria Ruiz, and Rosalie
Perside, as well as the auxiliary members Tpt, Huji, Matanya, and
MusikAnimal. They have a tough job to do, most of which is invisible to the
rest of us (as it should be) unless things have gone wrong (as they
shouldn’t but sometimes do). Thank you for helping to make the Wikimedia
technical spaces a friendly and welcoming environment for all.

Happy holidays,
Lucas

Am Di., 25. Dez. 2018 um 10:42 Uhr schrieb Derick N. Alangi <
alangider...@gmail.com>:

> Hello Everyone,
>
> I'm starting today's "Thank you Tuesday" thread with a big Merry Christmas
> to all Wikimedia Developers. Wikimedia Developers are just awesome and they
> have a way of doing with things (Computers + MediaWiki = Wikipedia).
>
> I want to thank all developers in the movement that have helped me become
> better at my contributions to MediaWiki and other related Wikimedia
> projects. A short list below;
>
> Legoktm, Reedy, Pmiazga, Jdlrobson, Thiemo_WMDE, Bawolff, Jdforrester,
> Krinkle, Matmarex, Volker_E, Sklaporte, Hoo, Lydia_WMDE, Nikerabbit,
> Aklapper, Xqt, Framawiki, QuimGil, Apergos, Amire80, BryanDavis and MaxSem
> + the *entire* Wikimedia developer community.
>
> See, the list is so long as over time, I've worked with developers that
> have in one way or another shaped my way of doing things in the Wikimedia
> movement. The list above is just a short list and I want to take today to
> thank all of them for their awesomeness and for helping people get better
> at writing code in Wikimedia. You are all awesome and I love you all!
>
> Enjoy your Christmas / Holidays <3. Who do you want to thank on this
> special day?
>
> *--*
> *Derick*
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister
Full Stack Developer

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

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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

[Wikitech-l] Thank you Tuesday

[Lucas Werkmeister]

Hi all,

it is another Tuesday, so I’ll start this week’s round of thanks :)

   - Thanks to Legoktm and everyone else working on MediaWiki code search
   <https://codesearch.wmflabs.org/search/> for this awesome tool! It is
   incredibly useful to be able to search for all references to some code
   you’re going to touch – I would feel much less confident doing any kind of
   cross-repo refactoring without it.
   - Thanks to Ladsgroup, Brian Wolff and everyone else who supported me
   getting +2 rights :)

Have a nice day,
Lucas

-- 
Lucas Werkmeister
Full Stack Developer

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

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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

Re: [Wikitech-l] Changes to User Blocking

[Lucas Werkmeister]

Well, that function is also exposed externally, e. g. in the 'blocked'
field of the OAuth identity (what’s returned by Special:OAuth/identify).
What should happen to that in the future?

Am Mo., 5. Nov. 2018 um 15:41 Uhr schrieb Dayllan Maza :

> >
> > Also, are there any good reasons to continue checking
> > User::isBlocked()? If not, I think deprecating it would be a good idea.
>
>
> +1 for deprecating it.
> I think the name of that function is misleading to begin with 'cause even
> before "Partial Blocks" there were other actions besides edit that a block
> could prevent (like 'sendemail').
>
>
> On Sun, Nov 4, 2018 at 9:39 PM Kunal Mehta  wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Hi,
> >
> > On 11/2/18 12:58 PM, Alex Ezell wrote:
> > > *tl:dr;* On a wiki with the new Partial Blocks enabled (currently
> > > only testwiki), if the code is checking User::isBlocked() to
> > > determine edit rights, it should instead check User::isBlockedFrom(
> > > Title ). The code could also check isBlocked() &&
> > > $block->isSitewide(). If it doesn’t, the code may block users that
> > > shouldn’t be blocked.
> >
> > Based on a quick codesearch[1], this affects a lot of extensions, and
> > MediaWiki core itself. It would be nice if bugs (or patches!) could be
> > filed against code that needs updating.
> >
> > Also, are there any good reasons to continue checking
> > User::isBlocked()? If not, I think deprecating it would be a good idea.
> >
> > [1]
> > https://codesearch.wmflabs.org/search/?q=-%3EisBlocked%5C(=nope=
> > =
> > <
> https://codesearch.wmflabs.org/search/?q=-%3EisBlocked%5C(=nope==
> >
> >
> > - -- Legoktm
> > -BEGIN PGP SIGNATURE-
> >
> > iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlvfrU4ACgkQUvyOe+23
> > /KLWYg/+LR3h0UjQwwomCba9VrnwvMYApsP7xHnZUvukMqF/mjNvKFnR1Rs/pEWj
> > 10IU0QMVxBB6cA47xLY9oYWoMTs6uO4qcLgJrHGxsHdaklOeaukqTZZWh4ubdhs1
> > KHJOoxNAfzZvD7f0IPsT1w5mlu68ehAMV5OfLH5QtqhViOBh8yCUSPn5dwpeY1k2
> > 28Ped42jst4U1PUCVELSf5hQe7KUCvE0xr5mcnT0rq5rta7nw9nCXeIaIQLUSP/i
> > ouh0ZE1vf3ScsqmM0AV2hqc2GOdtzwaMPPKXFTbP3UQjAXWYDOs7UdITLOGbQupj
> > JAW3vEEZEu6xd0TcvuQ1o5S9szHVxqJUOelqaZMn/w+8xOBfAQ4wcskqaEcE1Y2f
> > X0pneuAx473kJOfGVEv/RbAnf8Vc9hXkRoSK7OY6f0tJPYyMreWbc7H15gUVRA4X
> > jzcAH6VYOxxUX4trznNArmnGIisjylweZlJvTSWUawTzMNCUEieD4hWKmey8sX1r
> > YhQsoyuy4JkumXqY6Eu9XkVCHNQg+JZkRfGB5EudzoUAqlL5D1NhcHx+1EhaELQd
> > qNNVtPMH79vDUHs18Hn/np9eX8cHIyfDGhI5yHt4m3bx111p3I/hOo57yaV9WbrP
> > 3C/USolKKxNUPgoPPP/3KKa+skDt9wKvPIU5lvDd9F9TKbm8hcc=
> > =q47C
> > -END PGP SIGNATURE-
> >
> > ___
> > 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



-- 
Lucas Werkmeister
Full Stack Developer

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

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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

Re: [Wikitech-l] Avatars coming to gerrit

[Lucas Werkmeister]

What if I don’t own the copyright to my photo
<https://commons.wikimedia.org/wiki/File:Lucas_Werkmeister,_2017_%2B_WMDE_Logo.jpg>?
The current format of the LICENSE file allows me to specify a different
license, but not who the image should be attributed to.

Am Di., 9. Okt. 2018 um 12:52 Uhr schrieb Niklas Laxström <
niklas.laxst...@gmail.com>:

> la 6. lokak. 2018 klo 3.44 Paladox via Wikitech-l
> (wikitech-l@lists.wikimedia.org) kirjoitti:
>
> > We also have a license file for you to specify the license of your image
> at
> https://gerrit.wikimedia.org/r/plugins/gitiles/All-Avatars/+/refs/heads/master/LICENSE
> > If none is specified then it defaults to GPL 2.0+.
>
> What if one is uncomfortable or unwilling to license a photo of
> themselves under an open source licence?
>   -Niklas
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister
Software Developer (working student)

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

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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

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

[Lucas Werkmeister]

I’m not an expert on dewiki, but I assume they still want word-ending links
for simple stuff like [[Gesetz]]e (plural), [[Finger]]s (genitive). I would
guess these cases are still more common than the long compound words where
the  trick is used.

Am Do., 4. Okt. 2018 um 17:44 Uhr schrieb Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il>:

> I'm really not an expert on German. However, I have been slowly analyzing
> common trails in some other languages with purpose of doing smarter link
> trailing some day. It's a very crazy and long term pet project :) In
> theory, I could do it for German, too.
>
> בתאריך יום ה׳, 4 באוק׳ 2018, 18:39, מאת C. Scott Ananian ‏<
> canan...@wikimedia.org>:
>
> >
> >
> https://hu.wikipedia.org/w/index.php?title=Grafikus_matroid=prev=20406147
> > illustrates another use: separating - and { in the unusual case where
> this
> > string is wanted and you *don't* want language converter markup.  ie
> > `-{foo}-` is different from `-{foo}-`.  You don't usually notice
> > this because languageconversion is disabled in many wikis, but it can
> cause
> > problems if unbalanced syntax is used inside a template argument, like:
> > `{{foo|-{bar}}`.  Here you need to use `{{foo|-{bar}}`, even if
> > LanguageConverter is not enabled.
> >
> > Amir -- 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?  Can they be automatically
> > distinguished?
> >  --scott
> >
> > On Thu, Oct 4, 2018 at 11:17 AM Bináris  wrote:
> >
> > > Here is a list of removals. :-)
> > >
> > >
> >
> https://hu.wikipedia.org/w/index.php?title=Speci%C3%A1lis:Szerkeszt%C5%91_k%C3%B6zrem%C5%B1k%C3%B6d%C3%A9sei/BinBot=20180912205000=BinBot=28
> > >
> > >
> > > Amir E. Aharoni  ezt írta (időpont:
> 2018.
> > > okt. 4., Cs, 16:47):
> > >
> > > > Thanks. Can you please give some particular examples?
> > > >
> > > > בתאריך יום ה׳, 4 באוק׳ 2018, 17:41, מאת Bináris ‏<
> wikipo...@gmail.com
> > >:
> > > >
> > > > > Amir E. Aharoni  ezt írta (időpont:
> > > 2018.
> > > > > okt. 4., Cs, 16:18):
> > > > >
> > > > > >
> > > > > > This sentence shows the template used at the
> end.{{Citation
> > > > > > needed|reason=Reliable source needed for the whole
> > > > sentence|date=October
> > > > > > 2018}}
> > > > > >
> > > > > > However,  has less trivial use cases, that are not quite
> > the
> > > > same
> > > > > > as demonstrating wiki syntax. One such usage I'm aware of is
> > linking
> > > a
> > > > > part
> > > > > > of a long compound German word, for example "[[Schnee]] > > > > />reichtum".
> > > > > > It produces the desired effect, however it is a bit of a hack:
> the
> > > word
> > > > > > "nowiki" doesn't have anything to do with dividing compound
> words.
> > > This
> > > > > use
> > > > > > is quite common in the German Wikipedia because of the nature of
> > the
> > > > > German
> > > > > > language, which has a lot of long compound words.
> > > > > >
> > > > >
> > > > > We have a lot of them in Hungarian Wikipedia, and we have just
> > decided
> > > to
> > > > > eradicate them, because this is a non-desired effect. :-)
> > > > > ___
> > > > > 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
> > >
> > >
> > >
> > > --
> > > Bináris
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> >
> > --
> > (http://cscott.net)
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > 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



-- 
Lucas Werkmeister
Software Developer (working student)

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

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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

Re: [Wikitech-l] My Phabricator account has been disabled

[Lucas Werkmeister]

Am Do., 9. Aug. 2018 um 13:50 Uhr schrieb Aryeh Gregor :

> To begin with, punishment of any infraction that occurred in a
> publicly-accessible forum such as Phabricator can be public.  If the
> infraction itself can remain public, the punishment for it can also.
> That seems like a good starting point.


This argument doesn’t work at all, IMHO. Suppose I revealed the real name
of an anonymous contributor in a Phabricator comment (accidentally or as
deliberate doxxing) – just because I thought that this comment could be
public surely doesn’t mean that it should stay public, or that the
subsequent interaction with the CoCC should be public.

Of course, I’m not saying that what happened here was equivalent to doxxing
– I just don’t think it at all follows that the punishment should be public
just because the infraction was.

Cheers,
Lucas

-- 
Lucas Werkmeister
Software Developer (working student)

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

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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

Re: [Wikitech-l] My Phabricator account has been disabled

[Lucas Werkmeister]

Can we please avoid jumping to conclusions like “Ladsgroup [was] enforcing
the CoC out of their personal feelings” or that this was an “immediate
escalation”, when the only information we have in this thread is a quoted
email that the author probably never intended to be a comprehensive summary
of the situation in the first place, and which was only relayed to this
list through a non-neutral party?

Cheers,
Lucas

Am Mi., 8. Aug. 2018 um 16:45 Uhr schrieb Dan Garry :

> On 8 August 2018 at 14:29, Alex Monk  wrote:
>
> > Are you trying to ban people discussing CoC committee decisions publicly?
> > Not that it even looks like he wrote grievances.
>
>
> Hardly. I have absolutely nothing to do with the administration of this
> list, nor the authority to set what is discussed on this list, nor any
> involvement in the Code of Conduct, all of which you are well aware.
>
> Dan
>
> --
> Dan Garry
> Lead Product Manager, Editing
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Lucas Werkmeister
Software Developer (working student)

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

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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

Re: [Wikitech-l] GSoC 2018 Introduction: Prssanna Desai

[Lucas Werkmeister]

Welcome Prssanna! I’m excited to see the improvements you’ll bring to WDQS
:)
Cheers, Lucas

Am So., 6. Mai 2018 um 07:46 Uhr schrieb Pine W <wiki.p...@gmail.com>:

> Welcome, Prssanna. Because your project involves WDQS, I am cross-posting
> your introduction to the Wikidata mailing list.
> Good luck with your project.
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
>  Original message From: prssanna desai <prs...@gmail.com>
> Date: 5/5/18  5:56 AM  (GMT-08:00) To: wikitech-l@lists.wikimedia.org
> Subject: [Wikitech-l] GSoC 2018 Introduction: Prssanna Desai
> Greetings,
> I'm Prssanna Desai, an undergraduate student from NMIMS University, Mumbai,
> India and I've been selected for GSoC '18.
>
> *My Project:* *Improve Data Explorer for query.wikidata.org
> <http://query.wikidata.org>*
>
> The project consists of making usability improvements to the Explorer
> Dialog and the Graph Explorer of WDQS.
> You can read my full proposal here:
> https://phabricator.wikimedia.org/T189669
>
> I’d like to thank my mentors Jonas Kress, Stas Malyshev and Lucas
> Werkmeister for giving me this wonderful opportunity!
>
> Regards,
> Prssanna Desai
> ___
> 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



-- 
Lucas Werkmeister
Software Developer (Intern)

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

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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

Re: [Wikitech-l] What ways are there to include user-edited JavaScript in a wiki page? (threat model: crypto miners)

[Lucas Werkmeister]

A restrictive script-src in a Content-Security-Policy (RFC
<https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy>,
T135963 <https://phabricator.wikimedia.org/T135963>) could have helped with
this. Alternatively, a report-mode CSP could at least have brought this to
global operators’ attention, though I don’t know if they would’ve been
faster to react than the fawiki community’s seven minutes.

Cheers,
Lucas

2018-03-14 17:03 GMT+01:00 Amir Ladsgroup <ladsgr...@gmail.com>:

> That already happened and the user got blocked indefinitely immediately
> after the incident. The JS was there for seven minutes which bad enough
> IMO.
>
> One thing is that Persian Wikipedia community is working to strip the right
> of editing mediawiki ns from the templateeditor user group:
> https://fa.wikipedia.org/w/index.php?oldid=22370489#%D9%
> 86%D8%B8%D8%B1%D8%AE%D9%88%D8%A7%D9%87%DB%8C_%D8%A8%D8%B1%
> D8%A7%DB%8C_%DA%AF%D8%B1%D9%81%D8%AA%D9%86_%D8%AF%D8%B3%
> D8%AA%D8%B1%D8%B3%DB%8C_%D9%88%DB%8C%D8%B1%D8%A7%DB%8C%D8%
> B4_%D9%81%D8%B6%D8%A7%DB%8C_%D9%86%D8%A7%D9%85_%D9%85%D8%
> AF%DB%8C%D8%A7%D9%88%DB%8C%DA%A9%DB%8C_%D8%A7%D8%B2_%D9%88%
> DB%8C%D8%B1%D8%A7%DB%8C%D8%B4%DA%AF%D8%B1%D8%A7%D9%86_%D8%
> A7%D9%84%DA%AF%D9%88
>
> Other things include protecting us from this type of js inside the
> mediawiki. That's going to be difficult.
>
> Best
>
> On Wed, Mar 14, 2018 at 4:59 PM Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com> wrote:
>
> > In my opinion, such accounts should be globally blocked btw. It is a
> > grave breach of trust and such accounts cannot be trusted anywhere
> > else either. Thanks for playing, but goodbye for ever.
> >
> > DJ
> >
> > On Wed, Mar 14, 2018 at 3:42 PM, Brian Wolff <bawo...@gmail.com> wrote:
> > > On Wednesday, March 14, 2018, David Gerard <dger...@gmail.com> wrote:
> > >> What ways are there to include user-edited JavaScript in a wiki page?
> > >>
> > >> I ask because someone put this revision in (which is now deleted):
> > >>
> > >>
> > >
> > https://fa.wikipedia.org/w/index.php?title=%D9%85%D8%AF%
> DB%8C%D8%A7%D9%88%DB%8C%DA%A9%DB%8C:Common.js=next&
> oldid=22367460=en
> > >>
> > >> You can't see it now, but it was someone including a JavaScript
> > >> cryptocurrency miner in common.js!
> > >>
> > >> Obviously this is not going to be a common thing, and common.js is
> > >> closely watched. (The above edit was reverted in 7 minutes, and the
> > >> user banned.)
> > >>
> > >> But what are the ways to get user-edited JavaScript running on a
> > >> MediaWiki, outside one's own personal usage? And what permissions are
> > >> needed? I ask with threats like this in mind.
> > >>
> > >>
> > >> - d.
> > >>
> > >> ___
> > >> Wikitech-l mailing list
> > >> Wikitech-l@lists.wikimedia.org
> > >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > > You need editinterface, edituserjs, or some of the centralnotice
> related
> > > rights (or the steward related rights to give yourself these rights).
> > >
> > > Any method that does not involve editinterface or a related right that
> is
> > > normally restricted to administrator (or higher group) should be
> > considered
> > > a serious security issue in mediawiki and reported immediately.
> > >
> > > --
> > > Brian Wolff
> > > ___
> > > 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
>



-- 
Lucas Werkmeister
Software Developer (Intern)

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

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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