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

[Samuel Klein]

How lovely.  Thank you Dirk for your work on this.
I was just today talking with a friend about how one might customize a
beautiful wikibook and potentially give it its own permanent ID and, say,
contribute it to the Open Library.

On Sat, Apr 23, 2022 at 10:14 AM Dirk Hünniger via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> Hi Juergen,
>
> the mediawiki2latex tool is still used see
> https://qa.debian.org/popcon.php?package=mediawiki2latex
>
> it can handle complex tables. It is fully open source, distributed as a
> debian package, which can run on an OS as a docker container. Currently
> I am only investing little time to keep it working. Still I could do
> more if demand rises in the furtuer
>
> Yours Dirk
>
> On 22.04.22 22:19, Juergen Fenn wrote:
> > Dear Erik,
> > Dear list,
> >
> > Am 22.04.22 um 21:35 Uhr schrieb Erik Moeller:
> >> That specific book is a good example of the problems that we've always
> >> had with PDF generation by way of LaTeX, such as complex tables. Also
> >> note the intermittent appearance of unsupported tags in the output.
> >>
> >> As far as I know, the renderer they use is still partially
> >> proprietary. I'm not sure if it would still be seen as valuable to
> >> open source fully, given that LaTeX is indeed probably a technical
> >> dead-end for these kinds of conversions, and given that the codebase
> >> is very old.
> >
> > You might like to know that there is a more recent free
> > MediaWiki-to-LaTeX project that is actively maintained by Dirk Hünninger
> > and can be tried out on WMF Labs:
> >
> > https://mediawiki2latex.wmflabs.org/
> >
> > I understand that Dirk produced some PDF versions for German Wikibooks,
> > but I do not know whether he is still contributing.
> >
> > I put Dirk in CC to let him know we speak of matters LaTeX. Maybe he
> > would like to join the conversation.
> >
> > Best regards,
> > Jürgen.
> ___
> 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/D7BW7B6NWQPW5SHESADJVCI3AXX2YYBQ/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org



-- 
Samuel Klein  @metasj   w:user:sj  +1 617 529 4266
___
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/J3ISWKGVI2FTT6WQXYZEC4CGBQKR4COI/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Wikimedia Foundation Board of Trustees 2022 election - updates

[Todd Allen]

Yes, and let me say it in stronger terms: This is unacceptable.
Community-selected seats have nothing to do with affiliates; affiliates are
absolutely not the community. Community-selected seats must be an at-large
election from Wikimedia editors from any candidate who cares to run, not
taken from a "short list" of affiliate-approved candidates.

Affiliate seats are NOT community seats.

Regards,

Todd Allen

On Sat, Apr 23, 2022 at 4:32 PM Andreas Kolbe  wrote:

> Chris,
>
> There is no longer any distinction between community and affiliate
> trustees. For reference, see the "Type of seat" column in the current board
> member table on Meta, as well as the footnote under the table.[1]
>
> What Dariusz has announced here is a new process for determining
> "community-and-affiliate trustees". This new process is being "*implemented
> on a trial basis for the 2022 election*".
>
> Andreas
>
> [1]
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard/April_2022_-_Board_seats_in_2022_and_2023
>
> On Sat, Apr 23, 2022 at 9:19 PM Chris Keating 
> wrote:
>
>>
>>
>> On Sat, Apr 23, 2022 at 1:32 PM Andreas Kolbe  wrote:
>>
>>> Dear Dariusz,
>>>
>>> I am surprised your post has not attracted more attention. It's probably
>>> because you did not spell out what the adopted recommendation involves. It
>>> says (my emphases):[1]
>>>
>>>
>>> *The Board of Trustees wants to improve the set of skills and the
>>> diversity contributed by newly selected trustees. For this reason, the
>>> Board has approved a new process to select two community-and-affiliate
>>> trustees this year. The objective is to have two trustees confirmed by
>>> October 1st. Affiliates will vote to pre-select 6 candidates. A community
>>> vote will decide who from these 6 candidates will be recommended for the
>>> two seats.*
>>>
>>> This is a fundamental change to the WMF board election process. Many
>>> people will feel that this further disenfranchises the volunteer community.
>>>
>>
>> The effect of this is that the two seats which were in the past solely
>> elected by the Wikimedia Affiliates will now be elected through this
>> combined model where the affiliates shortlist 6 candidates and the
>> community elects two of them.
>>
>> That is, to my mind, enfranchising the volunteer community to a greater
>> extent.
>> ___
>> 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/X23XT2PEFSQKN2WPJZOEY64EMC27GZSH/
>> 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/SCRZ2KNGMCOW7NXN6FA5WF66LCXNO5MP/
> 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/HDQZPM6TG37M5RXTZZ4GEGEGC7RSMBAS/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Wikimedia Foundation Board of Trustees 2022 election - updates

