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.
Description
Description
Related Objects
Related Objects
- Mentioned In
- T118304: Make Phabricator "Creating and renaming projects" documentation page less confusing for people who want to have a project
T118125: Create #acl*releng - Mentioned Here
- T118304: Make Phabricator "Creating and renaming projects" documentation page less confusing for people who want to have a project
T118125: Create #acl*releng
Event Timeline
Comment Actions
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 :)
Comment Actions
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.
Comment Actions
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.
Comment Actions
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's not a case of recording, you have to propose the project, it is discussed, and only then may it be created.
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
We should be reverting first. Is that not the closest that Phabricator will allow us to get to actually effectively reverting project creations?
No, it's not.
This one hasn't been resolved, and you should not have marked it as such.
Comment Actions
@Krenair: I honestly don't understand this at all. Why not just allow people to create them, what's the big deal?
Comment Actions
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?
Comment Actions
@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.
Comment Actions
I think the restriction he was referring to was the use of the acl* group. Of course, now I'm playing interpreter :)
Comment Actions
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.
That's a terrible idea.
Comment Actions
@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.
Comment Actions
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.
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.
Comment Actions
...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).