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

Created on 21 March 2012, almost 13 years ago
Updated 17 August 2023, over 1 year ago

One of the problems with the support options on drupal.org issue http://drupal.org/node/1236290 was that there was an impression that Dries needed to be the decision maker on this issue, this was expressed by killes, webchick, and others. Once two potential options were narrowed down (StackExchange or improve support options on d.o.) it then came down to who would make a decision on that. Eventually, Angie made it clear that people involved in the forums were the ones that needed to weigh in to make a decision. Eventually, they weighed in, but still no one closed the issue, perhaps believing that it was Angie or Dries (or chx who filed the issue) who were the only ones who had the authority to close it? However, Dries never even entered the issue.

I decided to step up and close the issue, because it seemed voices were heard and I wanted to move forward rather than let it languish for years, but was that really the right thing to do?

I think what would have helped here is to have had an explicit and easily findable document on d.o. (do we have something already? asides just maintainers.txt?) that explicitly states the roles and authority that we do currently dole out.

Here are a few examples that I can think of (could be wrong, feel free to correct)

Dries - Commit access to all Drupal core versions
Drupal maintainer (e.g., Angie) - Commit access to the version he or she maintains
Drupal.org webmasters (e.g., Drumm, killes) - Authority to kill spam, unpublish nodes, etc., somewhat explained here http://drupal.org/drupalorg-site-maintainers-guide
Drupal Association: Distribute money raised through Drupalcon, donations, etc. to Drupal projects
New contribuer/project application approvers - Ability to give a user git access to commit modules
Module maintainers - Commit access to their own projects
Authenticated user - Post/edit own nodes, comment, create git sandbox

I'm sure there is more than this, but the point is, document the authority that already exists (unless I'm just missing where this is already documented)

✨ Feature request
Status

Closed: outdated

Component

Policies

Created by

πŸ‡ΊπŸ‡ΈUnited States coderintherye

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    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'.

Production build 0.71.5 2024