[Andreas Kolbe]

Chris,

There is no longer any distinction between community and affiliate
trustees. For reference, see the "Type of seat" column in the current board
member table on Meta, as well as the footnote under the table.[1]

What Dariusz has announced here is a new process for determining
"community-and-affiliate trustees". This new process is being "*implemented
on a trial basis for the 2022 election*".

Andreas

[1]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard/April_2022_-_Board_seats_in_2022_and_2023

On Sat, Apr 23, 2022 at 9:19 PM Chris Keating 
wrote:

>
>
> On Sat, Apr 23, 2022 at 1:32 PM Andreas Kolbe  wrote:
>
>> Dear Dariusz,
>>
>> I am surprised your post has not attracted more attention. It's probably
>> because you did not spell out what the adopted recommendation involves. It
>> says (my emphases):[1]
>>
>>
>> *The Board of Trustees wants to improve the set of skills and the
>> diversity contributed by newly selected trustees. For this reason, the
>> Board has approved a new process to select two community-and-affiliate
>> trustees this year. The objective is to have two trustees confirmed by
>> October 1st. Affiliates will vote to pre-select 6 candidates. A community
>> vote will decide who from these 6 candidates will be recommended for the
>> two seats.*
>>
>> This is a fundamental change to the WMF board election process. Many
>> people will feel that this further disenfranchises the volunteer community.
>>
>
> The effect of this is that the two seats which were in the past solely
> elected by the Wikimedia Affiliates will now be elected through this
> combined model where the affiliates shortlist 6 candidates and the
> community elects two of them.
>
> That is, to my mind, enfranchising the volunteer community to a greater
> extent.
> ___
> 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/X23XT2PEFSQKN2WPJZOEY64EMC27GZSH/
> 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/SCRZ2KNGMCOW7NXN6FA5WF66LCXNO5MP/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Vi to]

"lack of infrastructure" and lack of "current volunteers" weren't addressed
in your email at all, given that you're relying upon wrong premises by
assuming checkusers' bad faith and non-existing practices.

Vito

Il giorno sab 23 apr 2022 alle ore 19:58 Lane Chance 
ha scritto:

