Community Tools Leadership Team [PROPOSAL - V2]

This document is the second revision of the proposal, based on feedback from the discussion which began at https://groups.drupal.org/node/400478. It is still a draft. We expect to refine it in conjunction with the people actually filling the roles before finalizing their appointment.

Overview

The Drupal.org Software Working Group (drumm, eliza411, tvn, webchick) was chartered to provide vision and direction for Drupal.org by working with the community on Drupal.org software in a number of ways. The first duty on our list is establishing team leadership.

From the charter:
(DSWG) Creates and removes teams for each major area of the Drupal.org websites, which have authority to make software and feature decisions within their scope. The DSWG defines and appoints the leadership roles within each team, such as a technical lead, product owner, QA lead, etc.
Full charter: https://drupal.org/node/1929526

Community Tools Scope

Proposed scope of functionality for the Community Tools Team includes:

• Forums
• Planet
• User profiles
• User Dashboard
• User groups (groups.drupal.org)

We feel that, outside of the issue queue, these are the sections of the site where community interaction happens. Therefore it makes sense to group them under one leadership team, which will take a high-level look at the current tools and work with the community to find out what kind of tools are needed for they things our community does outside of code development, e.g. for discussions, collaboration on initiatives, events and local groups organization, job search etc.

Roles

Product Owner
Project Manager
UX Lead
Section Owners: for each sub-section.
Lead Architect: one for User Groups. Add for other sub-sections as needed, when technical complexity will justify this.

Product Owner

• Has a high level view on all community tools functionality (ideally is a day-to-day user so whatever decisions they make affect them directly, too), thinks strategically and plans ahead for the tools community needs, prioritizes the features that make up the BDD test harness.
• Is extremely gifted at both asking for and listening to feedback from the wider community (not just the insider community), and able to parse out the good points of a large, heated discussion without taking it too personally.
• Moreover is trusted by said community to take their feedback and make a decision that people can at least live with.
• Is ruthless about using metrics and data to prioritize features and drive their decisions wherever possible, rather than letting the loudest voice win.
• Is extremely available so people do not get blocked on them. This might mean that this person is on DA staff or otherwise compensated.

This person owns the "roadmap" of their particular section and works with the DSWG in order to secure DA budget where needed to support.

Project Manager

Someone who can handle things like communications and issue queue tending to communicate this team's decisions.

UX Lead

The UX lead is able to go from requirements set by the product owner to an implemented design that encompasses the different needs of the audiences by showing the design process, carefully handling community feedback and doing the necessary user research to validate the design.

• A multi-versed UX person(s), who is able to develop high quality deliverables from wireframes, flow charts to prototypes, but also capable of carrying out guerilla style user research to validate concepts.
• Able to communicate the design process, to get stakeholder buy-in, and feedback from the community.
• Able to navigate the often difficult technical requirements while keeping the bigger picture in mind, and clearly laying out the rationale for certain priorities.
• Support the product owner in setting priorities and vision around newly developed tools

Section Owners

People who know the functionality of their sub-section front-to-back and actively day-to-day work with the users. Can give the product owner guidance on their sub-section needs and user desires, help prioritize features.

Lead Architects

People who know the ins and outs of the code, who can be relied upon to give contributors, the project manager, and the product owner guidance on whether approach A or B is preferable and help prioritize features. Should be extremely knowledgeable of all the various "gates" that Drupal.org deployment has, and be able to guide contributors on how to meet them as well as able to estimate the ‘size’ of features based on their knowledge.

Responsibilities

How big and how long a commitment is expected of leaders? How are transitions handled?

Staff, volunteers, and compensation

Drupal Association employees may be appointed to roles on teams. Acceptance or fulfillment of a role will not be a condition of employment. Appointment and removal of all individuals to these roles is the responsibility of the DSWG and the individual involved.

There is currently no model for compensation for these roles. This will be a topic of conversation with people interested in the position.

The Drupal Association intends to hire people to support feature development and deployment in areas like Drupal.org continuous integration (as distinct from continuous integration for the Drupal project), quality assurance, and user experience. This support staff does not come under the jurisdiction of the DSWG, although clearly cooperation between the DA support team and the DSWG teams is required.

Day-to-Day Expectations

• Review change requests opened for your specific area of the site at least weekly
• Provide initial feedback for new ideas within a week (not going to happen ever / good idea, we can consider)
• Participate in idea discussion, help flesh out implementation plan
• Approve the idea and implementation plan, indicating development is ready to begin
• Provide guidance and reviews during development, requests for review should not wait longer than a week
• Review the development implementation, marking as ready for Beta server
• Final review on Beta, marking as ready for Staging
• Final review on Staging, marking as ready for Production

Support

• If a daily responsibility is not getting done, someone from the DSWG will ask them what questions they have or resources they need.
• If we/someone can honestly see the struggling person being great at something else, offer/inquire if they would be interested in that other (better for them) role.
• Find someone new for the role and ask the struggling person to share the role with the new person.

Commitment Length

The length of the commitment is two years, with a yearly review during which the Drupal.org Software Working Group will evaluate whether the roles still reflect the needs of the site and the person filling the role can and should continue.

Transitions

Two months notice is desirable when someone needs/wants to leave a role.

Month one
First month is devoted to finding a replacement. The search is to be communicated via various communication channels (documenting the list of such channels is a separate task DSWG is working on).

Month two
second month is devoted to transition.

1. Ask outgoing person to still spend 50% (30-70%) time being available to new person and updating documentation, and doing some stuff (but not all things).
2. Ask incoming person to be at 100% (or 80%) time, but not expect them to be able to actually do stuff alone. Work closely with outgoing person, shadowing them, being mentored (given initial small easy tasks, working up to more difficult, reading documentation, having experienced outgoing person be available to answer questions).
3. Schedule twice weekly 2 hour meetings where attendees are outgoing, incoming, and at least two non-transitioning group members. Use these to prioritize, ask and answer questions.

Authority

The scope of Community Tools Leadership Team authority includes:

• Setting priority within their area
• Closing feature requests with a “won’t fix” with an explanation why.
• Approving work for development and deployment
• Working with the Software Working Group for budget and staff support

The scope of authority within the team will be finalized before appointment. The basic intention is that the Product Owner has the final say in what features will be developed (or not), while technical leads will have the final say on how a chosen feature is implemented.

Conflict Resolution

Conflicts with leadership team decisions and conflicts within the leadership team regarding decisions are escalated as follows:

1. Drupal.org Software Working Group >
2. DA CTO (vacant) >
3. DA Executive Director >
4. Drupal Association Board of Directors

Where conflicts directly affect the Drupal project, the Technical working group may be consulted.

If conflicts become personal in nature, the Community Working Group may also be involved.