Can/should my extensions be deleted from the Wikimedia Git repository?

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Can/should my extensions be deleted from the Wikimedia Git repository?

Antoine Musso-3
On 08/06/2018 15:26, Stephan Gambke wrote:
> Incidentally, what is the procedure to request removal of +2 rights for somebody on my extension repo?

Hello,

In Gerrit, the Mediawiki extensions all inherit rights from the
'mediawiki' group which has a lot of people:
https://gerrit.wikimedia.org/r/admin/groups/4cdcb3a1ef2e19d73bc9a97f1d0f109d2e0209cd,members

When we debated Gerrit user rights, the agreement was to have all those
people to act as maintainers of all extensions. With the implicit
agreement to not mess around.

I think one of the benefit is you get functions updated magically, get
the latest linters/tests, translations etc.  So it is kind of a
maintenance service offered to any extension hosted on Gerrit.


For Wikimedia deployed extensions, SRE and Release Engineer require
those rights.

Surely for extensions that are actively maintained, the maintainers will
want to review all those changes. At least to be aware of them.  Though
when we do mass changes (update function calls, bump linters
version...), it is convenient to refer to the mediawiki group members
instead of hunting for the proper maintainer.


For the Lingo extension, it is owned by an empty group 'extension-Lingo':
https://gerrit.wikimedia.org/r/admin/groups/d47037083d4a819970a5dda6a95bd503c7897cfd

It still inherits rights mediawiki/extensions.git and thus inherits the
'mediawiki' group ownership.


--
Antoine Musso


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Can/should my extensions be deleted from the Wikimedia Git repository?

C. Scott Ananian
In reply to this post by Yaron Koren-2
On Fri, Jun 8, 2018 at 9:44 AM, Yaron Koren <[hidden email]> 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.
>

Let's not lose sight of Yaron's proposal for compromise here.  Having
slightly different wording here seems like it would be a win-win for
everyone: those who want to be sure new contributors get a pointer to the
CoC would be satisfied, and Yaron would be satisfied that he is not
misrepresenting the scope of the CoC in his own repositories.

It seems that other multi-homed repositories might have similar wording
tweaks.  A repo which takes pull requests via github, for example, might
have a CoC mentioning the applicability of github's CoC or WMF's CoC,
depending on circumstances.

I think there are a number of fascinating topics here, and it's probably
certainly worth documenting the costs/benefits of WMF hosting (eg implicit
+2 access by maintainers, which could be a con, but the pro side is that
you get translatewiki integration, library upgrades, and other maintenance
work done "for free") along with pointers so that new repo owners can
easily find out exactly who has maintainer rights to their repo and a short
history describing why that decision was made.  That documentation would
also be a good place for best practices such as README and CoC (as well as
clarifying the circumstances where the CoC is expected to apply).


> 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 good question. 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.  This is just my opinion --
I'm interested in hearing further discussion of these points --- but let's
not get distracted from considering (and hopefully accepting) Yaron's
compromise offer.
 --scott
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Can/should my extensions be deleted from the Wikimedia Git repository?

Bináris
Let me say I am very much surprised on this whole debate. We call these in
Hungary "storm in a glass of water".
Please step back all for a moment and try to look at the whole stuff from a
broader view.
We have a very first world problem, to write and discuss and enforce codes
of conduct, and advertise them everywhere. Have we?
The best code of conduct is still *"Behave normally",* or, as it was moved
to Meta from original place, *Don't be a jerk. *Everything is included.
Yes, we will still have problems of different cultures, and this is normal.
Those who cannnot accept that shouldn't participate in global projects. But
we can work it out.
This is the 43rd mail in this thread. To be honest, I have read only the
first few.

Is this whole thing WORTH the time of several highly trained programmers,
whose working hours are measured with gold?
Is this whole thing WORTH of forcing a volunteer, one of us, who is highly
committed to our common dream, to do something that he is not OK with or
quit?
Is life long enough for that?

