Re: [Wikimedia-l] [Wikitech-ambassadors] Translatable modules

2020-09-22 Thread Amir E. Aharoni
‫בתאריך יום ג׳, 22 בספט׳ 2020 ב-19:08 מאת ‪Gerard Meijssen‬‏ <‪
gerard.meijs...@gmail.com‬‏>:‬

> Hoi,
> Would it be considered for projects that are not the initial target to opt
> in.. I expect that particular in the smaller projects this will be really
> welcome and beneficial.
>

The short answer is "yes".

The longer answer is that even though it will be possible, with the current
scope of this project it probably just won't be very useful on sites other
than the multilingual ones, which I mentioned in the first email.

Once this phase is implemented and deployed, it's quite possible that at a
later stage it will be enhanced and become useful for other sites, but
there will be a separate discussion about that.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 



[Wikimedia-l] Translatable modules

2020-09-22 Thread Amir E. Aharoni
Hi,

*Crossposting to Wikimedia-L, Wikitech-L, MediaWiki-L, and
Wikitech-Ambassadors. You can reply to the mailing list, but the ideal
place for further discussion is the talk pages of the wiki pages to which I
link below.*

There's a new proposal to localize Lua modules in a more modern, safe, and
convenient manner: https://www.mediawiki.org/wiki/Translatable_modules .

In the foreseeable future it will only affect multilingual sites, such as
Wikidata, Commons, Meta, and mediawiki.org, but at a later time it may also
be deployed on Wikipedias and other projects.

It will be great if experienced module developers could take a look at the
project page, https://www.mediawiki.org/wiki/Translatable_modules , and its
subpages, especially https://www.mediawiki.org/wiki/Translatable
modules/Proposed solutions . Your feedback will be very helpful in
implementing this project in a way that really benefits all the editors.

Thanks!

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 



[Wikimedia-l] Language Showcase, May 2020

2020-05-25 Thread Amir E. Aharoni
Hello,

This is an announcement about a new installment of the Language Showcase, a
series of presentations about various aspects of language diversity and its
connection to Wikimedia Projects.

This new installment will deal with the latest design research about the
upcoming section translation feature for Content Translation.

This session is going to be broadcast over Zoom, and a recording will be
published for later viewing. You can also participate in the conversation
on IRC or with us on the Zoom meeting.

Please read below for the event details, including local time, joining
links and do let us know if you have any questions.

Thank you!

Amir

== Details ==

# Event: Language Showcase #5

# When: May 27, 2020 (Wednesday) at 13:00 UTC (check local time
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200527T1300 )

# Where:

Join Zoom Meeting
https://wikimedia.zoom.us/j/9708103

Meeting ID: 970 8103 

IRC - #wikimedia-office (on Freenode)

# Agenda:

The latest design research about the upcoming section translation feature
for Content Translation.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] An encyclopedia must be conservative (?)

2020-05-29 Thread Amir E. Aharoni
Most people in the world (or at least in the U.S.) use the terms
"conservative" and "progressive" when talking about politics, and associate
them with bundles of viewpoints on society, economics, religion, and so on.
The political aspect is partly relevant to Wikipedia, too, but if we just
take them as words with literal meanings, we'll have to talk about some
other aspects, too. Here are the ones I can think of, in a mostly-random
order:

Aspect1: Fact-checking, trust, and reliability

Fact-checking, trust, and reliability on Wikpiedia should be conservative,
but in a way that is thoughtful and open to challenging itself. It's a
difficult and often overlooked point. In non-wiki encyclopedias the writers
are selected by the publisher: the publisher trusts the writers, and the
readers trust the publisher's brand. I'm intentionally not saying "printed"
or "old" encyclopedias, but "non-wiki" encyclopedias. They are still being
produced, in print and digitally—see my Wikimania 2014 talk[1] for just one
example.