>
> On Sat, 23 Apr 2022 at 15:17, Rae Adimer via Wikimedia-l <
> wikimedia-l@lists.wikimedia.org> wrote:
>
>> Hi Lane,
>>
>> I would appreciate if you could take the time to learn about an issue
>> before holding strong, accusatory opinions about it.
>>
>
> Maybe reading the facts in my email would be a good starting point. Your
> response has not refuted any of those facts, in fact as a checkuser you no
> doubt could confirm exactly how many times in the past checkuser tools have
> been misused and how they are still open to being misused.
>
>
>> gIPBE is granted to people in China and other areas where they want to
>> use proxies for security reasons. A significant portion of current gIPBEs
>> are for people in China. The issue here is not people being declined gIPBE,
>> it’s the sheer amount of people who need it and the lack of infrastructure
>> for current volunteers to handle those requests.
>>
>
>  Declining was not mentioned and is not the issue. Alternatives for "lack
> of infrastructure" and lack of "current volunteers" was addressed in my
> email. Lacking volunteers is not a reason to fail to provide access to new
> joiners editing in good faith.
>
>
>
>> What isn’t feasible is automatically giving everyone IPBE, global or
>> local, as it would make CU next to useless. Anyone intent on abuse could
>> just flip a VPN on. This isn’t “the convenience of current checkusers”,
>> this is an indisputable fact. People subject to bans often try to get IPBE
>> so they can edit on a VPN without concern for that account being found in
>> relation to previous ones. Any human review is better than mass-granting it
>> to tens of thousands of accounts. We just need to speed up the time it
>> takes to do that human review.
>>
>>
> No, it would not "make CU next to useless". If people are contributing as
> part of editathons or similar, and if 100% of all their contributions are
> valuable good faith contributions, nothing else should matter. Literally
> they are not using the account for anything wrong, so why would anyone
> care? It is not the job of checkusers to be secret police and see all new
> joiners in bad faith, that is neither useful, nor a good use of volunteer
> time.
>
>
>> Regards,
>> Rae
>>
>> On Sat, Apr 23, 2022 at 04:48 Lane Chance  wrote:
>>
>>> "Granting IPBE by default to [...extendedconfirmed]/etc. users is not
>>> feasible."
>>>
>>> Granting IPBE to large groups of good faith editors is feasible, such as
>>> entire classes of people during editathons, all registered accounts joining
>>> a virtual conference, or everyone with more than 1,000 edits on wikidata.
>>>
>>> "also make CU next to useless" is a unverifiable hypothesis which puts
>>> the convenience of current checkusers and the existing practices against
>>> the safety of new and regular users.
>>>
>>> Checkusers are not legally accountable for their use of privileges, and
>>> in the past checkusers have been found to have kept their own private
>>> records, despite the agreement not to do it and simply been allowed to
>>> vanish without any serious consequences.
>>>
>>> Considering that the risks to some users is prosecution, imprisonment or
>>> harassment by state actors which may be instigated by leaking this
>>> information, simple precautions like GIPBE should be automatic and
>>> preferably unquestioned for some regions or types of editathon or
>>> competition, such as for good faith contributors to the articles about the
>>> Ukraine war or human rights in China. If that's inconvenient for volunteer
>>> checkusers, than it's pretty certain that the WMF can fund an support
>>> service under meaningfully legally enforceable non-disclosure agreements,
>>> even independent of the WMF itself if necessary, to run necessary
>>> verification and ensure that the editors are not just vandals or state
>>> lobbyists.
>>>
>>> Lane
>>>
>>> On Fri, 22 Apr 2022 at 20:49, Rae Adimer via Wikimedia-l <
>>> wikimedia-l@lists.wikimedia.org> wrote:
>>>
 It would result in every block effectively being anon-only, and it
 would also make CU next to useless. Granting IPBE by default to
 autoconfirmed/extendedconfirmed/etc. users is not feasible.

 
 User:Vermont  on
 Wikimedia projects
 they/them/theirs (why pronouns matter
 )


 On Thu, Apr 21, 2022 at 4:00 PM Vi to  wrote:

> 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 

[Wikimedia-l] Re: Wikimedia Foundation Board of Trustees 2022 election - updates

[Chris Keating]

On Sat, Apr 23, 2022 at 1:32 PM Andreas Kolbe  wrote:

> Dear Dariusz,
>
> I am surprised your post has not attracted more attention. It's probably
> because you did not spell out what the adopted recommendation involves. It
> says (my emphases):[1]
>
>
> *The Board of Trustees wants to improve the set of skills and the
> diversity contributed by newly selected trustees. For this reason, the
> Board has approved a new process to select two community-and-affiliate
> trustees this year. The objective is to have two trustees confirmed by
> October 1st. Affiliates will vote to pre-select 6 candidates. A community
> vote will decide who from these 6 candidates will be recommended for the
> two seats.*
>
> This is a fundamental change to the WMF board election process. Many
> people will feel that this further disenfranchises the volunteer community.
>

