[Wikimedia-l] Community Conversations - Human Rights Policy

[Franziska Putz]

Dear Wikimedians,

The Global Advocacy team is looking for your input. We last contacted you about
the launch of the Human Rights Policy. Now, we're asking you to help us
understand how it can best support Wikimedians in practice.


We are hosting a series of community conversations in May. There are 4
regional sessions. Each will be 60 minutes, hosted on zoom, and include
translation support. On this Meta page

you can see the schedule for each call and access the link to register.

What is the outcome of these sessions? Our goal is to learn how community
members' human rights have been challenged and how the Foundation can
better support individuals and prevent such situations. We will do two
things with the information that is shared via these conversations. (1) We
will share a summary of our findings by publishing them on Meta, in a Diff
blog, and (hopefully!) presenting them at Wikimania. (2) Feedback and
recommendations will shape the implementation process of the Human Rights
Policy.


Where can you learn more about these calls and the Human Rights Policy? You
can learn more about the conversion format, types of questions that will
guide the conversation, as well as the Human Rights Policy on this meta page

.


What if you can’t join any of these conversations? If you are interested
but cannot attend the calls you can still share your experiences via a
survey that will soon be available.


We hope to see you there,


Ziski from the GA Team

Franziska Putz (she/her)

Movement Advocacy Community Manager, Global Advocacy

Wikimedia Foundation

fp...@wikimedia.org

*UCT timezone
___
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/AVDDFXP74JSBW64JECXMTU5IVYGMSAQU/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Vi to]

IPBE for autoconfirmed is a local matter, it would imply that any block
(TOR included) will, in practice, almost turn into anon-only.

Expiration is an option, as for any global group.

Vito

Il giorno gio 21 apr 2022 alle ore 19:51 Nathan  ha
scritto:

> How significant is the risk in just granting autoconfirmed (or similar)
> users IPBE by default? Why does IPBE expire anyway?
>
> On Thu, Apr 21, 2022 at 10:50 AM DerHexer via Wikimedia-l <
> wikimedia-l@lists.wikimedia.org> wrote:
>
>> Hi,
>>
>> Thanks for raising the topic. Being a steward for 14+ years, I've
>> followed closely the evolution of that problem.
>>
>> “When I noticed that range blocks caused more harm than good (countless
>> mails to stewards), I started to reduce the length of any such block (if
>> necessary at all; I check every single range intensively if a block would
>> case more harm than good). The situation with OPs is a bit different
>> because they obfuscate the original IP address which is pretty often needed
>> by checkusers and stewards to stop harm against the projects. For that
>> reason, I agree that we cannot give up on OP blocking. The only way to get
>> out of these problems are (much!) easier reporting ways, more people who
>> can give out exceptions (locally and globally) and check outdated OPs and
>> IPBEs. Maybe it would also make sense to give long-term users an option to
>> self-assign an IPBE (e.g.) once per week for x hours for such cases like
>> edit-a-thons. Most of their IP addresses used would still be reported (in
>> order to prevent abuse) but most problems for that one moment would be
>> solved (and users could look for long-term solutions).”
>>
>> Why the quotation marks? Because I've posted that very same message to
>> the metawiki page
>> 
>>  and
>> understand it as one step towards a solution. In my opinion, it makes way
>> more sense to talk publicly about the issue and possible solutions than
>> losing good ideas (and there have been some already in this thread!) in the
>> wide world of this mailing list. Let's have that conversation onwiki—and I
>> also encourage the WMF tech departments to join in that conversation.
>> Because we as stewards have reported our problems with the current
>> situation multiple times, sought for technical solutions (e.g., better
>> reporting tools), indeed did get a better rapport with the WMF teams but
>> still are not where we need to be in order to serve both interests
>> (openness and protection). Unsurprisingly, also stewards are individuals
>> with different opinions and (possible) solutions to that one problem. As
>> Vito said, we will once again discuss it and will share our thoughts and
>> solutions.
>>
>> Best,
>> DerHexer (Martin)
>>
>> Am Mittwoch, 20. April 2022, 20:19:48 MESZ hat Florence Devouard <
>> fdevou...@gmail.com> Folgendes geschrieben:
>>
>>
>> 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.
>> 

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