Our wiki model wants to let everyone write, and writers are not pre-vetted,
so our solution for trust is demanding reliable sources, which is why
Wikipedia articles in many languages have a lot of footnotes. Other
encyclopedias usually don't have footnotes, although some do have a
"further reading" or "bibliography" at the end of some articles, but they
are provided for further research and not for proof. The Wikpiedia attitude
to sources, known as "Verifiability" in the English Wikipedia, solidified
around 2005. It makes a lot of sense for a wiki encyclopedia, and it is one
of our cornerstones, at least in the larger languages. (The details of the
policy in each language may be different, but the general idea is the same.
If it's significantly different in your language, please tell me.)

The problem with this attitude is that it outsources trust to other
publishers: non-wiki encyclopedias, academic journals, newspapers and news
sites, and occasionally other sources. The better-known issue with it is
deciding which external sources are reliable. The less-known, but perhaps
even trickier issue is what to do about topics that should be covered in an
encyclopedia, but about which there is no coverage in what Wikipedia
editors would call "reliable sources" because of systemic bias, that is
because the people who are involved with the topic had historically less or
no access to academic publishing? Some people propose relaxing the demand
for external reliable source for such topics, and while I'm totally on
board with the social justice aspect of this attitude, it doesn't suggest a
solution to the trust problem: some people will use it to enrich Wikipedia
with information that can't be found elsewhere, but some people may abuse
it to add made up stuff.

I have a proposed solution for this problem, and although some people would
disagree, I call it conservative: Keep the demand for verifiability, and
help people who have been historically disadvantaged get access to trusted
academic institutions and conduct and publish their research outside of
Wikipedia first. The WMF and its partners can do it. It's not easy, but I
just don't see any other solution to the trust issue. I call this attitude
"conservative" because I want to preserve the trust in external knowledge
institutions, and keep the "outsourcing". It's not exactly what the current
strategy recommendation[2] says, and I respectfully doubt that that
recommendation is going to work.

Aspect 2: Technology

Should be reasonably progressive, of course, in the sense of using
reasonably modern design principles and implementations. We are outdated in
some ways: talk pages are a disaster, the jQuery JavaScript framework is
quite old (and is being gradually replaced), many templates are too
difficult to maintain, code review and feature deployment are not as robust
as they should be, and there are many other issues.

We shouldn't be *too* progressive, though: we should not jump on every
buzzword bandwagon and not to change design concepts and development
frameworks every year, as some sites do. It's probably good that we are not
jumping on the blockchain bandwagon at all, and that we are jumping on the
artificial "intelligence" bandwagon in a careful and measured way (ORES is
helpful, but keeps the human decision in the loop).

Talk pages are a particularly curious kind of disaster. Many Wikipedians
tend to be very conservative about them and don't want any technology
changes in them, but talk pages are not a continuation of any previous
tradition of encyclopedic writing or of Internet culture—they are
Wikipedia's own invention. Is it good that the community, or at least some
parts of it, is so conservative about it? Not really, and it causes serious
damage as time goes by, but arguing with these passionate people is
challenging.

Aspect 3: Presentation style

Should be conservative in the sense of continuing a centuries-old tradition
of writing 

Re: [Wikimedia-l] Language Showcase, July 2020

2020-07-22 Thread Amir E. Aharoni
‫בתאריך יום א׳, 19 ביולי 2020 ב-18:47 מאת ‪Jan Ainali‬‏ <‪
ainali@gmail.com‬‏>:‬

> Has this also been announced anywhere on-wiki?
>

Sorry, no, and I guess that it's a bit too late for it now for this edition.

However, I'm happy to publish it on a wiki for the next time. Where would
be a good place?
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] [Mediawiki-i18n] Language Showcase, July 2020

2020-07-22 Thread Amir E. Aharoni
בתאריך יום א׳, 19 ביולי 2020, 15:50, מאת Asaf Bartov ‏:

> Will there be a written summary (of the technical updates, in particular)
> for those who would miss or won't make time for the presentation?
>

I didn't plan to do it, but now that you're asking for it, yeah, I'll
publish it.