The effect of this is that the two seats which were in the past solely
elected by the Wikimedia Affiliates will now be elected through this
combined model where the affiliates shortlist 6 candidates and the
community elects two of them.

That is, to my mind, enfranchising the volunteer community to a greater
extent.
___
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/X23XT2PEFSQKN2WPJZOEY64EMC27GZSH/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Lane Chance]

On Sat, 23 Apr 2022 at 15:17, Rae Adimer via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> Hi Lane,
>
> I would appreciate if you could take the time to learn about an issue
> before holding strong, accusatory opinions about it.
>

Maybe reading the facts in my email would be a good starting point. Your
response has not refuted any of those facts, in fact as a checkuser you no
doubt could confirm exactly how many times in the past checkuser tools have
been misused and how they are still open to being misused.


> gIPBE is granted to people in China and other areas where they want to use
> proxies for security reasons. A significant portion of current gIPBEs are
> for people in China. The issue here is not people being declined gIPBE,
> it’s the sheer amount of people who need it and the lack of infrastructure
> for current volunteers to handle those requests.
>

 Declining was not mentioned and is not the issue. Alternatives for "lack
of infrastructure" and lack of "current volunteers" was addressed in my
email. Lacking volunteers is not a reason to fail to provide access to new
joiners editing in good faith.



> What isn’t feasible is automatically giving everyone IPBE, global or
> local, as it would make CU next to useless. Anyone intent on abuse could
> just flip a VPN on. This isn’t “the convenience of current checkusers”,
> this is an indisputable fact. People subject to bans often try to get IPBE
> so they can edit on a VPN without concern for that account being found in
> relation to previous ones. Any human review is better than mass-granting it
> to tens of thousands of accounts. We just need to speed up the time it
> takes to do that human review.
>
>
No, it would not "make CU next to useless". If people are contributing as
part of editathons or similar, and if 100% of all their contributions are
valuable good faith contributions, nothing else should matter. Literally
they are not using the account for anything wrong, so why would anyone
care? It is not the job of checkusers to be secret police and see all new
joiners in bad faith, that is neither useful, nor a good use of volunteer
time.


> Regards,
> Rae
>
> On Sat, Apr 23, 2022 at 04:48 Lane Chance  wrote:
>
>> "Granting IPBE by default to [...extendedconfirmed]/etc. users is not
>> feasible."
>>
>> Granting IPBE to large groups of good faith editors is feasible, such as
>> entire classes of people during editathons, all registered accounts joining
>> a virtual conference, or everyone with more than 1,000 edits on wikidata.
>>
>> "also make CU next to useless" is a unverifiable hypothesis which puts
>> the convenience of current checkusers and the existing practices against
>> the safety of new and regular users.
>>
>> Checkusers are not legally accountable for their use of privileges, and
>> in the past checkusers have been found to have kept their own private
>> records, despite the agreement not to do it and simply been allowed to
>> vanish without any serious consequences.
>>
>> Considering that the risks to some users is prosecution, imprisonment or
>> harassment by state actors which may be instigated by leaking this
>> information, simple precautions like GIPBE should be automatic and
>> preferably unquestioned for some regions or types of editathon or
>> competition, such as for good faith contributors to the articles about the
>> Ukraine war or human rights in China. If that's inconvenient for volunteer
>> checkusers, than it's pretty certain that the WMF can fund an support
>> service under meaningfully legally enforceable non-disclosure agreements,
>> even independent of the WMF itself if necessary, to run necessary
>> verification and ensure that the editors are not just vandals or state
>> lobbyists.
>>
>> Lane
>>
>> On Fri, 22 Apr 2022 at 20:49, Rae Adimer via Wikimedia-l <
>> wikimedia-l@lists.wikimedia.org> wrote:
>>
>>> It would result in every block effectively being anon-only, and it would
>>> also make CU next to useless. Granting IPBE by default to
>>> autoconfirmed/extendedconfirmed/etc. users is not feasible.
>>>
>>> 
>>> User:Vermont  on
>>> Wikimedia projects
>>> they/them/theirs (why pronouns matter
>>> )
>>>
>>>
>>> On Thu, Apr 21, 2022 at 4:00 PM Vi to  wrote:
>>>
 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, 

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