[Nathan]

How significant is the risk in just granting autoconfirmed (or similar)
users IPBE by default? Why does IPBE expire anyway?

On Thu, Apr 21, 2022 at 10:50 AM DerHexer via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> Hi,
>
> Thanks for raising the topic. Being a steward for 14+ years, I've followed
> closely the evolution of that problem.
>
> “When I noticed that range blocks caused more harm than good (countless
> mails to stewards), I started to reduce the length of any such block (if
> necessary at all; I check every single range intensively if a block would
> case more harm than good). The situation with OPs is a bit different
> because they obfuscate the original IP address which is pretty often needed
> by checkusers and stewards to stop harm against the projects. For that
> reason, I agree that we cannot give up on OP blocking. The only way to get
> out of these problems are (much!) easier reporting ways, more people who
> can give out exceptions (locally and globally) and check outdated OPs and
> IPBEs. Maybe it would also make sense to give long-term users an option to
> self-assign an IPBE (e.g.) once per week for x hours for such cases like
> edit-a-thons. Most of their IP addresses used would still be reported (in
> order to prevent abuse) but most problems for that one moment would be
> solved (and users could look for long-term solutions).”
>
> Why the quotation marks? Because I've posted that very same message to the 
> metawiki
> page
> 
>  and
> understand it as one step towards a solution. In my opinion, it makes way
> more sense to talk publicly about the issue and possible solutions than
> losing good ideas (and there have been some already in this thread!) in the
> wide world of this mailing list. Let's have that conversation onwiki—and I
> also encourage the WMF tech departments to join in that conversation.
> Because we as stewards have reported our problems with the current
> situation multiple times, sought for technical solutions (e.g., better
> reporting tools), indeed did get a better rapport with the WMF teams but
> still are not where we need to be in order to serve both interests
> (openness and protection). Unsurprisingly, also stewards are individuals
> with different opinions and (possible) solutions to that one problem. As
> Vito said, we will once again discuss it and will share our thoughts and
> solutions.
>
> Best,
> DerHexer (Martin)
>
> Am Mittwoch, 20. April 2022, 20:19:48 MESZ hat Florence Devouard <
> fdevou...@gmail.com> Folgendes geschrieben:
>
>
> 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 

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

[Samuel Klein]

Good point Martin :)  I will continue the discussion there.  But one more
note as I do:

I think 'blocking' as a concept is now the wrong solution in 100% of
cases.  Once it made sense as a stopgap.  But now we have machine models
that can effectively help classify contributions based on their content
rather than their metadata -- so it is always preferable to see what people
are trying to post before deciding how to handle it.  We also edit in a
society, and can easily allow people to approve one another or ping one
another to join our implicit web of trust.

As a bonus, doing this provides a smooth + uniform experience for editors +
editing tools (even if the way their edit is applied changes w/ context),
rather than giving different messages / interfaces based on how suspicious
their ambient network environment is.

On Thu, Apr 21, 2022 at 10:50 AM DerHexer via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> Hi,
>
> Thanks for raising the topic. Being a steward for 14+ years, I've followed
> closely the evolution of that problem.
>
> “When I noticed that range blocks caused more harm than good (countless
> mails to stewards), I started to reduce the length of any such block (if
> necessary at all; I check every single range intensively if a block would
> case more harm than good). The situation with OPs is a bit different
> because they obfuscate the original IP address which is pretty often needed
> by checkusers and stewards to stop harm against the projects. For that
> reason, I agree that we cannot give up on OP blocking. The only way to get
> out of these problems are (much!) easier reporting ways, more people who
> can give out exceptions (locally and globally) and check outdated OPs and
> IPBEs. Maybe it would also make sense to give long-term users an option to
> self-assign an IPBE (e.g.) once per week for x hours for such cases like
> edit-a-thons. Most of their IP addresses used would still be reported (in
> order to prevent abuse) but most problems for that one moment would be
> solved (and users could look for long-term solutions).”
>
> Why the quotation marks? Because I've posted that very same message to the 
> metawiki
> page
> 
>  and
> understand it as one step towards a solution. In my opinion, it makes way
> more sense to talk publicly about the issue and possible solutions than
> losing good ideas (and there have been some already in this thread!) in the
> wide world of this mailing list. Let's have that conversation onwiki—and I
> also encourage the WMF tech departments to join in that conversation.
> Because we as stewards have reported our problems with the current
> situation multiple times, sought for technical solutions (e.g., better
> reporting tools), indeed did get a better rapport with the WMF teams but
> still are not where we need to be in order to serve both interests
> (openness and protection). Unsurprisingly, also stewards are individuals
> with different opinions and (possible) solutions to that one problem. As
> Vito said, we will once again discuss it and will share our thoughts and
> solutions.
>
> Best,
> DerHexer (Martin)
>
> Am Mittwoch, 20. April 2022, 20:19:48 MESZ hat Florence Devouard <
> fdevou...@gmail.com> Folgendes geschrieben:
>
>
> 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 

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