The Language team also publishes a monthly report, for example
https://www.mediawiki.org/wiki/Wikimedia_Language_engineering/Reports/2020/June
. It usually includes updates about translatewiki and the Translate
extensions, as well as updates about Content Translation and other features
that we maintain.

Finally, as I mentioned, there will also be a recording.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


[Wikimedia-l] Language Showcase, July 2020

2020-07-19 Thread Amir E. Aharoni
Hello,

This is an announcement about a new installment of the Language Showcase, a
series of presentations about various aspects of language diversity and its
connection to Wikimedia Projects.

This next installment will deal with the translatewiki website, the
Translate extension in general, the latest technical updates in both of
them, and some upcoming projects.

This session is going to be broadcast over Zoom, and a recording will be
published for later viewing.

Please read below for the event details, including local time, joining
links and do let us know if you have any questions.

Thank you!

Amir

== Details ==

# Event: Language Showcase #6

# When: July 22, 2020 (Wednesday) at 13:00 UTC (check local time
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200722T1300 )

# Where:

Join Zoom Meeting
https://wikimedia.zoom.us/j/99585961221

Meeting ID: 995 8596 1221

# Agenda:

The translatewiki website, the Translate extension in general, the latest
technical updates in both of them, and some upcoming projects.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


[Wikimedia-l] more Planet RSS maintainers wanted

2021-04-16 Thread Amir E. Aharoni
Hi!

I'm not sure how it happened, but for a while I've been the main maintainer
of the Wikimedia Planet: https://meta.wikimedia.org/wiki/Planet_Wikimedia

The Wikimedia Planet is a bunch of RSS feeds that aggregate posts from
various blogs in several languages that are related to Wikimedia in one way
or another. Some people think that RSS is an outdated technology, but there
are also quite a lot of people, including myself, who beg to disagree, and
find RSS readers more convenient and nicely organized for getting news
updates than social networks or algorithmic aggregators. (I used Google
Reader and then I switched to Feedly; there are many other RSS readers.)

It's not so *bad* that I'm the main maintainer because there's very little
work to do and it's actually quite fun. Nevertheless, it's not very good
that I'm practically the only one, because sometimes maintenance requests
can get stuck for months, and there's also that whole notion of [[Bus
factor]].

So, if anyone is interested in joining me in this *very easy and fun*
effort, please just take a look at
https://meta.wikimedia.org/wiki/Planet_Wikimedia and try addressing the
current requests (there are very few of them). And then check the same page
once a month or so. If you know how to use Git, then you have all the
necessary skills to do it. If you don't know Git, I'll be happy to teach
you the necessary basics—it's not as difficult and scary in 2021 as it was
in 2011. Just contact me off-list.

Thanks :)

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 



[Wikimedia-l] calculating autoconfirmed age and edit count

2021-10-04 Thread Amir E. Aharoni
I've been involved in this lengthy circular debate: What should be the
autoconfirmed age and article count in the Hebrew Wikipedia? See
https://phabricator.wikimedia.org/T243076 if you curious about this
particular one, but I'd love to ask a more global question:

How were these numbers calculated originally?

For the account age, the default is four days, or five or seven days for a
few wikis.

For the edit count, the default is zero, but several wikis have 5, 10, 25,
or 50.

(See
https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php
and search for "wgAutoConfirmAge" and "wgAutoConfirmCount".)

Some wikis have groups, usually called "extended confirmed", and with
higher counts; for example, 500 edits in English and some other languages
(search for wmgAutopromoteOnceonEdit on the same page).

So, how did the people arrive at these numbers? Why is it four days by
default? Is it all just intuition and guesses, or was there any research
behind it?

