Developer tools team leadership

I'm not sure I have answers to your four questions, but as one who missed the boat on new issue tracker review and QA (likely due to DrupalCon pre-travel crunches), I'm happy to be considered for direct notification re: testing future changes. If that just means I need to sign up for e-mails from a very narrow / closely maintained g.d.o group, I'm happy to do that - I just typically don't use e-mail notifications on d.o / g.d.o to keep the noise level down in my inbox.

My goal thus far has been to think meta and communicate how certain changes impede my contribution instead of just push back against "new", so you shouldn't get any knee jerk flak from me. Ultimately, until you got people actually doing their day to day work on the system, I wouldn't have expected some of these issues to turn up anyways. : )

Some specific comments on the proposal at https://groups.drupal.org/node/372893 (commenting here to keep discussion centralized). That proposal maps fairly closely to my own thoughts, so figured I would submit "patches" to the existing proposal, rather than make a new, competing one. :)

Scope

100% agreed that "issue queue" is not complete enough of a scope. Or, rather, I can't imagine a governance structure in which the issue queue had a separate product owner/QA person/etc. than the project download pages, etc. and that functioning at all well. :P

I think the scope you've outlined (Project (and sandbox) pages, and their elements, Releases and release nodes, Issue queue) sounds great, and I would propose we call this scope something like "Project collaboration tools," to make them distinctly separate from "Git stuff," (better title needed ;)) which I think is a big enough ball of wax to be its own distinct area.

My only concern is by not including Testbot here, and probably not including it under "Git stuff" either, we really risk this being brushed under the rug as an afterthought, which was exactly what happened during the D5 => D6 upgrade, as well as the D6 => D7 upgrade. :( I'd love to see this mission-critical functionality go under one of those umbrellas, though I am not sure exactly which one is best.

Roles

I actually think the roles you've outlined (Product Owner, UX/QA Lead, Tech Lead) are quite fine, but just to spur some discussion, allow me to throw a counter-proposal into the mix, which is sort of my "wish list" for how Drupal core initiative teams would be put together, if we decide to do initiatives again in Drupal 9.

• "Product owner" / "Buck stops here" person (area-specific): Drupal core works (well, for some value of works :D) because if we ever reach a stalemate and can't agree on something, we can always fall back to either the subsystem maintainer of the area in question, one of the core maintainers, or worst-case Dries in order to break a tie. Drupal.org has no BDFL model, and it shows. With something like project collaboration tools, there are going to be literally hundreds of opinions, most of them conflicting, about the right direction to take the features, what things should get fixed over other things, etc. So we need someone in this role who:
  • 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 owns the English version of 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 drive their decisions wherever possible, rather than letting the loudest voice win.
  • Is extremely effing available so people do not get blocked on them. This might mean that this person is on DA staff, not sure.

  This person would own the "roadmap" of that particular section, and would liaise with the D.o SWG (or whoever) in order to secure DA budget where needed to support

• Project manager (global?): Whether this is a "global" role that spans all governance sub-groups (like a DA staff member), or whether each sub-group has its own, I feel this role is crucial. The initiatives who had someone who could handle things like communications, issue queue wrangling, volunteer onboarding (and polite "ahem" pinging when they inevitably fell off the grid), running interference, etc. were vastly more successful, as a general rule, than those who had one or more techies trying to also do those things. Let the doers focus on doing, and let the PM focus on making the doers successful at doing. :)
• Lead Architect (area-specific): Someone who knows the ins and outs of the code, who can be relied upon to give contributors guidance on whether approach A or B is preferable, etc. 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.
• UX Lead (global?): Someone who knows the D.o UX guidelines developed by the D.o CWG inside and out, who could help develop mockups, get volunteers unstuck on questions related to design of components. If this were a DA staff person, I'd also throw performing regular usability tests of Drupal.org on their plate, in order to help feed into the product owners' roadmaps for their section, and to help .
• QA Lead (global?): I split this out from UX because I see this as a role that could fundamentally focus on nothing but QA best practices (and similarly allow the UX role to focus on nothing but UX/design). Good QA requires the kind of person who can blunder into problems, but remember the exact pitch and yaw of their hands over the keyboard at the time. :) Even better if they're technical, and can do some investigation and throw developers a bone as to what might be happening. This person would also need to be intimately familiar with all of the D.o deployment gates, and help do final sign-off on changes, help with BDD test authoring (the codey part), accessibility review, etc.

