Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Gergo Tisza]

On Fri, Jun 8, 2018 at 3:44 PM Yaron Koren  wrote:

> I suppose that one solution which hasn't been discussed yet is to change
> the wording of that file so that it says something more defensible, like
> "This extension is hosted on facilities governed by the Code of Conduct",
> or that kind of thing - that would at least remove the pragmatic objection
> that I (and some others in this thread) have raised.
>

Thanks for the constructive proposal, Yaron. I agree this is an accurate
description of what the code of conduct says now about scope.

I still think limiting scope like that is problematic and in the unlikely
case that someone does abuse or harass community members outside Wikimedia
platforms while simultaneously making use of those platforms, I believe the
CoC committee would leverage that to deter them (threaten to ban or fork if
it comes to that) - that seems like the only morally tenable option. So I
guess the best way to resolve the issue is to make a CoC amendment proposal.

It still leaves open the question of whether the file should be made
> mandatory, and if so, what the mechanism should be to determine that.
>

A CoC committee decision, presumably? They are probably in the best
position to tell whether it would meaningfully help their work or not.

That said, we still haven't solved adding the file to new repos
automatically, or added it to the repos created since last summer, or
determined which non-extension/skin repos makes it sense to add to, all of
which have much more impact than anything that could happen with the
handful of repos where it is actively opposed. So it does not make sense to
invest a lot of energy into this right now, IMO.

As I wrote briefly before, I just don't think the file
> is making an accurate statement, given that it implies that *all*
> development of the extension is governed by the CoC, which is not the case.


I'd still like the understand what the assumed harm is. Is this strictly a
moral issue, where you want to avoid giving misleading information, but
otherwise that information would be harmless? Or a liability issue, where
your clients think that working on / using a CoC-covered extension makes it
more likely that they get sued or publicly attacked? Or do you think you
might work with clients who might be deterred because they do development
in ways that violate the CoC, and would be unwilling to change that? Or
some clients might boycott such extensions for political reasons?


On Fri, Jun 8, 2018 at 8:23 PM Greg Rundlett (freephile) 
wrote:

> I can also (as a consultant) see
> how written policies which my clients see in my code could be construed as
> a possible LIABILITY or RISK on their  part. They'll either want me to
> carry more indemnity insurance, or even be disinclined to do business with
> me. Not because they don't abide by the code of conduct, but because
> there's an explicit notice of some obligation that creates liability.


Thanks for being specific about how the file is a problem for you. It is
important for the health of the MediaWiki ecosystem that we make commercial
MediaWiki development as frictionless as possible and don't create policies
that place an undue burden on it.
That said, code of conduct notices are already abundant in opensource
software; we are not doing some kind of bold new experiment, just following
the standard. Was there a chilling effect for projects that added such a
file? Are you aware of consultants running into problems over that?
How do you handle this issue in your own work in non-MediaWiki code? Do
you, for example, choose between Javascript frameworks or PHP libraries you
include in your extensions based on whether they include a code of conduct?


On Sat, Jun 9, 2018 at 3:28 AM C. Scott Ananian 
wrote:

