Drupal.org Governance: Step 1: Structuring the webmasters queue or who is doing what?

July this year first ever Drupal Governance Sprint took place. Drupal.org was among the topics discussed. There were some ideas on how to ensure that site maintenance goes smooth, policies are in place, user’s issues are being answered and experience in the queue is consistent for the users. While implementing those ideas should have positive effect on Drupal.org maintenance, that process will take quite some time. And we don’t necessarily need to wait. We can start discussing existing problems and self-organizing right now. This will also make governance project go much easier and faster once it moves to Drupal.org.

I want to start discussion on Drupal.org governance with one huge and important part of the Drupal.org which is webmasters queue.

Current situation

  • For the past months the webmasters queue persistently has had over 1000 issues open at any given time.
  • While our webmasters do a lot, answer lot’s of issues, overall this queue has rather inconsistent nature (not an active structured team effort).
  • There are currently 158 people with “site maintainer” and “administrator” permissions, but most of them are really busy with other projects, they maintain contrib modules, contribute to core etc.
  • We don’t have a clear process of how one can become part of the team, apart from rather vague “start doing something and maybe someone will notice and promote you”.
  • People who do have permissions to do things often are not sure if they are supposed to do something in specific case and what exactly they need to do.
  • Webmasters are not really a team now, but a number of people with permissions. There are no clear “leader” or roles, responsible for specific tasks.
  • There is no clear way of how to reach this people: no dedicated irc channel, no g.d.o group, issue queue is too huge, mailing list is not really used much.

The site is growing, new and new sections being added, which require maintenance. The current situation is not sustainable anymore.

We have examples of Security and Infrastructure teams with clear structure, roles, ways you can reach them. While not saying they are ideal and not copying them we can at least do small steps in order to bring more organization to Webmasters team.

First and obvious step would be to define “owners” of different parts of webmasters issue queue. Some parts have 1-2 active people, constantly working on them. Others - don’t. Documenting this will help us see who is doing what and where we have gaps.

In order to do this I’ve opened an issue. The summary lists various parts of webmasters queue and people responsible for them. If you are a webmaster and want to commit to specific part of the issue queue - please add your name.

I suggest a 2 week timeframe for all interested individuals to comment on that issue and choose which part of the queue they want to commit to. In 2 weeks we’ll see the team we have currently and where we have gaps.

Documenting current contributors and their specific roles will be the first step. Once this is done, we can move further: building teams and improving processes around those people to ensure webmasters queue is active and efficient.

-----
Thanks to greggles and silverwing for feedback and help with the post.

Comments

> People who do have permissions to do things often are not sure if they are supposed to do something in specific case and what exactly they need to do

This can be due to policy discussions by the community that never finish (planet) or features of the site that go live without the entire webmaster team being involved (api.drupal.org, the marketplace).

In addition to what Heine said which is a very real problem, there also appears to be an issue with inconsistent permissions. For example, I have no way to do anything on api.drupal.org, GIT, or users beyond blocking/unblocking. I'm sure I'm not the only one. So once roles are defined for components, permissions should probably be reviewed as well to make sure webmasters can address the components appropriately.