That's a lot of roles, which == a lot of people to coordinate. :\ It's very possible some of these could overlap. For example, maybe your product owner is also the best person to do QA since they're so familiar with all the functionality and get a "spidey sense" when something breaks. Maybe your lead architect also likes to be very involved in volunteer management and write blog posts, so they wear the PM hat, too. But I think by calling these roles out as separate, it's a way of laying out what the ideal team's "traits" would be, if that makes sense.

Responsibilities

One area I'd disagree with here is I don't necessarily think that all of these roles need to be filled by volunteers. If we have someone who's perfect, and also ready and willing, then great. But the DA has big plans to support D.o in 2014, and that includes building a team which may include some of these folks (e.g. the CTO might act in the "product owner" capacity, a UX/QA hire might fill those roles across site sections, etc.).

I think 1 year terms might be too short. Figure it's going to take at least 2-3 months to spin up on the happy shiny fun that is Drupal.org governance, possibly another 1-2 months to get community trust, that's leaving only about half the term in which to actually do things. I think 2-year terms might be more realistic.

However, I also really don't want to find ourselves in a position where we have someone who's awesome in a role, excited to fill it, and doing a great job, just about to hit their stride, and then "oops, sorry, time to replace you with someone green." :\ So I'd rephrase it maybe more like the teams will all be reviewed annually by the D.o SWG, and if it's not working out (either because the person's in a bad fit, or because the person wants out), new team members will be brought on. I dunno. Is that too wishy-washy?

I'm a little less enthused about each site sub-section making up their own responsibilities and removal criteria. I feel like there needs to be predictability and continuity across these, so as a contributor you don't get used to how, say, the "Project stuff" product owner runs the ship, and then come to find out that under "Git stuff" it's totally different. I feel like this is probably something the D.o SWG needs to own, but obviously it would be developed in collaboration with the product owners from various sections.

Authority

+1 on this section.

As far as where escalation kicks in, we could try and get prescriptive about it, but mostly it's when things are blocked up at one level or another. Kind of a "you know it when you see it" situation, I feel (but perhaps I'm being naïve).

In the core queue usually we yell back and forth 2-3 times, and then someone changes the "assigned to" field to the next point of escalation, and they respond within a few days. If it's taking longer than that, then the next escalation point, etc. The D.o SWG could try and come up with some guidelines around how long things can sit there waiting for a decision (I'd allow a week probably due to vacations, etc.), but not sure we need to get super detailed about when escalation kicks in, myself.

--

Thanks, Melissa!!

I'd love to see these roles compensated. Don't know where I had the idea the were supposed to be volunteer (except that there's not an existing economic model for it).

Lets consider stipends or contracts for the roles in addition to thinking about whether they should be filled by staff.

For the past few years I have often on the sidelines been involved with improving our project tools. Often this meant providing feedback on work of dww (some wireframes, etc.). I think its a really good development to see this process more formalised. I think we should take a good look at the lessons we can learn from the D7 upgrade, but also not be too harsh on it as we all know that it didn't go as intended.

I have limited my feedback to the UX part, since I feel like thats the part I am most informed about providing feedback upon.

Scope
I wholeheartedly agree with Angie's proposal, we should enlarge the scope so key parts of our collaboration infrastructure aren't left behind. I do wish to stress that expanding the scope from "just issue/project tools" to all "collaboration tools" is a huge shift. Requires staff or at least some budget, if this is highly unlikely - its good to know now, before we completely hash this out.

Sadly, we have not invested a whole lot in the UX of Drupal.org since the redesign project. Although tvn, has been able to fulfill some of this role however as Angie accurately notes doing QA and UX work is very hard to combine. The UX work is not anywhere near the level we want it to be, where we do validation and design of major changes. I feel in the past few years it often came down to a design being hashed out in a few hours because developers needs it the next day. Which often bypasses a even a half-assed UX process.

For any of this to work, from a UX perspective we need to clearly figure out how to elevate good design from the mazes of trying to get "something" out there. You can have amazingly researched designs, and beautifully documented wireframes but in the end it comes down to allocating enough resources and priorities to making sure a good design makes it into the product. That is key, I feel like the rest is something we can figure out.

Roles
I joked with eliza411 that all these roles centralise around managing community feedback. I think that is fundamental though, besides being an awesome UX/Product Owner/QA person - you have to really know how to manage the community. I see a lot of UX designers who struggle to participate in the community, this because the dynamics of a design conversation can be very overwhelming. However once you learn how it works, it is actually do-able to get a lot of stuff done. These are highly visible changes, so even with loads of managers the designer will need to deal with the feedback.

I don't think this requires a full-time UX person, but do keep in mind the type of UX designer you are looking for might be a unicorn. For the role to succeed the Product Owner should have a big affiliation with creating user value. Otherwise its likely that UX work will get snowed in with more pressing priorities on keeping our collaboration tools alive.

Responsibilities:
I think both Angie, Jthorson, sdboyer are spot on. Clear transition plans and evaluation processes.

Authority
I am really not that worried about this, I feel like we have already been able to make the decisions when needed. But perhaps, that's an outsiders point of view. The issue queue workflow problem, didn't happen overnight and was signaled by many contributors before it was rolled out. The fact that you get more vocal feedback now, is simply because its in their face now. The majority will simply only chime in, when they see it - no communication will change that. It just means that you have to listen extra carefully to the few that do chime in, as they might represent a much larger group (it's often easy to think N=1).

Great to see this conversation happening, I think its been long overdue - but now with the upgrade out of the way something we can finally focus on improving.

Read through all this.

Noting the discussion timeline goes through Nov 22, in one day.

(I wish there was a "hey I read this and am paying attention" button on g.d.o.)

Ideas (maybe good, maybe bad) to spur discussion on transitions of people in and out of roles.

A) 2 year initial commitment with a clause like both parties can decide at any time to separate
because
- 1 year is too short for someone to ramp up and be able to accomplish anything (learn what, learn how, earn trust, finally do something)

B) 1 year renewal. commitment to another year done within 3 months of end of commitment.
because
- makes it clear people do not have to leave after their term. because if they are good we want to keep them.
- 3 months gives enough time to find replacement.
- 1 year renewal is better than another 2 years, they will have already done 2 years, and be all ramped up.