[Yaroslav Blanter]

I was personally hit by an open proxy when I was on holidays last year
(South Tirol, Italy, for the record). I could edit the four projects where
I am administrator, but I could not edit five other projects where I update
the image of the day. (In fact, I could not edit Meta either except for my
own talk page). On my talk page, I requested an exempt and was quickly
given it; then I requested a global exempt for the remaining couple of days
and was given it as well; I can not really complain about the reaction
speed. However, I am by every definition a trusted user: 500K global edits,
admin flags on four projects, and a global rollback. I guess at least half
of the stewards have seen my username around. It probably would be easier
for everybody if I could get a global IP block exempt for say two or three
years, and then have it renewed assuming I am still active and the account
is not blocked on any project. I am sure we could come up with some
criteria for trusted users, and these can be given long-term exempts. This
would not fully solve the problem, but will take some time off the
stewards' hands.

Best
Yaroslav

On Sat, Apr 23, 2022 at 4:17 PM Rae Adimer via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> Hi Lane,
>
> I would appreciate if you could take the time to learn about an issue
> before holding strong, accusatory opinions about it.
>
> gIPBE is granted to people in China and other areas where they want to use
> proxies for security reasons. A significant portion of current gIPBEs are
> for people in China. The issue here is not people being declined gIPBE,
> it’s the sheer amount of people who need it and the lack of infrastructure
> for current volunteers to handle those requests.
>
> What isn’t feasible is automatically giving everyone IPBE, global or
> local, as it would make CU next to useless. Anyone intent on abuse could
> just flip a VPN on. This isn’t “the convenience of current checkusers”,
> this is an indisputable fact. People subject to bans often try to get IPBE
> so they can edit on a VPN without concern for that account being found in
> relation to previous ones. Any human review is better than mass-granting it
> to tens of thousands of accounts. We just need to speed up the time it
> takes to do that human review.
>
> Regards,
> Rae
>
> On Sat, Apr 23, 2022 at 04:48 Lane Chance  wrote:
>
>> "Granting IPBE by default to [...extendedconfirmed]/etc. users is not
>> feasible."
>>
>> Granting IPBE to large groups of good faith editors is feasible, such as
>> entire classes of people during editathons, all registered accounts joining
>> a virtual conference, or everyone with more than 1,000 edits on wikidata.
>>
>> "also make CU next to useless" is a unverifiable hypothesis which puts
>> the convenience of current checkusers and the existing practices against
>> the safety of new and regular users.
>>
>> Checkusers are not legally accountable for their use of privileges, and
>> in the past checkusers have been found to have kept their own private
>> records, despite the agreement not to do it and simply been allowed to
>> vanish without any serious consequences.
>>
>> Considering that the risks to some users is prosecution, imprisonment or
>> harassment by state actors which may be instigated by leaking this
>> information, simple precautions like GIPBE should be automatic and
>> preferably unquestioned for some regions or types of editathon or
>> competition, such as for good faith contributors to the articles about the
>> Ukraine war or human rights in China. If that's inconvenient for volunteer
>> checkusers, than it's pretty certain that the WMF can fund an support
>> service under meaningfully legally enforceable non-disclosure agreements,
>> even independent of the WMF itself if necessary, to run necessary
>> verification and ensure that the editors are not just vandals or state
>> lobbyists.
>>
>> Lane
>>
>> On Fri, 22 Apr 2022 at 20:49, Rae Adimer via Wikimedia-l <
>> wikimedia-l@lists.wikimedia.org> wrote:
>>
>>> It would result in every block effectively being anon-only, and it would
>>> also make CU next to useless. Granting IPBE by default to
>>> autoconfirmed/extendedconfirmed/etc. users is not feasible.
>>>
>>> 
>>> User:Vermont  on
>>> Wikimedia projects
>>> they/them/theirs (why pronouns matter
>>> )
>>>
>>>
>>> On Thu, Apr 21, 2022 at 4:00 PM Vi to  wrote:
>>>
 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] Re: Open proxies and IP blocking