[DerHexer via Wikimedia-l]

 Hi,

Thanks for raising the topic. Being a steward for 14+ years, I've followed 
closely the evolution of that problem.

“When I noticed that range blocks caused more harm than good (countless mails 
to stewards), I started to reduce the length of any such block (if necessary at 
all; I check every single range intensively if a block would case more harm 
than good). The situation with OPs is a bit different because they obfuscate 
the original IP address which is pretty often needed by checkusers and stewards 
to stop harm against the projects. For that reason, I agree that we cannot give 
up on OP blocking. The only way to get out of these problems are (much!) easier 
reporting ways, more people who can give out exceptions (locally and globally) 
and check outdated OPs and IPBEs. Maybe it would also make sense to give 
long-term users an option to self-assign an IPBE (e.g.) once per week for x 
hours for such cases like edit-a-thons. Most of their IP addresses used would 
still be reported (in order to prevent abuse) but most problems for that one 
moment would be solved (and users could look for long-term solutions).”
Why the quotation marks? Because I've posted that very same message to the 
metawiki page and understand it as one step towards a solution. In my opinion, 
it makes way more sense to talk publicly about the issue and possible solutions 
than losing good ideas (and there have been some already in this thread!) in 
the wide world of this mailing list. Let's have that conversation onwiki—and I 
also encourage the WMF tech departments to join in that conversation. Because 
we as stewards have reported our problems with the current situation multiple 
times, sought for technical solutions (e.g., better reporting tools), indeed 
did get a better rapport with the WMF teams but still are not where we need to 
be in order to serve both interests (openness and protection). Unsurprisingly, 
also stewards are individuals with different opinions and (possible) solutions 
to that one problem. As Vito said, we will once again discuss it and will share 
our thoughts and solutions.
Best,DerHexer (Martin)
Am Mittwoch, 20. April 2022, 20:19:48 MESZ hat Florence Devouard 
 Folgendes geschrieben:  
 
   
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 

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

[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: Open proxies and IP blocking

[Mario Gómez]

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] Re: Open proxies and IP blocking

[Mario Gómez]

On Thu, Apr 21, 2022 at 12:32 PM K. Peachey  wrote:

>
> Is there any reason we are creating multiple blocks, which is causing
> multiple rows created in the backend?
>

I'm not aware of the number of rows in the backend being currently a
problem here. There's a few logistic reasons to do it this way. If stress
on the backend becomes a problem, I'm sure we can figure out a solution.

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/R7L4SWTPWMNTX4YD5KCNK66G3HHIUGMS/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[K. Peachey]

On Thu, 21 Apr 2022 at 07:42, Mario Gómez  wrote:
> …
> These blocks from English Wikipedia are now also imported to Spanish 
> Wikipedia, as well as global blocks (the ones by Tks4Fish). The blocking 
> system has received some tuning over time to decrease the number of affected 
> users, but it's clear that it's not enough, in particular for some countries 
> like Ghana or Benin. So we need further tuning, or rethink how/when we apply 
> the blocks.
> …
> Best,
>
> Mario

Is there any reason we are creating multiple blocks, which is causing
multiple rows created in the backend?

Surely it would be simpler to manage by just just directly as a global
block in the first place?
___
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/IH4SDFJ3P6MCQ5XMZPMWNLFSC2DZ5WVS/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Galder Gonzalez Larrañaga]