Please study this essay on the topic thoroughly:
https://www.youtube.com/watch?v=Qyclqo_AV2M

Bináris
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Can/should my extensions be deleted from the Wikimedia Git repository?

Gergo Tisza
In reply to this post by Yaron Koren-2
On Fri, Jun 8, 2018 at 3:44 PM Yaron Koren <[hidden email]> 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) <[hidden email]>
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 <[hidden email]>
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 <[hidden email]> 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 general I think it's a good idea to let arguments with no
clear winner rest for a while before looking at them again, instead of
trying to force a resolution no matter the cost. Opinions evolve, cultural
trends shift, demographics change, people might gain more experience in the
topic that was discussed, the community's decisionmaking infrastructure
might improve; closing off a debate might became much cheaper with a little
patience. We are in this for the long run, as the Wikipedia people say.


On Fri, Jun 8, 2018 at 6:32 PM Brian Wolff <[hidden email]> wrote:

> Fwiw, I also had a discussion last night with someone who hasnt
> participated in this discussion as of yet but stated that incidents like
> this make them want to host their extensions elsewhere except they are not
> willing to pass up translatewiki integration-so the people not commenting
> objection goes both ways


On Fri, Jun 8, 2018 at 3:26 PM Stephan Gambke <[hidden email]>
wrote:

> It is a pity that there is even a need for a CoC, but I am more than happy
> to have one if it helps to make people feel more comfortable. But
> insinuating that not wanting that file in each and every repo would imply
> disagreement with the code itself is not only insulting, it has a chilling
> effect on the communication here.
>

Thanks both for bringing that up. It is important to acknowledge that
people on every side of this debate might feel stressed or threatened, and
do what we can to minimize that. Extrapolating from comments to presumed
views about the code of conduct is something I should try harder to avoid;
I apologize.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Can/should my extensions be deleted from the Wikimedia Git repository?

Yaron Koren-2
In reply to this post by Yaron Koren-2
Gergo Tisza <gtisza at wikimedia.org> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Can/should my extensions be deleted from the Wikimedia Git repository?

Chad
In reply to this post by MZMcBride-2
On Fri, Jun 8, 2018 at 12:19 AM MZMcBride <[hidden email]> wrote:

> Yaron Koren wrote:
> >That's how it went until two days ago, when Antoine Musso submitted a
> >patch for my Site Settings extension (I don't know why that one
> >specifically), re-adding the file. I rejected the patch, on the same
> >grounds as before, but another developer, Chad Horohoe, overrode me and
> >merged it in. That led to a discussion featuring Antoine, Chad, a few
> >other WMF developers, and me, which you can find here:
> >
> >https://gerrit.wikimedia.org/r/#/c/437555/
> >
> >Some of the (unbelievable) highlights:
> >
> >- From Antoine: "Well then can we just archive this repository please?"
> >
> >- From Chad: "Yeah no that's not how it works. If it's being hosted on
> >gerrit.wikimedia.org, it needs a CoC file. If you object to that, you can
> >find hosting elsewhere."
>
> It was really inappropriate for Chad to hastily and forcefully merge this
> change.
>
>
Probably. I was in a pretty crappy mood and I went "not again" and
merged it. I don't actually care one way or the other if repos have the
file (nb: I support the CoC), but I just want to be **consistent**

If we're gonna have them: have them everywhere. If not, then we
should be removing them everywhere.

-Chad
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Can/should my extensions be deleted from the Wikimedia Git repository?

Chad
In reply to this post by Alex Monk
On Fri, Jun 8, 2018 at 7:02 AM Alex Monk <[hidden email]> wrote:

> I think Gerrit admin permissions were abused to remove the review
>
>
https://gerrit.wikimedia.org/r/Documentation/access-control.html#category_remove_reviewer

Anyone who is a project owner on mediawiki/* could have done it, it had
nothing
to do with admin permissions. But that's not the point of this thread at
all...

-Chad
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123