Developer tools team leadership [PROPOSAL - R3]

This document is the second revision of the discussion which began at https://groups.drupal.org/node/368148. 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, kim.pepper, 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:
Team Leadership [The 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

Developer Tools Scope

The scope of functionality for the Developer Tools Leadership Team includes:

Projects (modules, themes, distributions)

• Project pages, and their elements
• Releases and release nodes
• Packaging scripts
• Issue queue
• Change records

Version control

• Git repositories
• Git integration with website (access agreement, commit logs, Git instructions, etc.)
• Repository viewer (drupalcode.org)

Continuous Integration Testing

• Testbot server (PIFT)
• Testbot client (PIFR)
• qa.drupal.org

Since this is a very wide set of functionality, the more complex systems will need distinct technical leadership. That leads to...

Roles

Product Owner
Project Manager
UX Lead
Lead Architects: one for Project (at least one, we’re eager to discuss ways to effectively sub-divide Project responsibilities), one for Version Control, and one for Continuous Integration.)

Product Owner

• Knows the functionality of their site section front-to-back (ideally is a day-to-day user so whatever decisions they make affect them directly, too), and 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. The scope for the project manager/s may extend to all three areas of the Developer Tools (Project, Version Control, and Continuous Integration or may focus on a single area.) This is to be determined based on interest level and discussions with other team members before roles are formalized.

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

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:

1. An issue for people to follow in the Software Working Group issue queue
2. A g.d.o post to Drupal.org Improvements group (https://groups.drupal.org/drupalorg)
3. A g.d.o post to Drupal Governance group (https://groups.drupal.org/governance
4. Twitter @drupal_org as needed; @drupal @DrupalAssoc once; committee members personally if desired.
5. DA newsletter
6. Ask for spots on podcasts, either directly about the open role, or in general about governance and mention open role during small part of the discussion
7. DA blog (any blog) .. might make it into Weekly Drop, or one of the five stories of the week on DrupalEasy
8. Explore user opinion and potential effectiveness of using the tools that we are trying to target the users of to get the message out there

   Suggestions:

   • Place a banner on the issue view page and project pages.
   • Add a footer to issue queue mail
   • Add a footer to g.d.o. mail
   • Explore communicating via the DUGs: Create a curated list of local user group organizers, create newsletter or mailing list for them, kind of “stay up to do with major D.o news”. Use this channel to let them know what’s going on and ask them to announce in their user groups

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