There are lot of ways a PDF collection may be used. Most of the languages in the world don't have textbooks. Providing them is strategic and part of our vision. Downloading a bunch of articles from wikivoyage and making a travel guide is another one. Showing the articles made by a group of students to the school director so they appreciate the length of the work is another one. Building collections for readers who can't access a computer or Internet is another one... As said, this is something ot was made and now is broken, not a new feature.2022(e)ko api. 21(a) 11:45 erabiltzaileak hau idatzi du (Gergő Tisza ):On Wed, Apr 20, 2022 at 11:14 PM Galder Gonzalez Larrañaga  wrote:We may differ in what was first: abandoning it or closing it, but the process is available at phabricator.What was first was regular production incidents caused by OCG, which would have required a rewrite (and to some extent rearchitecting) to operate smoothly. That would have been a major project, plus the service had a constant maintenance cost (it was a node.js service, and node is relatively maintenance-heavy), and the WMF did not want to maintain two different renderers forever. We migh also have a different view on priorities, but a Foundation with 100 million dollars in a vault can pay for someone to solve this issue, no doubts.Yes, or the money (probably a quarter-year work for a team, at least, so that might be something like $300K?) can be used on something else. There are a huge number of things to spend money on, and IMO it's hard to argue for the strategic importance of PDF book rendering. It wasn't used much, it would have been work-intensive to maintain  (every new wikitext feature would have required special handling for the LaTeX transformation, and there are all kinds of wikitext/HTML constructs which are not easy to express in LaTeX), and there isn't much value in a PDF of Wikipedia articles when the originals are freely available over the internet (and for people with difficulties accessing the internet, there are better alternatives).(Personally, I don't think Proton was worth the investment, either - it doesn't give much value beyond the PDF generation that most browsers are already capable of doing.) By the way: the Proton PDF render is also failing if the article has a gallery. But no one cares about it. It used to work, it was broken, and no one was responsible for the fail.I assume that refers to T209837?The drawback of Proton is that since it uses a headless browser for PDF rendering, there isn't much room to influence how the rendering goes (beyond CSS tweaks or upstream bug reports), so issues like that might not be easily fixed. (OTOH it at least displays galleries, which OCG didn't.)
___
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/HNS3VQZPDPPIDINXPRU3O5JKGIL4QYUS/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Gergő Tisza]

On Wed, Apr 20, 2022 at 11:14 PM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> We may differ in what was first: abandoning it or closing it, but the
> process is available at phabricator.
>

What was first was regular production incidents caused by OCG, which would
have required a rewrite (and to some extent rearchitecting) to operate
smoothly. That would have been a major project, plus the service had a
constant maintenance cost (it was a node.js service, and node is relatively
maintenance-heavy), and the WMF did not want to maintain two different
renderers forever.


> We migh also have a different view on priorities, but a Foundation with
> 100 million dollars in a vault can pay for someone to solve this issue, no
> doubts.
>

Yes, or the money (probably a quarter-year work for a team, at least, so
that might be something like $300K?) can be used on something else. There
are a huge number of things to spend money on, and IMO it's hard to argue
for the strategic importance of PDF book rendering. It wasn't used much, it
would have been work-intensive to maintain  (every new wikitext feature
would have required special handling for the LaTeX transformation, and
there are all kinds of wikitext/HTML constructs which are not easy to
express in LaTeX), and there isn't much value in a PDF of Wikipedia
articles when the originals are freely available over the internet (and for
people with difficulties accessing the internet, there are better
alternatives).
(Personally, I don't think Proton was worth the investment, either - it
doesn't give much value beyond the PDF generation that most browsers are
already capable of doing.)


> By the way: the Proton PDF render is also failing if the article has a
> gallery. But no one cares about it. It used to work, it was broken, and no
> one was responsible for the fail.
>

I assume that refers to T209837 ?
The drawback of Proton is that since it uses a headless browser for PDF
rendering, there isn't much room to influence how the rendering goes
(beyond CSS tweaks or upstream bug reports), so issues like that might not
be easily fixed. (OTOH it at least displays galleries, which OCG didn't
.)
___
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/ND6JQGJDURC7H5MP2HBVRGN2DC2URHJQ/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Lane Chance]