> My personal opinion is (a) it should be mandatory, but the
> contents not strictly proscribed -- in the same way that github
> loosely-requires an open source license statement in its public repos (ie,
> I think it's in the terms of service but not enforced by code), and (b) the
> proper mechanism is probably techcomm/archcomm.


On reflection, I think trying to involve TechCom would be a bad idea. In a
contentious issue like this, any decision (or even the refusal to make one)
would probably result in a loss of social capital, which is better spent on
getting people on board with transforming MediaWiki architecture. The CoC
committee on the other hand was selected and trained for expertise in
specifically these kinds of social issues, and they don't have much
standing to lose in the eyes of people who are dubious about the CoC anyway.


On Fri, Jun 8, 2018 at 6:13 PM Brian Wolff  wrote:

> * Generally speaking, its usually considered in poorform to have an
> argument about something, lose the argument (or at least not win it), wait
> a year until people forget about it, and then try and do the exact same
> thing.
>

While I disagree that this would be an accurate description of what
happened, in ge

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

[Gergő Tisza]

Hi all,

per the discussion on Phabricator, I'd like to split the administrator
("sysop") user group into two parts - one which can edit sitewide CSS/JS,
and one which can not. You can find the details and detailed rationale in
the task:
https://phabricator.wikimedia.org/T190015

To inform the editor communities, and to make sure we can accommodate their
needs, I plan to run a community consultation; I'll probably kick it off on
Friday and have it run for two weeks. You can find the draft here:
https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_editing_sitewide_CSS/JS

I would appreciate if folks who are knowledgeable about the use of CSS/JS
editing and user rights management in various parts of the community could
look at it and add their concerns or suggestion to the talk page (or
Phabricator if that's more appropriate). Suggestions for a better group
name are especially welcome.

(As I wrote it in the FAQ on the consultation page, I think making sure
that MediaWiki is secure and at the same time empowers its users falls
under the authority of the developer community, and so the normal code
review process is appropriate for this change. Thus the consultation is not
intended to be an RfC or other discussion/veto type process. If you
disagree about the change in general, please discuss that on Phabricator,
or the linked Gerrit patches.)

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

[Wikitech-l] Making PolyGerrit the default ui for gerrit

[Paladox]

Hi, i have created this task [1] with i have uploaded this patch [2] to make 
polygerrit the default ui.
The reason why is upstream are preparing to remove the gwtui very soon. In 
matter of fact upstream have disabled the gwtui on *.googlesource.com. Upstream 
already have this change [3] to remove the ui. Making PolyGerrit the default ui 
will get new users use to the new ui.
GWTUI will still be available with ui switcher in the footer or you can append 
the url like https://gerrit.wikimedia.org/r/?polygerrit=0

PolyGerrit is stable, secure and also fast. It also has features that you 
cannot see in gwtui like user status, naming your patchiest (description), cc 
feature and also being able to tell who added you as a reviewer.
This email is advanced notice before we change the default ui.
any bugs todo with polygerrit / gerrit can be filled at 
https://phabricator.wikimedia.org/project/view/330/ and we can forward it 
upstream.


[1] https://phabricator.wikimedia.org/T196812
[2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/439444
[3] https://gerrit-review.googlesource.com/c/gerrit/+/116790


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

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

[Petr Bena]

Is there any historical evidence that sysops being able to edit JS /
CSS caused some serious issues? Your point that "most of
administrators don't understand JS / CSS" is kind of moot. They are
usually trustworth and intelligent people. They don't mess up with
something they don't understand and therefore it makes little sense to
restrict them from being able to do that.

I remember that many years ago there was an attempt to split sysop
group on English Wikipedia to multiple smaller roles and it horribly
failed.

I understand your points, but do we really need it? Is it going to
improve anything?

On Mon, Jun 11, 2018 at 1:58 PM, Gergő Tisza  wrote:
> Hi all,
>
> per the discussion on Phabricator, I'd like to split the administrator
> ("sysop") user group into two parts - one which can edit sitewide CSS/JS,
> and one which can not. You can find the details and detailed rationale in
> the task:
> https://phabricator.wikimedia.org/T190015
>
> To inform the editor communities, and to make sure we can accommodate their
> needs, I plan to run a community consultation; I'll probably kick it off on
> Friday and have it run for two weeks. You can find the draft here:
> https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_editing_sitewide_CSS/JS
>
> I would appreciate if folks who are knowledgeable about the use of CSS/JS
> editing and user rights management in various parts of the community could
> look at it and add their concerns or suggestion to the talk page (or
> Phabricator if that's more appropriate). Suggestions for a better group
> name are especially welcome.
>
> (As I wrote it in the FAQ on the consultation page, I think making sure
> that MediaWiki is secure and at the same time empowers its users falls
> under the authority of the developer community, and so the normal code
> review process is appropriate for this change. Thus the consultation is not
> intended to be an RfC or other discussion/veto type process. If you
> disagree about the change in general, please discuss that on Phabricator,
> or the linked Gerrit patches.)
>
> Thanks!
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Bartosz Dziewoński]

On 2018-06-11 15:28, Petr Bena wrote:

Is there any historical evidence that sysops being able to edit JS /
CSS caused some serious issues? Your point that "most of
administrators don't understand JS / CSS" is kind of moot. They are
usually trustworth and intelligent people. They don't mess up with
something they don't understand and therefore it makes little sense to
restrict them from being able to do that.


Yes, in the recent months there have been several incidents of a sysop 
accounts on Wikimedia wikis being taken over by an attacker, and the 
first thing done by the compromised accounts was adding nasty code to 
sitewide JavaScript to take over further accounts.



--
Bartosz Dziewoński

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

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

[Thiemo Kreuz]

> Is there any historical evidence that sysops being able to edit JS / CSS 
> caused some serious issues?

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

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

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

Best
Thiemo

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

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

[Petr Bena]

OK in that case I think this should be done.

On Mon, Jun 11, 2018 at 3:40 PM, Thiemo Kreuz  wrote:
>> Is there any historical evidence that sysops being able to edit JS / CSS 
>> caused some serious issues?
>
> Oh yes, this happens more often than I feel it needs to. I remember a
> situation when I posted a fix for a script in the MediaWiki:…
> namespace as an {{edit request}}, and a well-meaning administrator
> tried to "improve" my line of code and forgot a comma, breaking all
> JavaScript for all logged-in as well as not logged-in Wikipedia
> editors and readers for some painful minutes.
>
> I believe such can be avoided with more clear roles that are visible
> for everybody. A separate "tech admin" role would also allow
> volunteers to apply for exactly that, and not be asked why they don't
> do enough "administrator actions" with their privileges.
>
> Sure, this is anecdotal evidence. Please forgive me, but I currently
> don't have the time to find the pages documenting these situation.
>
> Best
> Thiemo
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Gergo Tisza]

On Mon, Jun 11, 2018 at 3:28 PM Petr Bena  wrote:

> Is there any historical evidence that sysops being able to edit JS /
> CSS caused some serious issues? Your point that "most of
> administrators don't understand JS / CSS" is kind of moot. They are
> usually trustworth and intelligent people. They don't mess up with
> something they don't understand and therefore it makes little sense to
> restrict them from being able to do that.
>

The primary concern here is someone taking over the account by password
guessing, social engineering, phishing, exploiting some unfixed MediaWiki
vulnerability etc. The secondary concern is admins becoming malicious or
doing something stupid as a way of ragequitting, which is rare but does
happen (for example, not so long ago, someone thought it would be a good
idea to make money by installing a cryptocoin miner on Wikipedia). Admins
making a mistake and breaking the site also happens occasionally, but
that's not a security problem so it's a pretty minor issue in comparison.

I understand your points, but do we really need it? Is it going to
> improve anything?


It reduces the attack surface. Less people with access means less
vulnerable passwords, less people whose system has been infected with the
latest computer virus etc.
Also there are things we might require JS editors to do which might be
inconvenient to some people (e.g. making two-factor authentication
required) so it's good to reduce the number of people who have to be
exposed to that.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Petr Bena]

Speaking of security, I believe that all sysops and people allowed to
edit JS / CSS anywhere on mediawiki sites should be required to use
2FA.

On Mon, Jun 11, 2018 at 4:53 PM, Gergo Tisza  wrote:
> On Mon, Jun 11, 2018 at 3:28 PM Petr Bena  wrote:
>
>> Is there any historical evidence that sysops being able to edit JS /
>> CSS caused some serious issues? Your point that "most of
>> administrators don't understand JS / CSS" is kind of moot. They are
>> usually trustworth and intelligent people. They don't mess up with
>> something they don't understand and therefore it makes little sense to
>> restrict them from being able to do that.
>>
>
> The primary concern here is someone taking over the account by password
> guessing, social engineering, phishing, exploiting some unfixed MediaWiki
> vulnerability etc. The secondary concern is admins becoming malicious or
> doing something stupid as a way of ragequitting, which is rare but does
> happen (for example, not so long ago, someone thought it would be a good
> idea to make money by installing a cryptocoin miner on Wikipedia). Admins
> making a mistake and breaking the site also happens occasionally, but
> that's not a security problem so it's a pretty minor issue in comparison.
>
> I understand your points, but do we really need it? Is it going to
>> improve anything?
>
>
> It reduces the attack surface. Less people with access means less
> vulnerable passwords, less people whose system has been infected with the
> latest computer virus etc.
> Also there are things we might require JS editors to do which might be
> inconvenient to some people (e.g. making two-factor authentication
> required) so it's good to reduce the number of people who have to be
> exposed to that.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Bart Humphries]

" I remember a situation when I posted a fix for a script in the
MediaWiki namespace
as an {{edit request}}, and a well-meaning administrator tried to "improve"
my line of code and forgot a comma, breaking all JavaScript for all
logged-in as well as not logged-in Wikipedia editors and readers for some
painful minutes"

Everyone makes mistakes.  I presume that under this revised proposal, that
administrator would still have had JS edit permission, and might have still
made the mistake.  I mean, they apparently knew JS well enough to have been
able to pass whatever test would have been required to get that permission
added to their account.

Perhaps we need a real test environment of some sort, so that changes like
that must be run on the test server for X [time period] before being pushed
to live?  Changes can't happen on live until there's some sort of consensus
that the test code actually works as run -- any additional changes reset
the test time period counter before it can be pushed to live.

Bart Humphries
bart.humphr...@gmail.com
(909)529-BART(2278)

On Mon, Jun 11, 2018 at 7:40 AM, Thiemo Kreuz 
wrote:

> > Is there any historical evidence that sysops being able to edit JS / CSS
> caused some serious issues?
>
> Oh yes, this happens more often than I feel it needs to. I remember a
> situation when I posted a fix for a script in the MediaWiki:…
> namespace as an {{edit request}}, and a well-meaning administrator
> tried to "improve" my line of code and forgot a comma, breaking all
> JavaScript for all logged-in as well as not logged-in Wikipedia
> editors and readers for some painful minutes.
>
> I believe such can be avoided with more clear roles that are visible
> for everybody. A separate "tech admin" role would also allow
> volunteers to apply for exactly that, and not be asked why they don't
> do enough "administrator actions" with their privileges.
>
> Sure, this is anecdotal evidence. Please forgive me, but I currently
> don't have the time to find the pages documenting these situation.
>
> Best
> Thiemo
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit as a shared community space