C) expect/request at least 2 month "notice" when someone needs/wants to leave a role.

Ci) first month is devoted to finding a replacement
Cia) communicate info: that the search is on
Cia1) who do we want to reach? do we want to reach the people with the skills to fill the role? or people who use the tools (and they can nominate people)? both?
Cia2) about what? tools are issue queue, project sandboxes, git, repository viewer, test bot
Cia3) wording short but make it clear why what is happening is relevant to them. what might change that will effect them?
Cib) communicate via:
- an issue for people to follow,
- g.d.o post,
- twitter (which twitter accounts, make a list, core. also ping people to tweet/re-tweet.),
- DA newsletter,
- 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,
- DA blog (any blog) .. might make it into Weekly Drop, or one of the five stories of the week on DrupalEasy
- use the tools that we are trying to target the users of to get the message out there
= put a banner on the issue edit page (do all our target people edit issues at least once a month?), maybe on the issue view page in order to get site builders who may not edit issues that often. put banner on whatever tool (repository viewer, project pages), have the tool tell people... testbot comments? those would go on the issue so that wouldn't cover more people... git .. people using git are also using the issue pages. So maybe the issue edit, issue view, project pages would cover everyone.

Cii) second month is devoted to transition.
Ciia) 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).
Ciib) 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).
Ciic) Schedule twice weekly 2 hour meetings where attendees are outgoing, incoming, and ... 2 others related to the group. Use these to prioritize, ask and answer questions.

In order to facilitate the community discussion of the proposal for developer tool team leadership, I'll need to change the proposed date. Paid work has gotten in the way the first week of December. I'll post the time as an event by the end of the day tomorrow, along with the consolidated proposal. It will mostly likely move to 8:00am Pacific/16:00 UTC on Tuesday, December 10.

Scope:

I agree that we should extend the original scope of "issue queue leadership team" to "Developer tools team", with the following items under their purview:

• Projects, releases and packaging
• Issue queue
• Testbot (includes qa.drupal.org)
• Change records
• Git (repositories, Project integration)
• Repository viewer (drupalcode.org)

Roles:

(fwiw I think roles is a better/clearer title for this section)

• One product owner / team lead
• Tech lead for Testbot
• Tech lead for Git / Repository viewer
• Tech lead for Projects, releases and packaging - //I think this should be so, however right now it doesn't seem that knowledge about the packaging scripts is concentrated in the same people, who have the best knowledge of the Project* code base. It seems like packaging sits in between Project and Version control, so I am wondering if we need a separate person who'll concentrate on this.