A 'liberalization' of IPBE can easily be enabled by allowing WMF
funded projects to add this group to any participants that request it,
or even all participants in some editathons given the benefits of
editing from shared wifi or through a proxy in some countries where
editing Wikipedia may have personal risks.

Editathons in national museums or universities are often hampered, and
new joiners have significant amounts of time wasted when they find out
their edits made in a library of a cafe get rejected and they can
forget editing that day, or told to wait for a month or indefinitely
for a global steward to consider their request. The risks are almost
zero that someone actively contributing to a funded content creation
project would be a vandal. Even if this ever happened, their account
would be sanctioned without it becoming a stewards problem. Keep in
mind that stopping editing from internet cafes or libraries
disproportionately harms poorer people and those editing from
countries without the best technical infrastructure who otherwise have
to try to edit from a mobile phone and may end up paying to edit
rather than using the public free access.

The current system works against the stated values of the community
and causes unnecessary harm. Let's just get on with making adding
newbies to IPBE a normal part of good faith editing, and stop global
stewards and mass IP blocks, being a serious and unnecessary barrier
to good faith editors.

Lane

On Thu, 21 Apr 2022 at 10:04, Željko Blaće  wrote:
>
> My 2 cents in this telegraph short email
>
> #1 it is a common situation in Bosnia and Croatia, likely in 
> other CEE countries of CEE where providers are 'cheap' with IP addresses. I 
> know an amazingly constructive and dedicated, but not proactive editor who 
> failed to get unblocked on EN, as he could not explain as a novice to EN 
> admins in 2015 that he was not a sock puppet . Loss is on our side.
>
> #2 This is a complex (and for outreach mission critical) problem that 
> requires real-time addressing and most likely a dedicated paid professionals 
> (better 4 x 50% across time zones) to take the burden off from voluntary 
> stewards and admins, but also to inform and educate those who could not 
> follow what are common network issues across different regions.
>
> Best, Z.
>
>
> ___
> 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/IOIXYDEWHOJXGSDPLSPM27NRR75M7YQL/
> 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/BUWW7XKVGAFXMJOK5VMMZCXL7W3U3SZI/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Željko Blaće]

My 2 cents in this telegraph short email

#1 it is a common situation in Bosnia and Croatia, likely in
other CEE countries of CEE where providers are 'cheap' with IP addresses. I
know an amazingly constructive and dedicated, but not proactive editor who
failed to get unblocked on EN, as he could not explain as a novice to EN
admins in 2015 that he was not a sock puppet . Loss is on our side.

#2 This is a complex (and for outreach mission critical) problem that
requires real-time addressing and most likely a dedicated paid
professionals (better 4 x 50% across time zones) to take the burden off
from voluntary stewards and admins, but also to inform and educate those
who could not follow what are common network issues across different
regions.

Best, Z.
___
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/IOIXYDEWHOJXGSDPLSPM27NRR75M7YQL/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Mario Gómez]

On Thu, Apr 21, 2022 at 12:53 AM Samuel Klein  wrote:

>
> +++.  We are raising these barriers to [apparently] try to stave off
> vandalism and spam.  But hard security like this can put an end to the
> projects, for good.  There is no more definitive end than one that seems
> mandated from within.  We need better automation, MLl models, sandboxing,
> and triage to help us *increase* the number of people who can edit, and
> can propose edits to protected pages, while decreasing the amount of
> vandalism and spam that is visible to the world.
>

For the P2P proxy blocks, vandalism was a factor (AFAIK spam wasn't), but I
think the strongest trigger was the amount of harassment, death threats or
other physical harm threats, and doxxing attempts coming out from this
particular proxy service.

I agree that we should increase the number of people who can edit. But we
should also maintain a reasonably safe space for contributors. There are
trade-offs that need to tune at every corner.

For this kind of abuse, we have a toolbox:
- IP blocking
- Page protections
- Edit filters
- Bots and other post-edit analysis tools
- Manual patrolling (assisted with various tools) + reporting to
admins/oversighters/stewards.

Each of them has its own caveats, we should improve them all, and find some
balance in the usage of each tool. IMHO, complete removal of any of these
tools will be harmful to our projects and contributors.

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/PUL24LJ5LYQKXXEMCT5OOKCMLFOICMJX/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org