[Moriel Schottlender]

Yaron,

On Sun, Jun 10, 2018 at 8:35 PM Yaron Koren  wrote:

> This looks to me like a violation of the Code of Conduct. I don't want to
> cause more drama in this discussion, especially since it seems like a sort
> of consensus has formed and we can all move on, but I do find it disturbing
> that a member of the Code of Conduct Committee, who is tasked with
> enforcing the rules, is himself willing to engage in personal attacks.
>

This isn't a personal attack, it's a consequence to your earlier email.

You stated yourself, that one of the reasons you don't think a COC.md file
should exist in your repository is because not all interactions are covered
by it. While that might be true technically-speaking, it does make a
statement to potential contributors about what they might expect in terms
of feeling safe and secure with a CoC in place.

For those of us who "bad interaction online" are a norm rather than an edge
case, a statement that the CoC is not fully covering a space means we don't
go to that space if we can help it.

Saying that one does not intend on touching a space where the maintainer
clearly stated the CoC is only partially in effect is not a personal attack
-- it's a consequence of what you said.
A consequence that is also shared by others who may feel less comfortable
speaking up on public threads, but would avoid going into such spaces all
the same. Not because of who you are personally, but because of what your
statement about how your space is governed means.

Whatever other claims and discussion is going on in this and the other
thread, let's not try to make it sound like there's a personal attack going
on here.

Moriel



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

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

[Steven Walling]

I'm definitely supportive of greater security for sitewide JS/CSS, but
Bart's proposal is an interesting one. (Sorry for top posting, on mobile)

What if we required review of edits to JS/CSS in the MediaWiki namespace
(not in other namespaces), ala pending changes or something similar? We
require code review in Gerrit, so why not sitewide code in the wiki?

I propose this because if we split code editing rights into a separate
userright, this entails increased process bloat for managing who and who
doesn't get the right, the criteria for deciding that, and so on. Requiring
code review would allow for more flexibility while increasing security. It
would require less process bloat too because the community already has
mechanisms for requesting edits be confirmed via talk pages and such.

On Mon, Jun 11, 2018 at 8:15 AM Bart Humphries 
wrote:

> " I remember a situation when I posted a fix for a script in the
> MediaWiki namespace
> as an {{edit request}}, and a well-meaning administrator tried to "improve"
> my line of code and forgot a comma, breaking all JavaScript for all
> logged-in as well as not logged-in Wikipedia editors and readers for some
> painful minutes"
>
> Everyone makes mistakes.  I presume that under this revised proposal, that
> administrator would still have had JS edit permission, and might have still
> made the mistake.  I mean, they apparently knew JS well enough to have been
> able to pass whatever test would have been required to get that permission
> added to their account.
>
> Perhaps we need a real test environment of some sort, so that changes like
> that must be run on the test server for X [time period] before being pushed
> to live?  Changes can't happen on live until there's some sort of consensus
> that the test code actually works as run -- any additional changes reset
> the test time period counter before it can be pushed to live.
>
> Bart Humphries
> bart.humphr...@gmail.com
> (909)529-BART(2278)
>
> On Mon, Jun 11, 2018 at 7:40 AM, Thiemo Kreuz 
> wrote:
>
> > > Is there any historical evidence that sysops being able to edit JS /
> CSS
> > caused some serious issues?
> >
> > Oh yes, this happens more often than I feel it needs to. I remember a
> > situation when I posted a fix for a script in the MediaWiki:…
> > namespace as an {{edit request}}, and a well-meaning administrator
> > tried to "improve" my line of code and forgot a comma, breaking all
> > JavaScript for all logged-in as well as not logged-in Wikipedia
> > editors and readers for some painful minutes.
> >
> > I believe such can be avoided with more clear roles that are visible
> > for everybody. A separate "tech admin" role would also allow
> > volunteers to apply for exactly that, and not be asked why they don't
> > do enough "administrator actions" with their privileges.
> >
> > Sure, this is anecdotal evidence. Please forgive me, but I currently
> > don't have the time to find the pages documenting these situation.
> >
> > Best
> > Thiemo
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Yaron Koren]

Gergo Tisza  wrote:

> I'd still like the understand what the assumed harm is. Is this strictly a
> moral issue, where you want to avoid giving misleading information, but
> otherwise that information would be harmless? Or a liability issue, where
> your clients think that working on / using a CoC-covered extension makes
it
> more likely that they get sued or publicly attacked? Or do you think you
> might work with clients who might be deterred because they do development
> in ways that violate the CoC, and would be unwilling to change that? Or
> some clients might boycott such extensions for political reasons?

If I can put words in your mouth, it sounds, based on the specific examples
you give, like your real question is: how would I (and the people I work
with) feel about having the scope of the Code of Conduct be expanded to
match what CODE_OF_CONDUCT.md says? If so, that's a fair question, but I'd
rather not answer it in this thread - I've been trying to keep this
discussion focused on a few basic factual questions (is the CoC file
accurate? Is it mandatory?), and even that has led to a pretty wide-ranging
and heated discussion. So I'd rather not add another very big topic into
the mix. It might make sense to create a separate discussion for that
topic, though.

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

Re: [Wikitech-l] Gerrit as a shared community space

[Yaron Koren]

Hi,

Moriel Schottlender  wrote:
> This isn't a personal attack, it's a consequence to your earlier email.
>
> You stated yourself, that one of the reasons you don't think a COC.md file
>  should exist in your repository is because not all interactions are
covered
>  by it. While that might be true technically-speaking, it does make a
>  statement to potential contributors about what they might expect in terms
>  of feeling safe and secure with a CoC in place.
>
>  For those of us who "bad interaction online" are a norm rather than an
edge
>  case, a statement that the CoC is not fully covering a space means we
don't
>  go to that space if we can help it.
>
>  Saying that one does not intend on touching a space where the maintainer
>  clearly stated the CoC is only partially in effect is not a personal
attack
>  -- it's a consequence of what you said.
>  A consequence that is also shared by others who may feel less comfortable
>  speaking up on public threads, but would avoid going into such spaces all
>  the same. Not because of who you are personally, but because of what your
>  statement about how your space is governed means.
>
>  Whatever other claims and discussion is going on in this and the other
>  thread, let's not try to make it sound like there's a personal attack
going
>  on here.

No, I still think it's a personal attack. I think we've already established
that the CoC does not cover all interactions, and that the CoC.md file is
thus giving false information. Some people have stated that clearly, some
have grudgingly admitted it, but no one has really argued against it. Even
you note that it's "technically" true, whatever exactly that means.

And of course, this file was put in place by a few developers - it wasn't
an opt-in choice. (It's still not 100% clear that it's even an "opt-out"
choice, though at this point it seems to be.)

Given those two things, the presence of a CoC.md file in an extension
directory tells a potential contributor nothing - nothing about additional
security they're getting, and nothing really about the extension's
developers. Actually, it's worse than nothing, because it gives potential
contributors false comfort as far as the protections they'll have. If, as
you say, some people face a real danger of harassment everywhere not
covered by a code of conduct, then it's all the more reason to either
remove that file, or reword it, everywhere - so people know what they're
actually getting into.

So, why should Amir want to avoid dealing with my code specifically? Is it
because he would have fewer protections? Clearly, no. It must be something
about me personally that would make him treat my code differently from
everyone else's.

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

