Page MenuHomePhabricator

Deal with project creation violation
Closed, ResolvedPublic

Description

I noticed that #acl*releng has been created, but I have not been able to find a ticket allowing it. This should be be emptied and archived until the proper process has been followed.

Event Timeline

Krenair created this task.Nov 8 2015, 2:38 AM
Krenair raised the priority of this task from to Needs Triage.
Krenair updated the task description. (Show Details)
Krenair added subscribers: Krenair, demon, greg, Aklapper.
Restricted Application added subscribers: StudiesWorld, scfc. · View Herald TranscriptNov 8 2015, 2:38 AM
demon added a comment.Nov 8 2015, 4:11 PM

I noticed that acl*releng has been created, but I have not been able to find a ticket allowing it.

Whoops!

This should be be emptied and archived until the proper process has been followed.

Nah, that'd be silly :)

This should be be emptied and archived until the proper process has been followed.

Nah, that'd be silly :)

No, we need a way to shut down projects that are wrongly created and archiving+emptying is probably as close as we're going to get in phabricator.

greg added a comment.Nov 8 2015, 4:52 PM

Why? If there is damage done, sure, but in this case no damage was done. It was simply not recorded but followed all other guidelines. Why are you singling out this one when there are many others?

I'd appreciate some good faith here.

Why? If there is damage done, sure, but in this case no damage was done.

No damage being done does not been you get to ignore the process. You need a very, very good reason to start restricting things in Wikimedia.

It was simply not recorded but followed all other guidelines.

It's not a case of recording, you have to propose the project, it is discussed, and only then may it be created.

Why are you singling out this one when there are many others?

What others? I will open tickets to shut down every other tag/ACL project created outside the process if need be (and note the ones that should've been documented in the log task). This one was caught because I've started keeping a closer eye on project creations.

This should be be emptied and archived until the proper process has been followed.

Nope. Instead you could talk to people, assume they mean well, and help them making it better. "Emptying and archiving" is one potential outcome after such a conversation. Doing that before having a conversation is just throwing stop energy at a vaguely defined problem.

Aklapper closed this task as Resolved.Nov 9 2015, 7:05 AM
Aklapper claimed this task.

Specific case is being dealt with in T118125.
In general, I do check weekly for project creations+changes and their edit/join policies, and contact project creators who might not have fully followed the guidelines, in order to sort out issues. To me that's "dealing with it", hence closing this task as "resolved" as this happens regularly.

Krenair reopened this task as Open.Nov 9 2015, 5:57 PM

This should be be emptied and archived until the proper process has been followed.

Nope. Instead you could talk to people, assume they mean well, and help them making it better. "Emptying and archiving" is one potential outcome after such a conversation. Doing that before having a conversation is just throwing stop energy at a vaguely defined problem.

We should be reverting first. Is that not the closest that Phabricator will allow us to get to actually effectively reverting project creations?

Specific case is being dealt with in T118125.

No, it's not.

In general, I do check weekly for project creations+changes and their edit/join policies, and contact project creators who might not have fully followed the guidelines, in order to sort out issues. To me that's "dealing with it", hence closing this task as "resolved" as this happens regularly.

This one hasn't been resolved, and you should not have marked it as such.

demon added a comment.Nov 9 2015, 6:12 PM

Ok then what still needs discussing?

Aklapper reassigned this task from Aklapper to Krenair.Nov 10 2015, 7:17 AM

@Krenair: I honestly don't understand this at all. Why not just allow people to create them, what's the big deal?

greg added a comment.Nov 11 2015, 12:19 AM

If I might be so brave (or foolish) I *think* the crux of the issue for this specific case is "You need a very, very good reason to start restricting things in Wikimedia." Is that correct, Krenair?

@greg: The funny thing is, I don't see the very good reason to restrict project creation. IMO it wouldn't be horrible if project creation was a free-for-all, or very nearly so.

greg added a comment.Nov 11 2015, 5:18 AM

I think the restriction he was referring to was the use of the acl* group. Of course, now I'm playing interpreter :)

Krenair reassigned this task from Krenair to Aklapper.Nov 11 2015, 2:45 PM

Ok then what still needs discussing?

Whether this project being created makes sense and is acceptable. I haven't seen a good reason for anything to be restricted to releng yet.

@greg: The funny thing is, I don't see the very good reason to restrict project creation. IMO it wouldn't be horrible if project creation was a free-for-all, or very nearly so.

That's a terrible idea.

mmodell added a comment.EditedNov 11 2015, 3:52 PM

@greg: I get that, but I counter that restricting project creation is as just as bad.
Though a case could probably be made for restricting acl* projects, restricting project creation in general seems very unfree and mean-spirited to me.

@Krenair: Release-Engineering-Team have a very justified need to restrict write-access to some things, like repositories, build plans, etc. This doesn't mean we would be hiding anything from anyone, it simply ensures the security of the code we release and the integrity of the CI infrastructure. Although not as free-and-anonymous as editing wikipedia, these restrictions are totally in line with existing practices in gerrit and jenkins. I wholeheartedly support unrestricted access to most things, and I will generally be the last one to suggest restricting anything, however, in this case I'm pretty sure it's completely reasonable.

Krenair reassigned this task from Aklapper to mmodell.EditedNov 11 2015, 3:57 PM

@greg: I get that, but I counter that restricting project creation is as just as bad.
Though a case could probably be made for restricting acl* projects, restricting project creation in general seems very unfree and mean-spirited to me.

ACL projects and tags are the only types of projects that you need to propose beforehand. Other types can be created by anyone with the permission (which the administrators give out quite liberally, and some groups can self-grant), some of which require you to document the creation afterwards and some do not. We already have people who *have requested and received this permission* yet *still* haven't read the project creation guidelines (or perhaps have read them and decided to ignore them), I'd prefer it not be opened up further.

Release-Engineering-Team have a very justified need to restrict write-access to some things, like repositories, build plans, etc. This doesn't mean we would be hiding anything from anyone, it simply ensures the security of the code we release and the integrity of the CI infrastructure.

That sounds fair enough, but I'm confused about why it took so long to get to this answer. It should've been the first thing said, before anyone even thought about creating the project.

Krenair closed this task as Resolved.Nov 11 2015, 3:57 PM

We already have people who *have requested and received this permission* yet *still* haven't read the project creation guidelines (or perhaps have read them and decided to ignore them)

...while I have the impression that most people have read them but forgot half of it because info on that page is scattered all over.
I'd welcome your feedback on T118304 (which is an attempt to describe the status quo in a hopefully less error-prone way).

Restricted Application added a subscriber: Luke081515. · View Herald TranscriptJan 13 2016, 9:38 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 20 2016, 10:13 PM