[Rae Adimer via Wikimedia-l]

Hi Lane,

I would appreciate if you could take the time to learn about an issue
before holding strong, accusatory opinions about it.

gIPBE is granted to people in China and other areas where they want to use
proxies for security reasons. A significant portion of current gIPBEs are
for people in China. The issue here is not people being declined gIPBE,
it’s the sheer amount of people who need it and the lack of infrastructure
for current volunteers to handle those requests.

What isn’t feasible is automatically giving everyone IPBE, global or local,
as it would make CU next to useless. Anyone intent on abuse could just flip
a VPN on. This isn’t “the convenience of current checkusers”, this is an
indisputable fact. People subject to bans often try to get IPBE so they can
edit on a VPN without concern for that account being found in relation to
previous ones. Any human review is better than mass-granting it to tens of
thousands of accounts. We just need to speed up the time it takes to do
that human review.

Regards,
Rae

On Sat, Apr 23, 2022 at 04:48 Lane Chance  wrote:

> "Granting IPBE by default to [...extendedconfirmed]/etc. users is not
> feasible."
>
> Granting IPBE to large groups of good faith editors is feasible, such as
> entire classes of people during editathons, all registered accounts joining
> a virtual conference, or everyone with more than 1,000 edits on wikidata.
>
> "also make CU next to useless" is a unverifiable hypothesis which puts the
> convenience of current checkusers and the existing practices against the
> safety of new and regular users.
>
> Checkusers are not legally accountable for their use of privileges, and in
> the past checkusers have been found to have kept their own private records,
> despite the agreement not to do it and simply been allowed to vanish
> without any serious consequences.
>
> Considering that the risks to some users is prosecution, imprisonment or
> harassment by state actors which may be instigated by leaking this
> information, simple precautions like GIPBE should be automatic and
> preferably unquestioned for some regions or types of editathon or
> competition, such as for good faith contributors to the articles about the
> Ukraine war or human rights in China. If that's inconvenient for volunteer
> checkusers, than it's pretty certain that the WMF can fund an support
> service under meaningfully legally enforceable non-disclosure agreements,
> even independent of the WMF itself if necessary, to run necessary
> verification and ensure that the editors are not just vandals or state
> lobbyists.
>
> Lane
>
> On Fri, 22 Apr 2022 at 20:49, Rae Adimer via Wikimedia-l <
> wikimedia-l@lists.wikimedia.org> wrote:
>
>> It would result in every block effectively being anon-only, and it would
>> also make CU next to useless. Granting IPBE by default to
>> autoconfirmed/extendedconfirmed/etc. users is not feasible.
>>
>> 
>> User:Vermont  on Wikimedia
>> projects
>> they/them/theirs (why pronouns matter
>> )
>>
>>
>> On Thu, Apr 21, 2022 at 4:00 PM Vi to  wrote:
>>
>>> 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? 

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

[Dirk Hünniger via Wikimedia-l]

Hi Juergen,

the mediawiki2latex tool is still used see 
https://qa.debian.org/popcon.php?package=mediawiki2latex


it can handle complex tables. It is fully open source, distributed as a 
debian package, which can run on an OS as a docker container. Currently 
I am only investing little time to keep it working. Still I could do 
more if demand rises in the furtuer