We might want to consider a separate Tech lead for the Issue queue, just to try distribute knowledge/responsibility for the Project* stuff a bit more, since that's a huge piece for one person.

I am not sure where change records should go, technically they are pretty simple. Do we need a separate person for them?

• QA lead (maintaining BDD tests for this area)
• Support lead - didn't see anyone talking about such role before, but it seems important to have a dedicated person who will ensure that support requests are being answered, flag complicated/important requests to the rest of the team. This person needs to a. know what's going on and what might have caused issues b. have knowledge about the inner workings of the system to be able to help people

UX lead - I think this should be a global position, or rather a small global team of "UX/Design maintainers" who will work with area-specific teams
Project manager - I think it's better for this role to be global, to work with different area-specific teams. In part to ensure they work in somewhat similar way.

I will argue that at least some of the roles should be DA staff members to ensure that they are highly available and the work is being done, and that the DA has institutional knowledge of the most crucial part of the website.

Responsibilities

will post a separate comment

Authority

Agree with what's written. I think these are very important:

• Set priority within their area
• Close feature requests with a “won’t fix”
• Approve work for development and deployment

While we were somewhat able to make decisions, this authority basically never existed. Especially the "closed(won't fix)" part. To succeed, we need to clearly document this and we need to enforce this. Which means, if some change wasn't reviewed and approved by the Product Owner, it should not go live. If product owner set status to "closed(won't fix)", someone else won't re-open that issue in the next 5 minutes, saying "but I want this".

We also need to be clear on authority within the team, so e.g. if Tech lead is strictly against specific new feature/approach, Product Owner should have the last word and make the final decision.

While we were somewhat able to make decisions, this authority basically never existed. Especially the "closed(won't fix)" part. To succeed, we need to clearly document this and we need to enforce this. Which means, if some change wasn't reviewed and approved by the Product Owner, it should not go live. If product owner set status to "closed(won't fix)", someone else won't re-open that issue in the next 5 minutes, saying "but I want this".

There's a reason this authority never existed. A lot of time has been spent by a lot of people over the past couple years making Drupal.org easier to contribute to. I don't think it's okay for somebody to just outright say "No", though I think the product owner should be able to direct how it's implemented and determine whether or not the DA will spend time doing it, or if it should be a community task.

As a result, those voices are often drowned out by what is perceived to be a lack of supporting opinion, when in reality it's merely a visibility issue.

Solving the visibility issue could probably be solved with a weekly "newsletter" of sorts - basically a list of issues where people should speak now or forever hold their peace.

In any case:

I totally agree that the DA should not be the sole arbiter of what does/does not go on d.o, and it's imperative to allow for (and actively support) community-driven improvements that are either not big enough or fall outside of the skillsets for DA staff. I also totally agree that the process of deciding what goes and doesn't go on d.o needs to be inclusive and seek out community feedback (particularly for controversial improvements), and that if the person in the product owner role just tosses about their iron hammer all the time without backing up their reasoning with data/research, they'll quickly lose community respect and be completely ineffective at their role.

I read and reread this a few times. The more I think about it, the more I agree with it. If there's a process for removing the product owner in the event that they start abusing their power, I'm happy. :)

I am really disturbed by ideas that somehow this group doesn't represent the community. I think that is a dangerous thought that has been surrounding the DA for a long while. The DA essentially IS the community its representation. Whenever priorities don't align with that of the community, the issue queue team should reconsider its position.

Angie is very right however that this team should cover the whole of the community, not just the 1% that spends every awake hour in the queue. I feel like loads of people are perfectly capable of managing those occasionally conflicting priorities. I do think its a little unrealistic to expect somewhat "data-driven" decisions on each part of the audience. Instead I would aim on using research as a tool to identify and align priorities, validation should be applied more sporadically depending on impact.

It should, when the opinions of this group doesn't align with the majority of the community then we are

Awesome to see the structure of roles and really enjoyed the video to understand the direction. I think a team approach will bring in more traction and bring in timely responses. Also as there is no financial commitment, having a team working on the same, will help keep the momentum. The idea to improve community participation and feedback is appreciated.

I am sure we will be looking at organisation sponsors
for many of these posts would help bring good representation of Community. Can Drupal association provide recognition for organization sponsors it would be great!

Using local groups to push the news is a good idea to get more participation.

Did not get an understanding on Time commitment for the different roles, I am sure that should come out in the announcement.

not sure why my post got submitted 3 times.