Explicitly document the privileged roles currently available on drupal.org, especially Dries & current Drupal maintainer's role

Not quite right...

"(e.g., Drumm, killes)" <-- They are more than maintainers. They are admins as far as roles go plus have super powers beyond the website as well.

On drupal.org, there are admins that have tons of powers, user admins that can bock people but not change roles or edit passwords, site maintainers that have full control with content but cannot ban people, doc maintainers which was privileged to add images but that isn't an issue anymore and the role may not exist, maintainers, and authenticated users.

I don't have access to roles (I'm a user admin, not full admin) so I likely don't have the names quite right but that's the general idea.

Beyond the user roles on drupal.org, there are some people who have server access or other really high level access that can affect beyond just the website.

Somewhere there is a list of site maintainers by name. I'm not sure where it is anymore, though, so you'd need to search. I don't know that roles are documented beyond that... There is a graphic for the uber admins that has shown up here at Drupalcon and is likely online somewhere. Webchick might know. I'm pretty sure it was her session I saw it.

Michelle

Hmm... I didn't change the component. Don't know why it did that and it won't let me change it back.

@Michelle infra team diagram is here: http://drupal.org/node/1206660 if you meant this graphic.

Yep, that's it!

+1 to explicity display roles with their missions and users in a wiki handbook

Edit: I am thinking that it would be far easier (And always up-to-date) to build a view with all this data. We could display all users belonging to a certain role, and group them accordingly, displaying a description per each role.

@coderintherye, if you're willing to create the page, I think you probably have nearly enough to do it.

There is more here than just the technical "roles" on d.o, of course.

We have Drupal roles:

• User 1 (Dries) can technically do anything, but limits himself by appropriateness
• Site Maintainer (essentially full admin privs)
• User Administrator (can delete users, etc.)

and a few others:

However, the role does *not* imply that someone is authorized to perform any action they have privileges to do. For example, as a User Administrator, I have the privilege to delete your account, but the privilege wouldn't have been granted to me if it weren't obvious that I wouldn't do that.

However, we have many more privileges:

• Commit privs, both core and contrib, that have specific policy constraints (what branch can be committed to, what type of patch can be committed)
• Infrastructure privileges (ssh to various hosts, sudo on various hosts, access to the database). Again, here I have the ability to access the d.o database, which means I could delete Dries account, but I wouldn't have that priv if it were likely.

I think that a page exploring what privileges are out there and how people get them is worth working on. (If you need a privilege to accomplish something, and have cred that supports that in the community, you normally get it just by asking in the issue queue. Lots of examples here in the infra queue. Normally, though, you have to ask *and* then pester.)

If you would like to explore a copy of d.o, I can give you access to a sandbox with admin privileges.

The reality is, you may be requesting,

"How are privileges and policies determined in the Drupal community".

And, of course, that's the initiative we're working on here. But it goes far and wide. To insiders, the things I said above are somewhat self-evident:

If you need a privilege to accomplish something, and have cred that supports that in the community, you normally get it just by asking in the issue queue. Lots of examples here in the infra queue. Normally, though, you have to ask *and* then pester.

However, that statement doesn't explain many, many policies that are "on the books" but not written down. And it doesn't explain some behaviors in the community that are undertaken without policy backing.

1. What do we do about spammers? Easy: Block them and delete their content. This is a web-wide response. There are a few gray areas, but we encounter them rarely.
2. What do we do about trolls? We've had an uneven and sometimes unpredictable response here. Normally, an issue about a warning is opened and discussed, and there's an escalation procedure. But I don't think anything is written down or that we have a clear path. But maybe I'm not paying attention.
3. What do we do about contrib security problems? The security team has very clear and predictable procedures, which they execute well. However, I'm not sure that their procedures are always fully understood by the community. The team page, for example, does not seem to say what happens when a contrib author does not respond appropriately to a security issue, and this is a regular occurrence.
4. What do we do about d.o pages with inappropriate or incorrect content, or where there's a difference of opinion?

All these things have lots of work and perhaps adequate consensus behind them, but in many cases only insiders know what the consensus is. IMO they should be stated as policies, but the policies should be easy to change. I don't think we lose anything by writing them down, and it gives people a sense that there is in fact some rationale behind community actions.

I've been a site maintainer for a very long time and a user administrator since the role was created in response to my plea to be able to block spammers. :) So I have a pretty good idea of a lot of things in this area but, still, I find myself now and then unsure what to do about something. I really like the idea of having this clearly documented. We do need to be careful to not end up with something inflexible where we constantly have to add new things to cover every last little possibility but general guidelines are great.

#1: Yup, that's definitely easy. Block spammers; delete content. But, the harder question: what is a spammer? That's not facetious. If they're hawking Viagra, it's a no-brainer. What if they're hawking Drupal e-books? If someone has a Drupal offering and they are excited to share it with the community and go a bit overboard in the forum, are they a spammer? In my opinion, no. But this is something that we need clear documentation on because other people would say yes.

#2: We are really terrible about our response to trolls. Basically, they are tolerated until someone with the power gets fed up with them and blocks them. And then that blocking may or may not be overturned depending on the troll's standing in the community, how persuasive they are, and what others in power (if any care enough to get involved) think about it. Someone who is an active contributor can get away with being very nasty where a new person may be banned right away. This needs guidelines but, honestly, writing guidelines on this could be painful. Defining trolling vs just being a bit cranky, defining whether it matters if you're a contributor... Ugh... Very very messy.

#3: I think the security team does a wonderful job but, yeah, it can be unclear to outsiders. I think more documentation is great as long as we can do it without putting more burden on them. :)

Sorry if this is rambly... I'm short on time so it's pretty much a brain dump and I'm not going back to clarify/tighten.

#4: What usually tends to happen is it gets unpublished and an issue filed. What happens after that depends on if anyone cares enough to protest. I've come across very old issues when cleaning up the queue where things are unpublished and nothing more was ever done. As a first step, I think a good policy with questionable content would be to unpublish it, file an issue, and then contact the author to point them to the issue and invite them to explain why the content is there and why it should be kept. If it stalemates, then that's where that conflict resolution team that's being worked on steps in. :)

A huge +1 on this. This is a necessary first step to creating real governance for the Drupal community. It is also a critical step for fixing and reinforcing good power structures in our community. That graphic is ok, but it only touches the surface on what is the real structure.

+1 to including non-technically-assigned roles as well, i.e. core initiative leads, documentation lead, etc.

Also, if we are really trying to define governance with this sort of thing, it needs to be explicit (or noted that it is not explicit) on how people are assigned these roles, the length of time of having these role, what are the responsibilities of these roles, and how to remove someone from the role. These are all very much just in the collective knowledge of the community and cannot be documented with a view.

The Governance project is responsible for the documentation I think that is being looked for here. It has descriptions for the roles and explains the decision making practice used. Looking at the dates, that project was created on the same day as this issue. Perhaps everyone here found it and the information?

Since there hasn't been further requests here and the governance documentation is available I am marking this 'outdated'.