Yours Dirk

On 22.04.22 22:19, Juergen Fenn wrote:

Dear Erik,
Dear list,

Am 22.04.22 um 21:35 Uhr schrieb Erik Moeller:

That specific book is a good example of the problems that we've always
had with PDF generation by way of LaTeX, such as complex tables. Also
note the intermittent appearance of unsupported tags in the output.

As far as I know, the renderer they use is still partially
proprietary. I'm not sure if it would still be seen as valuable to
open source fully, given that LaTeX is indeed probably a technical
dead-end for these kinds of conversions, and given that the codebase
is very old.


You might like to know that there is a more recent free
MediaWiki-to-LaTeX project that is actively maintained by Dirk Hünninger
and can be tried out on WMF Labs:

https://mediawiki2latex.wmflabs.org/

I understand that Dirk produced some PDF versions for German Wikibooks,
but I do not know whether he is still contributing.

I put Dirk in CC to let him know we speak of matters LaTeX. Maybe he
would like to join the conversation.

Best regards,
Jürgen.

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

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

[Étienne Beaulé]

Better PDF rendering from browsers themselves by their print functionality 
(with CSS3’s Paged Media Module[1]) could be another method. There’s often less 
friction when using features integrated in the browser, and with the much 
better general rendering and support through HTML engines over other projects 
like LaTeX (no matter how much I use it myself).

Sadly there doesn’t seem to be much currently done in this track, at least in 
Chromium[2].

[1]: https://www.w3.org/TR/css-gcpm-3/ 
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=368053 


Étienne

> Le 22 avr. 2022 à 16:35, Erik Moeller  a écrit :
> 
> For those who haven't tried it out, here's what the PediaPress output
> looks like (after it's done compiling the book, it'll give you a
> preview):
> https://en.wikipedia.org/w/index.php?title=Special:Book=order_collection=User:Pmillett/Books/2009%E2%80%9310_PBA_season=pediapress
> 
> That specific book is a good example of the problems that we've always
> had with PDF generation by way of LaTeX, such as complex tables. Also
> note the intermittent appearance of unsupported tags in the output.
> 
> As far as I know, the renderer they use is still partially
> proprietary. I'm not sure if it would still be seen as valuable to
> open source fully, given that LaTeX is indeed probably a technical
> dead-end for these kinds of conversions, and given that the codebase
> is very old.
> 
> If you're mainly using English Wikipedia, you might be under the
> mistaken impression that the book creator is hidden from view. But it
> is in fact still linked from the sidebar of many of the largest
> Wikipedias, including French, Arabic, Spanish, Italian, Dutch,
> Japanese, Polish, Portuguese, Russian, Swedish, Ukrainian, and
> Vietnamese. A link on every page - that's quite a bit of exposure!
> 
> I agree it's a fair question what should happen to it: removal,
> replacement, or repair. In general, I do think there's a strategic
> case to be made for a more user-friendly way to create custom
> collections and share/export them in multiple formats (and to point
> people towards Kiwix and the ZIM format, which are indeed awesome for
> educational and offline use cases), and it'd be great to see direct
> collaborations with the OpenZIM/Kiwix community on this as Emmanuel
> suggests.
> 
> Warmly,
> Erik
> ___
> 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/G5CXXFAKJP6HFFIRPBQWRRURVB7PPVKR/
> 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/IR3ZFLM23MV3AOURUFRJNWJM7GNYBOBB/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Wikimedia Foundation Board of Trustees 2022 election - updates

[Andreas Kolbe]

Dear Dariusz,

I am surprised your post has not attracted more attention. It's probably
because you did not spell out what the adopted recommendation involves. It
says (my emphases):[1]


*The Board of Trustees wants to improve the set of skills and the diversity
contributed by newly selected trustees. For this reason, the Board has
approved a new process to select two community-and-affiliate trustees this
year. The objective is to have two trustees confirmed by October 1st.
Affiliates will vote to pre-select 6 candidates. A community vote will
decide who from these 6 candidates will be recommended for the two seats.*

