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
The first team we set out to appoint was Developer Tools Team. That process is at the finish line right now. We are getting ready to announce team members on January 30.
Therefore, it’s time for us to start working on the next team.
Proposal
Community Tools Team 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 Owner for Forums
- Section Owner for Planet
- Section Owner for User Profiles
- Section Owner for User Dashboard
- Section Owner for User Groups
- Lead Architect for User Groups
Detailed proposal: https://groups.drupal.org/node/402653
Proposed Timeline
January 23 - February 2 — Online Discussion
Process Facilitator: tvn
Responsibilities, Authority and Conflict Resolution will largely follow the ones we defined for Developer Tools Team. The discussion template below contains some of the questions for consideration for this team specifically.
Discussion Template
- Scope: Are the areas proposed related enough to group them and under one team? Is there something else, which should be listed?
- Roles: What roles are needed for this area (technical lead, product owner, QA lead, etc)?
February 3 - DSWG to summarize community discussion, publish the final proposal and publish the call for candidates
By February 28, Drupal.org Software Working Group to appoint leadership team
Comments
Imho this grouping makes a
I published more detailed
I published more detailed proposal at https://groups.drupal.org/node/402653. It is mostly based on the one developed for Developer tools team (https://groups.drupal.org/node/372893/) with adjustments for the current team's scope and roles. Thanks a lot eliza411 and everyone else who worked on the original Dev Tools proposal!
Should one person be Product Owner of all this?
I'd love to see more discussion of #1, as that's still a big question for me.
The linked Product Owner description says "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)." While it could work well to have a person who fits this description for Forums, Planet, User Profiles, and Groups looking out for the broader community interests, I'm doubtful such a person currently exists. Certainly someone could become familiar for this role, but I wonder if the lack of anyone already familiar with all of these sections might be a good indication that this is too much under one roof. Specifically, I wonder if Groups should maybe remain more independent.
On the one hand, groups.drupal.org management is currently a silo, with very little communication with the management of any of the community-focused sections of drupal.org. So consolidating the management would likely improve sharing of ideas and resources between the sites. I'm specifically thinking of spam as a problem that plagues all community resources while we're reinventing wheels between groups.drupal.org and drupal.org. But Groups also has it's own discussion forums, it's own content aggregation, and it's own user profiles, so there's likely more areas that could benefit from consolidating management.
On the other hand, I'd hate to see groups.drupal.org end up with even fewer resources than it has now as a result of this consolidation, which seems a likely outcome under the current proposal. Even just the listing of Forums, Planet, Profiles, and Groups as 4 areas of focus makes me nervous, as that puts them all on equal footing. Without knowing all the details, I suspect Groups is more complex than the other 3 combined. One could easily read this proposal and not realize that Groups is a completely separate site, not just a section of Drupal.org.
This complexity differences is already acknowledged on the technical level in the proposal to have one Lead Architect for Groups and another for the other 3 sections, but the complexity difference isn't only technical. Should Groups also have a separate Product Owner?
I don't have a good answer to that, but wanted to make sure it was at least considered here.
Thanks for your comment,
Thanks for your comment, Scott.
Yes, this is one of the main reasons for including groups here. I feel very strongly that we should get g.d.o team more involved with other D.o teams and volunteers. I think this will help the site get more attention and more help, which it deserves and needs, both from the community volunteers and the DA.
I do not think this is what's going to happen. And this is definitely not the intention. My hope is the opposite, that we'll be able to attract more resources and help to the current g.d.o team. Particularly, by providing a channel for them to get their initiatives into a larger Drupal.org development roadmap.
That is definitely true, Groups is more complex. However this does not mean they can't be under the same leadership team. When combining sections/sub-sites into teams we first of all look at what they do, what kind of service/tool they provide to the community. Above you said that the person, who can oversee all of these sections, probably does not exist. This might be true, and this is also sad. I think that we do need someone to look at all the community tools we have from a high level perspective, keeping them all in sight. Someone who while talking about changes to one of them, will think how it affects all the rest. I would also love us while having conversations about some new tool or section, first talk about what that should be, how it should help community to do X. And only then think where it is best to technically locate the thing, instead of the other way around.
To your main question - Should Groups also have a separate Product Owner? I'd say they might, but even in this case they should stay within this leadership team.
I must say while I agree with the scope, I was struggling with the list of roles for this team myself. Saying "technical lead for forums" or "technical lead for user profiles", doesn't sound the same as "technical lead for version control". Very different level of technical complexity, we don't even use custom code solutions for forums for example, for this person to maintain. On the other hand we do need a person on this team who will represent each of these sections. Maybe we should call all of them "Product Owner for X" or "Section Owner for X"? And since g.d.o is indeed technically complex section, they will also get "Technical Lead", therefore will be represented by two people in the team. Would this help your concerns?
To illustrate in this case the team would look like so:
Product Owner
Project Manager
UX Lead
Section Owner for Forums
Section Owner for Drupal Planet
Section Owner for User profiles
Section Owner for User Groups
Techical Lead for User Groups
Section Owners
I like that a lot. It feels like the right resource allocation while still keeping everything together.
It just occurred to me that
It just occurred to me that we should include/call out one more section here - User Dashboard. Which is related to user profiles, but is fairly separate component.
What about the issue queues?
So are the issue queues excluded from the intended Community Tools Team scope? I ask because the focus on community seems related to Prairie Initiative proposals, but then ideas like the reputation system (proposal, overview) which would affect the issue queues could not be considered by the Community Tools Team. Or would issue-queue related ideas be considered by another team?
Developer Tools Team
Issue queues are specifically in scope of Developer Tools Team (https://groups.drupal.org/node/372893). Sometime bigger initiatives would touch multiple sections of the site, in which case different teams will have to work together. Mechanics of that we will have to figure out as we go. :)
A while ago it was announced
A while ago it was announced that groups.drupal.org will move to Commons? What happened with that one? :)
****Me and Drupal :)****
Clickbank IPN - Sell online or create a membership site with the largest affiliate network!
Review Critical - One of my sites
Groups.d.o are still on D6
Groups.d.o are still on D6 currently, they will move to Commons when on D7. Upgrade is in progress.
_
With regards to #1, I agree this makes a lot of sense (including your suggestion to include the dashboard).
For #2, the way I would have thought it would be organized would be by having a decision maker role for each area, and additionally a technical/architect role for those areas where the complexity justifies it. imo a ux role should apply across areas. There should also be a single overall team lead type role.
In general, this is an excellent idea and will help overcome analysis paralysis and bike shedding that often prevents progress.
+1 on a single group for "all
+1 on a single group for "all the ways the community interacts" (apart from issue queues which are part of dev tools)
Less sure about user dashboards / user profiles though because that doesn't really fit that motif. OTOH I'm not exactly sure where else to put them.
I could see us going without the product owner for this group, since as sreynen points out they're pretty disparate pieces and it'd be really tricky to find someone with familiarity over all of it. We didn't have this problem as much with developer tools because the same people interact with all parts of it; community tools far less so — there are super distinct groups of people who use the forums vs. use g.d.o vs. read planet (though there's definitely also some overlap).
Not going with a product owner would mean giving decision-making powers to the engineers/techie types as opposed to "user advocates" or whatever though, so that's something to consider. OTOH that's effectively what we were forced to do in developer tools, too, so maybe we could choose to just be explicit about it here.
Since the Drupal.org Content Working Group owns the policies around user-generated content, it'd be good to see them represented here somewhere. Maybe as product owner? Not sure.
Less sure about user
Agree, it seems best to keep them here for now, until/if ever/ we come up with something better.
I can't agree here, I don't think the group can be efficient without a single person leading it. The one person who'll pull together one Roadmap for all Community tools, and set priorities as in - we do this first and this second, or we ask budget for this first and that second, etc.
I think in this group the overall Product Owner role will be a bit different than in the Dev Tools Team. If we decide to have "Section owners" per my previous comments, overall Product Owner won't need to have very deep knowledge of each section. We might consider calling this role 'Team Lead' or something.
I also don't think a group, such as DCWG, can play product owner role. WGs need to stay on strategy level and we are appointing the team for day to day operations. I don't even think DCWG will be able to write every single policy for every single thing on the site, often that requires deep knowledge of the particular section as well. What I can imagine, for example, is that people who moderate forums see a need in the new policy for specific situations. They prepare draft policy and ask DCWG to review and approve, to ensure it's in line with our general policies and such. DCWG then does review and approval.
What we need to do is be clear on what kind of decisions the team can do and what type of decisions are for DCWG. E.g. no big policy changes without DCWG approval.
"I can't agree here, I don't
"I can't agree here, I don't think the group can be efficient without a single person leading it. The one person who'll pull together one Roadmap for all Community tools, and set priorities as in - we do this first and this second, or we ask budget for this first and that second, etc."
Well, all of that's actually our job as the DSWG. :) But I think what I hear you saying is it'd be easier for the DSWG to maintain the overall Drupal.org roadmap + manage funding requests to the DA if these things were sent via one person per team rather than 4+. I can understand that reasoning.
However, in that case it doesn't seem like "Product Owner" is quite the right role name, because we wouldn't want that role to mean different things for different groups, and in Dev Tools it definitely was "knows all of the ins and outs of what the stuff in this part of the site does." "Team Lead" also feels wrong, though, because it sounds like this person isn't really leading anything, but rather distilling feedback from the individual section leads, who are the actual leaders. (Blah, too many "leads" in that sentence :D). In that respect, it's more of a "project manager" role, which we already have identified. So again, I'm not quite clear on why we need the additional role here.
And yeah, I suppose we could handle the DCWG relationship with a "scope" section, similar to the DSWG/DCWG charters themselves. It does seem though like it's a good idea for this group to be in close contact with the DCWG (much moreso than the DSWG, even), and I'd love to codify that in some way.
Thanks everyone for your
Thanks everyone for your comments! Software Working Group discussed the feedback yesterday. I updated the proposal with our current thinking about the roles in the team. We now start looking for possible candidates to fill the roles. If you are interested or know someone who could be a great candidate, let us know! You can use my contact form or talk to someone from the Software Working Group via IRC/other channels. Please let us know before February 20.
I am late to this discussion,
I am late to this discussion, but I feel the Community Tools Leadership Team [PROPOSAL - V2] might be missing one important community tool, which is localize.drupal.org. The centralized translation platform not only provide role/permission based colloboration tools for submitting/editing/approving/downloading translation but also has its own groups, wiki, poll, story and notifications.
As we probably know the importance of localization and internationalization to Drupal, I suggest this group also consider to give support to localize.drupal.org, both technical and nontechnical.
Another team
Thanks for your comment! We indeed remember about localize.drupal.org and were considering a number of teams it can be a part of. However, it seems that the tools l.d.o provides are not exactly developer tools, therefore Developer Tools team won't work, and not exactly Community tools either. If you look at everything else in the scope of Community tools team, the nature of interaction is a bit different, mostly about conversations between community members, the ways they get information from the community and present themselves.
L.d.o provides specific tools to work on translations. So for now our plan is to establish a separate Translation Tools team for l.d.o and everything related to core and contrib translations.
What do you think about that?
localize is a developer tool
actually - our translation infrastructure is a developer tool - it directly impacts how people around the world use our software. If it gets its own team, then great, but I don't think it should be dismissed lightly.
Donna Benjamin
Former Board Member Drupal Association (2012-2018)
@kattekrab
A separate team isn't
A separate team isn't dismissing it. As with any team, there are a couple possibilities:
We're working on filling out the team. I think the best thing to do now is to follow through with it. As always, we can re-evaluate the org chart when we know more.
I'm also late to the
I'm also late to the discussion, and it seems that there's a roadmap being discussed? After following links & threads linked to this topic, I didn't notice any roadmap/s (visualization or outline) presented. Am I missing something?
Marckee for Short
Team first, roadmap next :)
Hi Marc,
right now we are working on establishing leadership team, which will be responsible for developing said roadmap for their section of the site. So you are correct, the roadmap does not exist yet. We do hope that the team will create one.
Drupal type of HTML5 schema tags For Module info
What is really need on drupal.org is
http://schema.org type of tags
for module descriptions
Then it will be easier to gather and
use different module info
example html tags
hosting
version
sitescale
description
Then you this would make it easier to gather module info
You can make question and answer for which module to use
How about this feature a module question form
form you fill in and asks you questions?
i.e
1.choose module "search"
2.How many people do you expect use this site? 1000
3.Are you using a shared hosting or VPS? VPS
4.Is budget important? Yes
RESULT
Your module is search api
because ......
Other related module that we're not choosen are
solr apache because....
(it pulls related info from the community about the module)
Article Info search api
Here's list of articles related to this module
from https://drupal.org/planet
I hope that's helpful idea :)
This is a helpful idea
This is a helpful idea indeed, however in this specific post we are discussing team appointment for Drupal.org. Later in the year we will run large ideation process for Drupal.org, I hope you can present your idea then.