Is it *good* that four days is the default for everyone, until someone
bothers to update it (most wikis don't)? Or is it just a coincidence that
was defined for a certain wiki and applied elsewhere? And when it's
updated, why is it updated to one number and not some other?

While I am an ardent supporter of the "anyone can edit" principle, it makes
general sense to have some restrictions based on edit count, account age,
and perhaps other parameters. But HOW are they calculated? Would it make
sense to anyone to start making some calculations around it and optimize
the number for wikis of different sizes?

I'd imagine that there could be a calculation that says "in a given wiki,
the chance of being reverted or blocked goes down after X days and X
edits", and this number is probably different for every wiki (maybe there
already is such a calculation somewhere). This could possibly be a starting
point for a good calculation of a threshold; it wouldn't be perfect,
because in some wikis it can perpetuate community practices which may be
biased against new editors, but at least it's based on data and not on
guesses.

In the English Wikipedia 2016 discussion[1] about adding the "extended
confirmed" group, I found one comment, by User:Opabinia regalis, which
corresponds to my thinking on the topic: "The thresholds being used for
these restrictions are essentially arbitrary, and we don't have a strong
evidence base yet that they are well-chosen."

Perhaps after twenty years we could start actually calculating these
thresholds, and not just come up with arbitrary numbers? Or is there really
no demand for smart and research-based decisions about these thresholds?

[1]
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_129#New_usergroup_with_autopromotion_to_implement_arbitration_%2230-500%22_bans_as_a_page_protection

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/ONYNFNACK34LQLTBRHI6M56LBJHFBSKW/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] "content was" when deleting pages - is it useful?

2022-01-17 Thread Amir E. Aharoni
Hallo!

There's an old MediaWiki feature: When an administrator deletes a page, a
bit of its content is automatically added to an edit summary. This is later
viewable in deletion logs.

If you edit in the English, German, or Italian Wikipedia, then you haven't
actually seen this feature in years, because administrators in these wikis
essentially removed it by locally blanking the system messages that make it
work.

In many other wikis, however, this feature is still working.

Is it actually useful? Or should it perhaps be removed?

Here's a Phabricator task about it:
https://phabricator.wikimedia.org/T299351

If you have an opinion, weigh in there or here.

Thanks!

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/4ZONY3L5LEPO45POJ2SWTPHKFFIJ63UR/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: "content was" when deleting pages - is it useful?

2022-01-17 Thread Amir E. Aharoni
Yes, that's what I imagine.

In the Hebrew Wikipedia, this feature is still active, and someone wondered
what is it actually good for. When I delete pages, I definitely erase
things that may be in any way problematic. And sometimes I delete them even
if they aren't. If this feature didn't exist, it wouldn't bother me. But
that's my experience--maybe I'm missing something.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬


‫בתאריך יום ב׳, 17 בינו׳ 2022 ב-16:35 מאת ‪Newyorkbrad‬‏ <‪
newyorkb...@gmail.com‬‏>:‬

> The problem with this feature was that when the deleted material was
> libelous, offensive, etc., it would still automatically be copied into the
> deletion summary, which served to defeat the entire purpose of deleting it.
>
> Newyorkbrad/IBM
>
>
> On Monday, January 17, 2022, Amir E. Aharoni 
> wrote:
>
>> Hallo!
>>
>> There's an old MediaWiki feature: When an administrator deletes a page, a
>> bit of its content is automatically added to an edit summary. This is later
>> viewable in deletion logs.
>>
>> If you edit in the English, German, or Italian Wikipedia, then you
>> haven't actually seen this feature in years, because administrators in
>> these wikis essentially removed it by locally blanking the system messages
>> that make it work.
>>
>> In many other wikis, however, this feature is still working.
>>
>> Is it actually useful? Or should it perhaps be removed?
>>
>> Here's a Phabricator task about it:
>> https://phabricator.wikimedia.org/T299351
>>
>> If you have an opinion, weigh in there or here.
>>
>> Thanks!
>>
>> --
>> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
>> http://aharoni.wordpress.com
>> ‪“We're living in pieces,
>> I want to live in peace.” – T. Moore‬
>>
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/JFRQXYH7QPC3UE4K7G7APCVPPD64JP6M/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/UOM2ATKL34E5FCER4FY32TTPVIIYMSBW/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Collection / Special:Book usage