Re: [Wikitech-l] Gerrit as a shared community space

[Moriel Schottlender]

This isn't about not wanting that file in (which is a discussion that
should happen) -- this is about what you, yourself, said, about how
interactions are working in your repo.
That's where people decide whether they want to work in your repo or not.
They hear about the expectations in that space, consider whether those
expectations are right for them, and decide to join or not. That's a
judgment on the rules you decided to enforce and specifically stated you
care about -- it's not about you, your personality, or your personal
behavior.

Quite frankly, I don't blame people who regularly experience harassment
online to avoid spaces where the code of conduct is consciously only
enforced in parts of the space.
I, too, don't feel comfortable in joining that space, even for considering
potential interactions that I might encounter, and knowing that these
interactions, depending where they happen, may not be dealt with to my
personal ideal of what such space should be.

That's a fair conclusion about what we want to do with our time, Yair, and
has nothing to do with who you are as a person.

You stated that as far as you're concerned, there are interactions you
purposefully don't see as being governed by the CoC.
Some developers decide that they purposefully, in their repos, assume it
governs all interactions related to to work on the repo, and some,
apparently, do not.

People hear that you consider some spaces related to work on your repo as
intentionally not included in the CoC.
They make a valid decision that this type of space is not for them.

That's not a personal attack. that's a valid decision about where one wants
to spend their time given the governing rules of the space.

Moriel


On Mon, Jun 11, 2018 at 10:24 AM Yaron Koren  wrote:

> Hi,
>
> Moriel Schottlender  wrote:
> > This isn't a personal attack, it's a consequence to your earlier email.
> >
> > You stated yourself, that one of the reasons you don't think a COC.md
> file
> >  should exist in your repository is because not all interactions are
> covered
> >  by it. While that might be true technically-speaking, it does make a
> >  statement to potential contributors about what they might expect in
> terms
> >  of feeling safe and secure with a CoC in place.
> >
> >  For those of us who "bad interaction online" are a norm rather than an
> edge
> >  case, a statement that the CoC is not fully covering a space means we
> don't
> >  go to that space if we can help it.
> >
> >  Saying that one does not intend on touching a space where the maintainer
> >  clearly stated the CoC is only partially in effect is not a personal
> attack
> >  -- it's a consequence of what you said.
> >  A consequence that is also shared by others who may feel less
> comfortable
> >  speaking up on public threads, but would avoid going into such spaces
> all
> >  the same. Not because of who you are personally, but because of what
> your
> >  statement about how your space is governed means.
> >
> >  Whatever other claims and discussion is going on in this and the other
> >  thread, let's not try to make it sound like there's a personal attack
> going
> >  on here.
>
> No, I still think it's a personal attack. I think we've already established
> that the CoC does not cover all interactions, and that the CoC.md file is
> thus giving false information. Some people have stated that clearly, some
> have grudgingly admitted it, but no one has really argued against it. Even
> you note that it's "technically" true, whatever exactly that means.
>
> And of course, this file was put in place by a few developers - it wasn't
> an opt-in choice. (It's still not 100% clear that it's even an "opt-out"
> choice, though at this point it seems to be.)
>
> Given those two things, the presence of a CoC.md file in an extension
> directory tells a potential contributor nothing - nothing about additional
> security they're getting, and nothing really about the extension's
> developers. Actually, it's worse than nothing, because it gives potential
> contributors false comfort as far as the protections they'll have. If, as
> you say, some people face a real danger of harassment everywhere not
> covered by a code of conduct, then it's all the more reason to either
> remove that file, or reword it, everywhere - so people know what they're
> actually getting into.
>
> So, why should Amir want to avoid dealing with my code specifically? Is it
> because he would have fewer protections? Clearly, no. It must be something
> about me personally that would make him treat my code differently from
> everyone else's.
>
> -Yaron
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Making PolyGerrit the default ui for gerrit

[Paladox]

 The date to switch the default ui is next monday (18/06/18) which will give 
users plenty of time to give there opinion.
Users can still switch back to the old ui just the new ui is secure.
https://phabricator.wikimedia.org/T196812#4273184




On Monday, 11 June 2018, 13:38:20 BST, Paladox  
wrote:  
 
 Hi, i have created this task [1] with i have uploaded this patch [2] to make 
polygerrit the default ui.
The reason why is upstream are preparing to remove the gwtui very soon. In 
matter of fact upstream have disabled the gwtui on *.googlesource.com. Upstream 
already have this change [3] to remove the ui. Making PolyGerrit the default ui 
will get new users use to the new ui.
GWTUI will still be available with ui switcher in the footer or you can append 
the url like https://gerrit.wikimedia.org/r/?polygerrit=0

PolyGerrit is stable, secure and also fast. It also has features that you 
cannot see in gwtui like user status, naming your patchiest (description), cc 
feature and also being able to tell who added you as a reviewer.
This email is advanced notice before we change the default ui.
any bugs todo with polygerrit / gerrit can be filled at 
https://phabricator.wikimedia.org/project/view/330/ and we can forward it 
upstream.