This is a fundamental change to the WMF board election process. Many people
will feel that this further disenfranchises the volunteer community.

Moreover, this pre-selection of electable candidates is performed by
functionaries who are financially dependent on the Wikimedia Foundation.
Arguably, this builds further conflicts of interest into the process – at a
time when the Wikimedia Foundation already asks the public for more and
more money each year.[2]

The WMF simply no longer represents the volunteer community, and no longer
even considers that to be its role – if it did, it would hold free
elections.

Personally, I think that is a shame. I guess if volunteers would like to
have an organisation representing their interests, they will have to form
one themselves.

Best,
Andreas

[1]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard/April_2022_Board_Election_process_in_2022
[2] https://en.wikipedia.org/wiki/Wikipedia:Fundraising_statistics





On Wed, Apr 13, 2022 at 6:59 PM Dariusz Jemielniak 
wrote:

> Hi everyone,
>
> The Wikimedia Foundation Board of Trustees met between March 23-24 for our
> first in-person meeting in over two years. It was an opportunity to welcome
> our new CEO and several new trustees who have recently joined the Board.
> Further updates from the meeting will be shared soon, I am writing now to
> report on resolutions that the Board made regarding the upcoming 2022
> elections:
>
>
>1.
>
>We resolved to adopt recommendations related to the elections process
>
> .
>These recommendations have been developed as a result of feedback from the 
> community
>Call for Feedback
>
> 
>that happened in January and further discussions by a Board Selection Task
>Force. They will be implemented on a trial basis for the 2022 election.
>2.
>
>In service of maintaining continuity and stability in our leadership,
>we resolved to make some modifications to our plans to expand the Board
>
> 
>.
>
>
> You can read about the details of these resolutions on Meta. We are happy
> to discuss and answer any questions on the corresponding talk pages.
>
> Best,
>
> Dariusz on behalf of the Wikimedia Foundation Board of Trustees
>
> ___
> 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/ZLEFWZX2SWFX3LMZK4LSEZ2B6TNF34PZ/
> 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/DCK3ZIAPGSQGFAAF4JQKCAYUNACEJ4IQ/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Lane Chance]

"Granting IPBE by default to [...extendedconfirmed]/etc. users is not
feasible."

Granting IPBE to large groups of good faith editors is feasible, such as
entire classes of people during editathons, all registered accounts joining
a virtual conference, or everyone with more than 1,000 edits on wikidata.

"also make CU next to useless" is a unverifiable hypothesis which puts the
convenience of current checkusers and the existing practices against the
safety of new and regular users.

Checkusers are not legally accountable for their use of privileges, and in
the past checkusers have been found to have kept their own private records,
despite the agreement not to do it and simply been allowed to vanish
without any serious consequences.

Considering that the risks to some users is prosecution, imprisonment or
harassment by state actors which may be instigated by leaking this
information, simple precautions like GIPBE should be automatic and
preferably unquestioned for some regions or types of editathon or
competition, such as for good faith contributors to the articles about the
Ukraine war or human rights in China. If that's inconvenient for volunteer
checkusers, than it's pretty certain that the WMF can fund an support
service under meaningfully legally enforceable non-disclosure agreements,
even independent of the WMF itself if necessary, to run necessary
verification and ensure that the editors are not just vandals or state
lobbyists.

Lane

On Fri, 22 Apr 2022 at 20:49, Rae Adimer via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> It would result in every block effectively being anon-only, and it would
> also make CU next to useless. Granting IPBE by default to
> autoconfirmed/extendedconfirmed/etc. users is not feasible.
>
> 
> User:Vermont  on Wikimedia
> projects
> they/them/theirs (why pronouns matter
> )
>
>
> On Thu, Apr 21, 2022 at 4:00 PM Vi to  wrote:
>
>> 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