2022-04-16 Thread Amir E. Aharoni
Hi,

As far as I can see, the Collection extension, which provides the
Special:Book page, is deployed on nearly all Wikimedia wikis.

Is there data that shows how often do people actually use it?

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/5JWSKWYE5M44OZR5MLLXFQEZXLQYOO72/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Open proxies and IP blocking

2022-04-22 Thread Amir E. Aharoni
All of these suggestions sound good.

Reducing the current intimidating wall of text should be very high on the
priority list.

Another thing I'd suggest experimenting with is reducing the use of
preemptive IP blocks, simply because an IP was identified as a potentially
problematic proxy, and blocking them only if they actually vandalize.

בתאריך יום ו׳, 22 באפר׳ 2022, 15:44, מאת Florence Devouard ‏<
fdevou...@gmail.com>:

> I have read all the comments and discussed privately with a few people.
>
> There are some elements of answers that are purely in the hands of
> stewards, they have to discuss and find common grounds, in particular to
> implementing blocks, so that they limit damage on good people, whilst
> preserving the projects from vandals.
>
> However, the general observation is that the current system to report an
> unfair block to stewards and get unblocked by them is largely broken.
> 1) process is not simple to understand by the user
> 2) complicated to implement on the steward side (requires back and forth
> discussion, checking legitimacy of request, copy pasting information etc.)
> 3) the steward pool of volunteers is limited, whilst the stewards willing
> to do that job is even smaller (I heard the VRT queue is overflowing)
> 4) the process reveals IP private info
> All this creates a bottleneck.
>
> There is one path we could explore, a feature to simplify the process of
> "adding legitimate users" to the Global IPblock exemptions list, in a
> process inspired from the Global renamers one.
> * new functionary role (eg Global IPblock exempters) : populated by
> stewards, or people appointed by steward
> * interface directly on wiki (bypass of VRT, bypass of copy pasting
> between tools)
> * a process which would NOT require revealing the IP address to the
> functionary (it is sufficient that the system recognise the person is
> blocked in relationship with an Open Proxy/TOR stuff)
> * a process which could provide info to the functionary to very quickly
> assess whether the person is a legitimate editor or not (every person
> fighting vandalism know how to do that... display last contribs... block
> log... number of edits... etc. or simply direct links to those info to
> simplify the functionary job)
> * a process allowing various "unblocking" options, day, weeks, indef
> listing, pretty much as the blocking feature permit, so as to grant indef
> listing to the super trustworthy individuals, and a time limited listing to
> those more questionnable
> * add a checkbox system where requesters can give pre-loaded reasons for
> their asking (edit-a-thons etc.), which will help make the system
> multilingual and language neutral for the functionary (in most cases, no
> need to discuss with the user)
> * add any feature necessary to limit the risk of vandals abusing the
> feature (forced loging before submitting the request, capcha stuff)
>
> In short, simply make the "add to the Global IP block exemption list"
> process fluid with removal of the current bottle neck (stewards), which in
> turn will be able to focus on more important security issues.
>
>
> Is there any reasons why this would technically and socially not work ?
>
> Flo
>
>
> Le 22/04/2022 à 13:25, Rae Adimer via Wikimedia-l a écrit :
>
> Hi all,
>
> About unblocking IPs that geolocate to Africa, it’s not as though the
> blocked IPs are random. The problem with these affected ISPs are that they
> have many users on the same IP address. They aren’t traditional proxies
> (and traditional proxies will not be unblocked, that isn’t the issue here),
> they’re just poorly managed ISPs. I’m not even sure if there would be more
> vandalism from unblocking these ISPs, and I think it should be done.
>
> “Smart blocking” would be a bad idea. It would take *a lot* of work to
> implement and would be a net harm to our ability to deal with abuse. I am
> strongly opposed to creating this. Also remember to a large extent the
> issue with these IPs isn’t a range, it’s that there’s multiple users on the
> *same* IP.
>
> Regarding IPBE, the issue isn’t that we’re declining requests, it’s that
> we don’t get to them in a timely manner. There are a lot of requests.
>
> I’ve tried to clear up a number of other misconceptions in a comment on
> the Meta-Wiki page as well.
>
> Best regards,
> Rae
>
> On Fri, Apr 22, 2022 at 07:03 WereSpielChequers <
> werespielchequ...@gmail.com> wrote:
>
>> Yesterday I was on a conference call that included several Nigerian
>> Wikipedians, I was surprised at how much of their problems editing
>> Wikipedia were over blocks.
>>
>> The English language Wikipedia doesn't have an overall problem with
>> editing numbers, nearly eight years on, editing volumes are still clearly
>> above the 2014 minima. But we do have huge geographic skews and in
>> particular we badly underrepresent the English speaking parts of Africa in
>> our community and in our Projects. I don't know if other languages have
>> similar issues, but it would 