[1] https://phabricator.wikimedia.org/T196812
[2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/439444
[3] https://gerrit-review.googlesource.com/c/gerrit/+/116790


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

Re: [Wikitech-l] Gerrit as a shared community space

[Yaron Koren]

Hi,

Moriel Schottlender  wrote:
> Quite frankly, I don't blame people who regularly experience harassment
> online to avoid spaces where the code of conduct is consciously only
> enforced in parts of the space.
> I, too, don't feel comfortable in joining that space, even for considering
> potential interactions that I might encounter, and knowing that these
> interactions, depending where they happen, may not be dealt with to my
> personal ideal of what such space should be.

Neither I nor any other extension developers are "enforcing" the code of
conduct - that's up to a committee to do.

> You stated that as far as you're concerned, there are interactions you
> purposefully don't see as being governed by the CoC.

I don't know what "purposefully" means there. There are interactions that
are not governed by the CoC - how's that?

> Some developers decide that they purposefully, in their repos, assume it
> governs all interactions related to to work on the repo, and some,
> apparently, do not.

If anyone is "deciding" that, they're making an incorrect decision.
Meaning, you can certainly say that you will not tolerate harassment,
discrimination, etc. in personal emails as specified by the Wikimedia Code
of Conduct - but as far as enforcement, you're on your own, unlike with the
real CoC.

Also, given that every extension had this file added in, how is a potential
contributor to know who "decided" to embrace this file's statement and who
didn't? Given the threat of harassment, it seems awfully risky to assume
that everyone who didn't delete the file supports it.

-Yaron

On Mon, Jun 11, 2018 at 1:23 PM Yaron Koren  wrote:

> Hi,
>
> Moriel Schottlender  wrote:
> > This isn't a personal attack, it's a consequence to your earlier email.
> >
> > You stated yourself, that one of the reasons you don't think a COC.md
> file
> >  should exist in your repository is because not all interactions are
> covered
> >  by it. While that might be true technically-speaking, it does make a
> >  statement to potential contributors about what they might expect in
> terms
> >  of feeling safe and secure with a CoC in place.
> >
> >  For those of us who "bad interaction online" are a norm rather than an
> edge
> >  case, a statement that the CoC is not fully covering a space means we
> don't
> >  go to that space if we can help it.
> >
> >  Saying that one does not intend on touching a space where the
> maintainer
> >  clearly stated the CoC is only partially in effect is not a personal
> attack
> >  -- it's a consequence of what you said.
> >  A consequence that is also shared by others who may feel less
> comfortable
> >  speaking up on public threads, but would avoid going into such spaces
> all
> >  the same. Not because of who you are personally, but because of what
> your
> >  statement about how your space is governed means.
> >
> >  Whatever other claims and discussion is going on in this and the other
> >  thread, let's not try to make it sound like there's a personal attack
> going
> >  on here.
>
> No, I still think it's a personal attack. I think we've already
> established that the CoC does not cover all interactions, and that the
> CoC.md file is thus giving false information. Some people have stated that
> clearly, some have grudgingly admitted it, but no one has really argued
> against it. Even you note that it's "technically" true, whatever exactly
> that means.
>
> And of course, this file was put in place by a few developers - it wasn't
> an opt-in choice. (It's still not 100% clear that it's even an "opt-out"
> choice, though at this point it seems to be.)
>
> Given those two things, the presence of a CoC.md file in an extension
> directory tells a potential contributor nothing - nothing about additional
> security they're getting, and nothing really about the extension's
> developers. Actually, it's worse than nothing, because it gives potential
> contributors false comfort as far as the protections they'll have. If, as
> you say, some people face a real danger of harassment everywhere not
> covered by a code of conduct, then it's all the more reason to either
> remove that file, or reword it, everywhere - so people know what they're
> actually getting into.
>
> So, why should Amir want to avoid dealing with my code specifically? Is it
> because he would have fewer protections? Clearly, no. It must be something
> about me personally that would make him treat my code differently from
> everyone else's.
>
> -Yaron
>


-- 
WikiWorks · MediaWiki Consulting · http://wikiworks.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Escaping wikitext to JSON-valid string in templates

[Tom Schulze]

Hello everyone,

I am having trouble escaping and displaying wikitext in a way that is 
JSON-safe. I did some research but none of the provided 
MagicWords/ParserFUnctions/etc seem to be suited for this purpose. 
Please refer to my gitLab snippet  
to see the sample code of the query, template and widget.


My goal is to build up a structure like this using a widget (to load my 
custom JS), a cargo query and finally a template to display the items 
row by row:


Description
Description


The data is taken from a PageForms textarea form field (the user can 
enter any data she wants). This piece of HTML gets parsed by a custom 
Java Script on page load for further processing. As soon as characters 
like single (') or double quotes (") appear, the whole JSON string gets 
messed up and the JavaScript JSON parser throws errors. Even worse, the 
DOM structure becomes fragmented when single quotes appear. So 
client-side fixing w/ JavaScript is impossible/tedious.


Any solution is welcome, also restricting the types of characters used. 
Ideally, I would just need to wrap the parameter passed from the query 
to the template in some kind of Magic Word which escapes/strips out 
unwanted characters.


What options do I have ? I am open for different approaches...

Kind regards,

Tom

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

Re: [Wikitech-l] Gerrit as a shared community space

[Moriel Schottlender]

I'm not going to get into the minutia and details of how the code of
conduct is or isn't good to work in your repo, that's a separate discussion
that I won't participate in by choice right now.

I am simply pointing out that your own points made a declaration about how
working in the space you are in looks like.

In the gerrit commit that started this thing, you, yourself, publicly wrote
this:


*"The Site Settings extension uses a bunch of WMF tools and services for
its development, including hosting. If some random person sends me a patch
for Site Settings by email, and I email them back and say "Your code sucks,
you nitwit" (or worse), am I violating the Wikimedia Code of Conduct?"*
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/SiteSettings/+/437555/

This statement, the question itself, and the fact you are asking whether
this violates the CoC means, to me, and others who are unwilling to work in
a hostile environment, that you're unsure whether this is acceptable at all.
You might see this question as an innocent attempt to nitpick over the
specific details of whether by regulation something needs to happen.
I see it as a hint that you might **actually** think this is an acceptable
thing to do.
I don't know if you do. You might think it's not a bad response, but rather
a funny one. You might think it's acceptable because the original code
**was** stupid. I know people who think that, and that, for *their* spaces,
is valid.

But then I choose not to spend time in that space. That's valid too.
Which is why when Amir said he won't get near your code, he wasn't making a
personal attack. He was making a conclusion based on what you wrote about
the way your space operates.

That's not a personal attack no matter how much you try to shift the goal
post and talk about red herrings.
That's a consequence, and a reason of why the code of conduct was needed to
begin with.

You might accept this consequence as acceptable. That's your choice in your
space.
But don't throw that on others as if by making a conscious choice to avoid
spaces that have a danger of being toxic, they're personally attacking you.

Let's go back to the actual discussion at hand, instead.

Moriel

On Mon, Jun 11, 2018, 11:05 AM Yaron Koren  wrote:

> Hi,
>
> Moriel Schottlender  wrote:
> > Quite frankly, I don't blame people who regularly experience harassment
> > online to avoid spaces where the code of conduct is consciously only
> > enforced in parts of the space.
> > I, too, don't feel comfortable in joining that space, even for
> considering
> > potential interactions that I might encounter, and knowing that these
> > interactions, depending where they happen, may not be dealt with to my
> > personal ideal of what such space should be.
>
> Neither I nor any other extension developers are "enforcing" the code of
> conduct - that's up to a committee to do.
>
> > You stated that as far as you're concerned, there are interactions you
> > purposefully don't see as being governed by the CoC.
>
> I don't know what "purposefully" means there. There are interactions that
> are not governed by the CoC - how's that?
>
> > Some developers decide that they purposefully, in their repos, assume it
> > governs all interactions related to to work on the repo, and some,
> > apparently, do not.
>
> If anyone is "deciding" that, they're making an incorrect decision.
> Meaning, you can certainly say that you will not tolerate harassment,
> discrimination, etc. in personal emails as specified by the Wikimedia Code
> of Conduct - but as far as enforcement, you're on your own, unlike with the
> real CoC.
>
> Also, given that every extension had this file added in, how is a potential
> contributor to know who "decided" to embrace this file's statement and who
> didn't? Given the threat of harassment, it seems awfully risky to assume
> that everyone who didn't delete the file supports it.
>
> -Yaron
>
> On Mon, Jun 11, 2018 at 1:23 PM Yaron Koren  wrote:
>
> > Hi,
> >
> > Moriel Schottlender  wrote:
> > > This isn't a personal attack, it's a consequence to your earlier email.
> > >
> > > You stated yourself, that one of the reasons you don't think a COC.md
> > file
> > >  should exist in your repository is because not all interactions are
> > covered
> > >  by it. While that might be true technically-speaking, it does make a
> > >  statement to potential contributors about what they might expect in
> > terms
> > >  of feeling safe and secure with a CoC in place.
> > >
> > >  For those of us who "bad interaction online" are a norm rather than an
> > edge
> > >  case, a statement that the CoC is not fully covering a space means we
> > don't
> > >  go to that space if we can help it.
> > >
> > >  Saying that one does not intend on touching a space where the
> > maintainer
> > >  clearly stated the CoC is only partially in effect is not a personal
> > attack
> > >  -- it's a consequence of what you said.
> > >  A consequence that is also shared by others wh

Re: [Wikitech-l] Gerrit as a shared community space

[Moriel Schottlender]

Heh, an apology here, my autocorrect "fixed" your name, Yaron. I apologize
for that and should have caught it.
... The trouble of multilingual corrections.

Moriel

On Mon, Jun 11, 2018, 11:37 AM Moriel Schottlender <
mschottlen...@wikimedia.org> wrote:

> I'm not going to get into the minutia and details of how the code of
> conduct is or isn't good to work in your repo, that's a separate discussion
> that I won't participate in by choice right now.
>
> I am simply pointing out that your own points made a declaration about how
> working in the space you are in looks like.
>
> In the gerrit commit that started this thing, you, yourself, publicly
> wrote this:
>
>
> *"The Site Settings extension uses a bunch of WMF tools and services for
> its development, including hosting. If some random person sends me a patch
> for Site Settings by email, and I email them back and say "Your code sucks,
> you nitwit" (or worse), am I violating the Wikimedia Code of Conduct?"*
>
> https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/SiteSettings/+/437555/
>
> This statement, the question itself, and the fact you are asking whether
> this violates the CoC means, to me, and others who are unwilling to work in
> a hostile environment, that you're unsure whether this is acceptable at all.
> You might see this question as an innocent attempt to nitpick over the
> specific details of whether by regulation something needs to happen.
> I see it as a hint that you might **actually** think this is an acceptable
> thing to do.
> I don't know if you do. You might think it's not a bad response, but
> rather a funny one. You might think it's acceptable because the original
> code **was** stupid. I know people who think that, and that, for *their*
> spaces, is valid.
>
> But then I choose not to spend time in that space. That's valid too.
> Which is why when Amir said he won't get near your code, he wasn't making
> a personal attack. He was making a conclusion based on what you wrote about
> the way your space operates.
>
> That's not a personal attack no matter how much you try to shift the goal
> post and talk about red herrings.
> That's a consequence, and a reason of why the code of conduct was needed
> to begin with.
>
> You might accept this consequence as acceptable. That's your choice in
> your space.
> But don't throw that on others as if by making a conscious choice to avoid
> spaces that have a danger of being toxic, they're personally attacking you.
>
> Let's go back to the actual discussion at hand, instead.
>
> Moriel
>
>
> On Mon, Jun 11, 2018, 11:05 AM Yaron Koren  wrote:
>
>> Hi,
>>
>> Moriel Schottlender  wrote:
>> > Quite frankly, I don't blame people who regularly experience harassment
>> > online to avoid spaces where the code of conduct is consciously only
>> > enforced in parts of the space.
>> > I, too, don't feel comfortable in joining that space, even for
>> considering
>> > potential interactions that I might encounter, and knowing that these
>> > interactions, depending where they happen, may not be dealt with to my
>> > personal ideal of what such space should be.
>>
>> Neither I nor any other extension developers are "enforcing" the code of
>> conduct - that's up to a committee to do.
>>
>> > You stated that as far as you're concerned, there are interactions you
>> > purposefully don't see as being governed by the CoC.
>>
>> I don't know what "purposefully" means there. There are interactions that
>> are not governed by the CoC - how's that?
>>
>> > Some developers decide that they purposefully, in their repos, assume it
>> > governs all interactions related to to work on the repo, and some,
>> > apparently, do not.
>>
>> If anyone is "deciding" that, they're making an incorrect decision.
>> Meaning, you can certainly say that you will not tolerate harassment,
>> discrimination, etc. in personal emails as specified by the Wikimedia Code
>> of Conduct - but as far as enforcement, you're on your own, unlike with
>> the
>> real CoC.
>>
>> Also, given that every extension had this file added in, how is a
>> potential
>> contributor to know who "decided" to embrace this file's statement and who
>> didn't? Given the threat of harassment, it seems awfully risky to assume
>> that everyone who didn't delete the file supports it.
>>
>> -Yaron
>>
>> On Mon, Jun 11, 2018 at 1:23 PM Yaron Koren  wrote:
>>
>> > Hi,
>> >
>> > Moriel Schottlender  wrote:
>> > > This isn't a personal attack, it's a consequence to your earlier
>> email.
>> > >
>> > > You stated yourself, that one of the reasons you don't think a COC.md
>> > file
>> > >  should exist in your repository is because not all interactions are
>> > covered
>> > >  by it. While that might be true technically-speaking, it does make a
>> > >  statement to potential contributors about what they might expect in
>> > terms
>> > >  of feeling safe and secure with a CoC in place.
>> > >
>> > >  For those of us who "bad interaction online" are a norm rather than
>> an
>>

Re: [Wikitech-l] Gerrit as a shared community space

[Yaron Koren]

Moriel Schottlender  wrote:
> In the gerrit commit that started this thing, you, yourself, publicly
wrote
> this:
>
> *"The Site Settings extension uses a bunch of WMF tools and services for
> its development, including hosting. If some random person sends me a patch
> for Site Settings by email, and I email them back and say "Your code
sucks,
> you nitwit" (or worse), am I violating the Wikimedia Code of Conduct?"*
>
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/SiteSettings/+/437555/
>
> This statement, the question itself, and the fact you are asking whether
> this violates the CoC means, to me, and others who are unwilling to work
in
> a hostile environment, that you're unsure whether this is acceptable at
all.
> You might see this question as an innocent attempt to nitpick over the
> specific details of whether by regulation something needs to happen.
> I see it as a hint that you might **actually** think this is an acceptable
> thing to do.

I asked a straightforward, and relevant, hypothetical question - ultimately
that question is what this whole discussion is about. The fact that you're
using it as a "hint" that I like to harass people strikes me not as some
clever logic but as, yes, another personal attack. By my count, you're now
the fourth person in this discussion to attack me and my motivations
(though Brion apologized, so I consider that matter closed). It's
dispiriting, and I don't think you're doing your argument any favors by it.

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

[Wikitech-l] Discovery Weekly Update for the week starting 2018-06-04

[Chris Koerner]

Howdy,
Here's the weekly update from the Search Platform team.

As always, feedback and questions welcome.

== Discussions ==

=== Search ===
* After lots of talk about stemmers getting committed and plugins
getting deployed, the Slovak-language wikis have finally been
*reindexed*, and stemming [0] is now happening on the Slovak wikis!
[1]

=== Search—Time Machine Edition  ===
A few things from May that got missed:

* Trey wrote up some potential applications of natural language
processing (NLP) to on-wiki search [2]. We're still going through them
to pick out a couple that we'll turn into projects, probably next
quarter. Right now, spelling correction and entity extraction are high
on the list, but more questions, comments, and suggestions are
welcome.
* Erik pulled 90 days worth of regular expression (regex) searches
across all wikis, and Trey did a quick survey of the most common
patterns. [3] There are a lot more regex searches than we thought—5.6
million in 90 days!—and three apparently automated processes (bots,
apps, or tools of some kind) are responsible for more than 90% of the
regex searches.

[0] https://en.wikipedia.org/wiki/Stemming
[1] https://phabricator.wikimedia.org/T190815
[2] 
https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Potential_Applications_of_Natural_Language_Processing_to_On-Wiki_Search
[3] 
https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Survey_of_Regular_Expression_Searches
---

Subscribe to receive on-wiki (or opt-in email) notifications of the
Discovery weekly update.

https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly

The archive of all past updates can be found on MediaWiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

Interested in getting involved? See tasks marked as "Easy" or
"Volunteer needed" in Phabricator.

[1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R
[2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R

Yours,
Chris Koerner
Community Liaison
Wikimedia Foundation

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

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

[Pine W]

Hi Gergő,
I think that your proposal makes sense and would be good for the community to 
consider in an RfC.
Because this could involve complex wikilegal changes to how Wikimedia sites 
assign user permissions, and presently unforseen side effects, I think that the 
RfC should be translated into a variety of languages before it us opened, and 
that it should remain open for one month.
Thank you for requesting feedback early in the process of proposing this 
change, and for proceeding in a methodical and thoughtful way.


Pine
( https://meta.wikimedia.org/wiki/User:Pine )
 Original message From: Gergő Tisza  Date: 
6/11/18  4:58 AM  (GMT-08:00) To: Wikimedia developers 
 Subject: [Wikitech-l] Please comment on the 
draft consultation for splitting
the admin role 
Hi all,

per the discussion on Phabricator, I'd like to split the administrator
("sysop") user group into two parts - one which can edit sitewide CSS/JS,
and one which can not. You can find the details and detailed rationale in
the task:
https://phabricator.wikimedia.org/T190015

To inform the editor communities, and to make sure we can accommodate their
needs, I plan to run a community consultation; I'll probably kick it off on
Friday and have it run for two weeks. You can find the draft here:
https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_editing_sitewide_CSS/JS

I would appreciate if folks who are knowledgeable about the use of CSS/JS
editing and user rights management in various parts of the community could
look at it and add their concerns or suggestion to the talk page (or
Phabricator if that's more appropriate). Suggestions for a better group
name are especially welcome.

(As I wrote it in the FAQ on the consultation page, I think making sure
that MediaWiki is secure and at the same time empowers its users falls
under the authority of the developer community, and so the normal code
review process is appropriate for this change. Thus the consultation is not
intended to be an RfC or other discussion/veto type process. If you
disagree about the change in general, please discuss that on Phabricator,
or the linked Gerrit patches.)

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

Re: [Wikitech-l] Wikitech-l Digest, Vol 179, Issue 27

[kevin zhang]

Yaron,

By deciding to not allow the coc.md in your extension repositories at
gerrit, some people have publicly stated they won't contribute. You choose
a position, others have decided it's not worth the trouble. If you updated
your readme.md to be hostile, that is your own fault and would be advised
to remove such text. This is regardless of if the coc.md file is useful in
repositories. The coc does cover gerrit but as others have noted,  the
method of forcefully adding to hundreds of repositories without discussions
was horrible judgement. Now can we please move on from that? pretty sure
the +2 devs learned to not repeat this in future

Kevin

On Mon, Jun 11, 2018, 2:55 PM 
wrote:

> Send Wikitech-l mailing list submissions to
> wikitech-l@lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> or, via email, send a message with subject or body 'help' to
> wikitech-l-requ...@lists.wikimedia.org
>
> You can reach the person managing the list at
> wikitech-l-ow...@lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wikitech-l digest..."
>
>
> Today's Topics:
>
>1. Re: Making PolyGerrit the default ui for gerrit (Paladox)
>2. Re: Gerrit as a shared community space (Yaron Koren)
>3. Escaping wikitext to JSON-valid string in templates (Tom Schulze)
>4. Re: Gerrit as a shared community space (Moriel Schottlender)
>5. Re: Gerrit as a shared community space (Moriel Schottlender)
>
>
> --
>
> Message: 1
> Date: Mon, 11 Jun 2018 17:55:59 + (UTC)
> From: Paladox 
> To: Wikimedia Developers 
> Subject: Re: [Wikitech-l] Making PolyGerrit the default ui for gerrit
> Message-ID: <1404388831.6108064.1528739759...@mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
>  The date to switch the default ui is next monday (18/06/18) which will
> give users plenty of time to give there opinion.
> Users can still switch back to the old ui just the new ui is secure.
> https://phabricator.wikimedia.org/T196812#4273184
>
>
>
>
> On Monday, 11 June 2018, 13:38:20 BST, Paladox <
> thomasmulhall...@yahoo.com> wrote:
>
>  Hi, i have created this task [1] with i have uploaded this patch [2] to
> make polygerrit the default ui.
> The reason why is upstream are preparing to remove the gwtui very soon. In
> matter of fact upstream have disabled the gwtui on *.googlesource.com.
> Upstream already have this change [3] to remove the ui. Making PolyGerrit
> the default ui will get new users use to the new ui.
> GWTUI will still be available with ui switcher in the footer or you can
> append the url like https://gerrit.wikimedia.org/r/?polygerrit=0
>
> PolyGerrit is stable, secure and also fast. It also has features that you
> cannot see in gwtui like user status, naming your patchiest (description),
> cc feature and also being able to tell who added you as a reviewer.
> This email is advanced notice before we change the default ui.
> any bugs todo with polygerrit / gerrit can be filled at
> https://phabricator.wikimedia.org/project/view/330/ and we can forward it
> upstream.
>
>
> [1] https://phabricator.wikimedia.org/T196812
> [2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/439444
> [3] https://gerrit-review.googlesource.com/c/gerrit/+/116790
>
>
>
>
> --
>
> Message: 2
> Date: Mon, 11 Jun 2018 14:05:11 -0400
> From: Yaron Koren 
> To: Wikimedia developers 
> Subject: Re: [Wikitech-l] Gerrit as a shared community space
> Message-ID:
>  khjvgrbbdpb...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> Moriel Schottlender  wrote:
> > Quite frankly, I don't blame people who regularly experience harassment
> > online to avoid spaces where the code of conduct is consciously only
> > enforced in parts of the space.
> > I, too, don't feel comfortable in joining that space, even for
> considering
> > potential interactions that I might encounter, and knowing that these
> > interactions, depending where they happen, may not be dealt with to my
> > personal ideal of what such space should be.
>
> Neither I nor any other extension developers are "enforcing" the code of
> conduct - that's up to a committee to do.
>
> > You stated that as far as you're concerned, there are interactions you
> > purposefully don't see as being governed by the CoC.
>
> I don't know what "purposefully" means there. There are interactions that
> are not governed by the CoC - how's that?
>
> > Some developers decide that they purposefully, in their repos, assume it
> > governs all interactions related to to work on the repo, and some,
> > apparently, do not.
>
> If anyone is "deciding" that, they're making an incorrect decision.
> Meaning, you can certainly say that you will not tolerate harassment,
> discrimination, etc. in persona

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

[Pine W]

Apologies for the typos. Speaking of being thoughtful, perhaps I should be more 
careful when typing on mobile devices.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
 Original message From: Pine W  Date: 
6/11/18  1:42 PM  (GMT-08:00) To: Wikimedia developers 
 Subject: Re: [Wikitech-l] Please comment on 
the draft consultation for splitting
the admin role 
Hi Gergő,
I think that your proposal makes sense and would be good for the community to 
consider in an RfC.
Because this could involve complex wikilegal changes to how Wikimedia sites 
assign user permissions, and presently unforseen side effects, I think that the 
RfC should be translated into a variety of languages before it us opened, and 
that it should remain open for one month.
Thank you for requesting feedback early in the process of proposing this 
change, and for proceeding in a methodical and thoughtful way.


Pine
( https://meta.wikimedia.org/wiki/User:Pine )
 Original message From: Gergő Tisza  Date: 
6/11/18  4:58 AM  (GMT-08:00) To: Wikimedia developers 
 Subject: [Wikitech-l] Please comment on the 
draft consultation for splitting
the admin role 
Hi all,

per the discussion on Phabricator, I'd like to split the administrator
("sysop") user group into two parts - one which can edit sitewide CSS/JS,
and one which can not. You can find the details and detailed rationale in
the task:
https://phabricator.wikimedia.org/T190015

To inform the editor communities, and to make sure we can accommodate their
needs, I plan to run a community consultation; I'll probably kick it off on
Friday and have it run for two weeks. You can find the draft here:
https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_editing_sitewide_CSS/JS

I would appreciate if folks who are knowledgeable about the use of CSS/JS
editing and user rights management in various parts of the community could
look at it and add their concerns or suggestion to the talk page (or
Phabricator if that's more appropriate). Suggestions for a better group
name are especially welcome.

(As I wrote it in the FAQ on the consultation page, I think making sure
that MediaWiki is secure and at the same time empowers its users falls
under the authority of the developer community, and so the normal code
review process is appropriate for this change. Thus the consultation is not
intended to be an RfC or other discussion/veto type process. If you
disagree about the change in general, please discuss that on Phabricator,
or the linked Gerrit patches.)

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

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

[Gergo Tisza]

On Mon, Jun 11, 2018 at 6:02 PM Steven Walling 
wrote:

> I'm definitely supportive of greater security for sitewide JS/CSS, but
> Bart's proposal is an interesting one. (Sorry for top posting, on mobile)
>
> What if we required review of edits to JS/CSS in the MediaWiki namespace
> (not in other namespaces), ala pending changes or something similar? We
> require code review in Gerrit, so why not sitewide code in the wiki?
>
> I propose this because if we split code editing rights into a separate
> userright, this entails increased process bloat for managing who and who
> doesn't get the right, the criteria for deciding that, and so on. Requiring
> code review would allow for more flexibility while increasing security. It
> would require less process bloat too because the community already has
> mechanisms for requesting edits be confirmed via talk pages and such.
>

That's a good way to improve security, but orthogonal to separating
permissions (it would probably mean that an attacker would have to find two
vulnerable accounts, while this change will reduce the pool of accounts an
attacker could target; both make attacks harder, in different ways). No
reason not to do both, but separating permissions is (relatively) easy and
a review system is more like something on the scale of FlaggedRevs.

If you are interested, https://phabricator.wikimedia.org/T71445 has plenty
of discussion on code review for gadgets;
https://phabricator.wikimedia.org/T187749 is a variant of it I'm working on.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Pine W]

I tend to agree with Steven's comments. I think that requiring review would, as 
he said, be less costly to implement in terms of the amount of volunteer time 
spent on managing permissions. I think that there would also be less time spent 
discussing and redesigning social processes than there would be if the existing 
admin permissions are split and communities must decide who should get which 
level of admin permissions.
In terms of engineering time, implementing a review process might be more 
costly, but given the significantly lower cost of social implementation to 
volunteers, I think that this option would be my first choice in the short 
term. 


Pine
( https://meta.wikimedia.org/wiki/User:Pine )
 Original message From: Gergo Tisza  
Date: 6/11/18  3:11 PM  (GMT-08:00) To: Wikimedia developers 
 Subject: Re: [Wikitech-l] Please comment on 
the draft consultation for
  splitting the admin role 
On Mon, Jun 11, 2018 at 6:02 PM Steven Walling 
wrote:

> I'm definitely supportive of greater security for sitewide JS/CSS, but
> Bart's proposal is an interesting one. (Sorry for top posting, on mobile)
>
> What if we required review of edits to JS/CSS in the MediaWiki namespace
> (not in other namespaces), ala pending changes or something similar? We
> require code review in Gerrit, so why not sitewide code in the wiki?
>
> I propose this because if we split code editing rights into a separate
> userright, this entails increased process bloat for managing who and who
> doesn't get the right, the criteria for deciding that, and so on. Requiring
> code review would allow for more flexibility while increasing security. It
> would require less process bloat too because the community already has
> mechanisms for requesting edits be confirmed via talk pages and such.
>

That's a good way to improve security, but orthogonal to separating
permissions (it would probably mean that an attacker would have to find two
vulnerable accounts, while this change will reduce the pool of accounts an
attacker could target; both make attacks harder, in different ways). No
reason not to do both, but separating permissions is (relatively) easy and
a review system is more like something on the scale of FlaggedRevs.

If you are interested, https://phabricator.wikimedia.org/T71445 has plenty
of discussion on code review for gadgets;
https://phabricator.wikimedia.org/T187749 is a variant of it I'm working on.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Nathan]

Is the risk of an attacker taking over an account with CSS/JS edit
permissions any more or less because that person knows how to use CSS/JS?
If the criteria will be that only people who know how to use CSS/JS will
get access to make those edits, I'm not sure that is perfectly tailored to
the need being identified - security from outside threats. Can we make the
edit right temporary, so someone can request it through a normal simple
process, execute their edits, and then relinquish it? It can be a right
that admins could grant to each other, as long as they can't gift it to
themselves.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Pine W]

On Mon, Jun 11, 2018 at 6:26 PM, Nathan  wrote:

> Is the risk of an attacker taking over an account with CSS/JS edit
> permissions any more or less because that person knows how to use CSS/JS?
> If the criteria will be that only people who know how to use CSS/JS will
> get access to make those edits, I'm not sure that is perfectly tailored to
> the need being identified - security from outside threats.



That's a good point that I hadn't considered, and that I think further
supports the approach that Steven advocated instead of the approach of
developing a new user permission.




> Can we make the
> edit right temporary, so someone can request it through a normal simple
> process, execute their edits, and then relinquish it? It can be a right
> that admins could grant to each other, as long as they can't gift it to
> themselves.
>


I think that a per-edit review would be preferable, so that someone can't
request what they say will be benevolent edits and then do something
malicious before anyone else has enough time to review all of the changes
that they made.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Federico Leva (Nemo)]

Personally I'd like us to explore agnostic and non-invasive solutions.

The subdivision of permissions across more user groups relies on a 
number of assumptions which may not hold. For instance, on thousands of 
MediaWiki wikis there's only one sysop anyway.


Something I would like is the ability to "have" a permission, but only 
"activate" it for limited periods of time when needed. The activation 
could require some extra steps (e.g. inserting the password again). It 
could be logged to Special:Log, which people can then monitor as they 
wish. A separate countermeasure (other than deflag) could inhibit it.


Granular permissions are tricky on MediaWiki, but we might come up with 
simple implementations. Maybe, set a rate limit to 0 and add a special 
page to temporarily increase it for yourself (or others). Something like 
that.


Federico

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