[Wikimedia-l] Re: Open proxies and IP blocking

2022-04-20 Thread Amir E. Aharoni
I don't have a solution, but I just wanted to confirm that I agree fully
with the description of the problem. I hear that this happens to people
from Nigeria, Ghana, Kenya and some other countries almost every day.

The first time I heard about it was actually around 2018 or so, but during
the last year it has become unbearably frequent.

A smarter solution is needed. I tried talking to stewards about this
several times, and they always say something like "we know that this
affects certain countries badly, and we know that the technology has
changed since the mid-2000s, but we absolutely cannot allow open proxies
because it would immediately unleash horrible vandalism on all the wikis".
I'm sure they mean well, but this is not sustainable.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬


‫בתאריך יום ד׳, 20 באפר׳ 2022 ב-21:21 מאת ‪Florence Devouard‬‏ <‪
fdevou...@gmail.com‬‏>:‬

> Hello friends
>
> Short version : We need to find solutions to avoid so many africans being
> globally IP blocked due to our No Open Proxies policy.
> *https://meta.wikimedia.org/wiki/No_open_proxies/Unfair_blocking
> *
>
>
> Long version :
>
> I'd like to raise attention on an issue, which has been getting worse in
> the past couple of weeks/months.
>
> Increasing number of editors getting blocked due to the No Open Proxies
> policy [1]
> In particular africans.
>
> In February 2004, the decision was made to block open proxies on Meta and
> all other Wikimedia projects.
>
> According to the no open proxies policy : Publicly available proxies
> (including paid proxies) may be blocked for any period at any time. While
> this may affect legitimate users, they are not the intended targets and may
> freely use proxies until those are blocked [...]
>
> Non-static IP addresses or hosts that are otherwise not permanent proxies
> should typically be blocked for a shorter period of time, as it is likely
> the IP address will eventually be transferred or dynamically reassigned, or
> the open proxy closed. Once closed, the IP address should be unblocked.
>
> According to the policy page, « the Editors can be permitted to edit by
> way of an open proxy with the IP block exempt flag. This is granted on
> local projects by administrators and globally by stewards. »
>
>
> I repeat -> ... legitimate users... may freely use proxies until those
> are blocked. the Editors can be permitted to edit by way of an open proxy
> with the IP block exempt flag <-- it is not illegal to edit using an
> open proxy
>
>
> Most editors though... have no idea whatsoever what an open proxy is. They
> do not understand well what to do when they are blocked.
>
> In the past few weeks, the number of African editors reporting being
> blocked due to open proxy has been VERY significantly increasing.
> New editors just as old timers.
> Unexperienced editors but also staff members, president of usergroups,
> organizers of edit-a-thons and various wikimedia initiatives.
> At home, but also during events organized with usergroup members or
> trainees, during edit-a-thons, photo uploads sessions etc.
>
> It is NOT the occasional highly unlikely situation. This has become a
> regular occurence.
> There are cases and complains every week. Not one complaint per week.
> Several complaints per week.
> *This is irritating. This is offending. This is stressful. This is
> disrupting activities organized in good faith by good people, activities
> set-up with our donors funds. **And the disruption** is primarlly taking
> place in a geographical region supposingly to be nurtured (per our strategy
> for diversity, equity, inclusion blahblahblah). *
>
>
> The open proxy policy page suggests that, should a person be unfairly
> blocked, it is recommended
>
>- * to privately email stewards[image: (_AT_)]wikimedia.org.
>- * or alternatively, to post a request (if able to edit, if the
>editor doesn't mind sharing their IP for global blocks or their reasons to
>desire privacy (for Tor usage)).
>- * the current message displayed to the blocked editor also suggest
>contacting User:Tks4Fish. This editor is involved in vandalism fighting and
>is probably the user blocking open proxies IPs the most. See log
>
>
> So...
> Option 1: contacting stewards : it seems that they are not answering. Or
> not quickly. Or requesting lengthy justifications before adding people to
> IP block exemption list.
> Option 2: posting a request for unblock on meta. For those who want to
> look at the process, I suggest looking at it [3] and think hard about how a
> new editor would feel. This is simply incredibly complicated
> Option 3 : user:TksFish answers... sometimes...
>
> As a consequence, most editors concerned with those global blocks... stay
> blocked several days.
>
> We do not know know why the situation has 

[Wikimedia-l] Re: Open proxies and IP blocking

2022-04-21 Thread Amir E. Aharoni
It should usually be global. These days, people often need to edit a
Wikipedia or a Wikisource or some other wiki in their language, and maybe
in another language, and Wikidata, and Commons, and sometimes more wikis.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬


‫בתאריך יום ה׳, 21 באפר׳ 2022 ב-15:03 מאת ‪Mario Gómez‬‏ <‪
mariogomw...@gmail.com‬‏>:‬

>
> On Thu, Apr 21, 2022 at 11:32 AM Lane Chance  wrote:
>
>> A 'liberalization' of IPBE can easily be enabled by allowing WMF
>> funded projects to add this group to any participants that request it
>
>
> I think it makes sense to quickly grant temporary (e.g. 6 months) GIPBE +
> IPBE to every participant in an editathon. I thought this was already
> happening to some degree?
>
> Best,
>
> Mario
>
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/4NJV4LNPBHDTXZ2CR4ILBAEB7MY5UKS3/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/AUVDR4LY3UHUOZKA3BRK4MNNLFQ2EXNI/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Collection / Special:Book usage

2022-04-17 Thread Amir E. Aharoni
> On Sun, Apr 17, 2022, 09:29 Strainu  wrote:
> >
> > The correct question is: does it still do anything of value?
> ‫בתאריך יום א׳, 17 באפר׳ 2022 ב-10:42 מאת ‪Jan Ainali‬‏ <‪
ainali@gmail.com‬‏>:‬
>
> Even with all output options broken it is still a decent user interface
for creating and organizing collections of articles.

This may well be true, but I'm wondering how much is it *actually* used. I
know I never use it, but it's possible that thousand of other people do. If
it's true, then everything is fine. I can't find a log of its usage, or a
statistics page that shows how often do people use this feature.

It currently appears in at least two prominent places:
1. "Create a book" link in the desktop sidebar (in some wikis; I don't see
it in the English Wikipedia, but I do see it in Swedish and Basque).
2. "Extensions used by Wikimedia - Main" group in translatewiki.net, which
means that volunteer localizers are asked to translate it with (relatively)
high priority.

If only, say, five people use it in the whole Wikimedia universe, then
perhaps someone should consider downgrading its prominence or maybe
removing it entirely.

On translatewiki, I can move it from "Extensions used by Wikimedia - Main"
to "Extensions used by Wikimedia - Advanced" or even to "Extensions used by
Wikimedia - Legacy", but again, before I do this, I'd like to make sure
that it's not actually used by a lot of people.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/25WM4YSWVURKNCW2DI7ZFE3JA42T2RYR/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

<    1   2   3