In the summer, we organized the very first Drupal Governance Sprint. We sat down and discussed how to evolve Drupal's governance structure to support the Drupal community's continued growth. The result of that meeting was a proposal on how to evolve our governance. After discussing at length and formally chartering the first of these groups, the "Community Working Group" (CWG), we'd like to move on to governance.

One of these groups is the Software Working Group (DSWG). This group will work closely with the Drupal Association and the other working groups, along with incorporating broader community input, in order to develop and maintain a roadmap of features for They will also be focused on establishing and maintaining processes that help expedite decision-making, in order to reduce the barriers to contribute to

Here is a draft charter of the working group, drafted by webchick and myself, after running the general concept past a few of the Drupal Association staff and after discussing with the Drupal community in this issue. Before we officially launch this group, I would like to get your feedback. We'll iterate on the draft charter in approximately 3 weeks based on your input. Thanks! Software Working Group Charter


The mission of the Software Working Group (DSWG) is to provide the tools and processes for the community to make an extraordinary experience for evaluators, site builders, and contributors alike, and a shining example of what Drupal can do.

The DSWG acts as a group to define the overall technical strategy for the properties, to empower teams responsible for individual sub-sites and portions of to build and maintain this vision, and to provide them best practices, guidance, and coordination to help expedite decision-making.

Scope / duties / responsibilities


The DSWG is responsible for the overall strategy, planning, architecture, development, and maintenance of the software (e.g. modules, themes, customizations) used by the websites. The DSWG employs a "federated model" consisting of independent teams with centralized coordination for different aspects of the websites.

DSWG appoints and empowers different teams, each responsible for a particular aspect of the websites (e.g. issue queue, a particular sub-site), with the aim to provide contributors, end users, and sponsors of a delightful experience that scales to fit their needs.

Each team has the authority to make decisions within their scope but the DSWG acts as a steering committee to the different teams. It provides overall guidance, collaboration among those teams, providing advice about best practices, strategic and technical direction, etc. The DSWG also works with the Drupal Association on budgeting related to each team's software needs.

Specific duties

The DSWG provides vision and direction for, and works with the community on the following aspects of the software:

  1. Team Leadership Creates and removes teams for each major area of the 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.
  2. Ideation: Working with the different target audiences (e.g. contributors, evaluators, site builders, etc) to understand their needs and coordinate with the different teams on implementation.
  3. Planning: Collaborate with the Drupal community, the Drupal Association Board of Directors, and individual teams on maintaining an up-to-date plan for the websites that includes a prioritized feature roadmap, costs, schedule breakdown, deliverables, resource needs, and contingency plans.
  4. Architecture: Establish processes to ensure that we can efficiently make architectural decisions about the software, including those related to overall site architecture, choosing between different technical approaches, etc.
  5. Development and Maintenance: Provide guidance and processes to ensure the smooth running of the website, including: responsibility and accountability of the teams, performance, security (including roles/permissions on, upgrades, quality management, and sandbox environments.


Items specifically not within the scope of the DSWG’s duties:

  • The DSWG, as well as its sub-teams, cannot make deployment decisions without coordination with the Infrastructure Working Group (DIWG).
  • The DSWG, as well as its sub-teams, cannot make visual design changes to the websites without coordination with the Content Working Group (DCWG).
  • The DSWG cannot change or extend its own charter.



The DSWG must establish a process that balances timely decision-making with involvement of a broad spectrum of the Drupal community. The DSWG should also work closely with all other working groups, as well as Drupal Association staff, in order to determine overall needs and priorities for


The DSWG works within the budget provided by the Drupal Association, and presents a yearly plan with cost breakdown for Board approval.

Transparency and Appeals

The DSWG aims to be as transparent as possible by documenting its decisions publicly.

Individuals who do not agree with a given * decision may escalate to the DSWG, or ultimately to the Drupal Association Boad of Directors and/or their designate(s). They will review the decision and can choose to either uphold or alter it. In the meantime, the decision stands.


The current members are (in no particular order):

  • TODO

Members are appointed by the Drupal Association Board of Directors and/or their designate(s).

Charter revisions

The charter will be revised as needed. Any proposed charter revisions must be ratified by the Drupal Association Board of Directors and/or their designate(s) prior to acceptance into this charter.

#19 1929526-19.dswg-charter.patch1.84 KBdww


LeeHunter’s picture

I have added this issue which is relevant to all the proposed working group charters #1934018: Formalize stakeholder roles in working group charters.

sdboyer’s picture

one of the major conclusions i've come to since we launched the git migration is that we need product owners, plural, with specific subdomains of responsibility within the d.o ecosystem. this became particularly clear while we worked on the doobie project last year, attempting to create BDD tests that would encompass all the functionality on eliza411, jhedstrom, the CapGem team, and others made a colossal effort in putting together the tests we have. it quickly became clear, however, that the test suite would be unmaintainable without multiple people caring after segments of it. this is a basic pattern i've seen played out with clients, as well. the crux of it is this:

while BDD is often presented as a useful tool for allowing (non-coding) product owners to express testing requirements in natural language, the obverse reality is what matters: without product owners to express user requirements and maintain those expressions, BDD has no direction and loses its value.

and, let's be clear: we desperately need BDD for BDD is the best mechanism i am aware of to have living, functional documents that describe the set of contracts a website has with its users, and if there was one common undercurrent throughout all of last year's work on the D7 upgrade, it was that nobody knows the full set of functionality that provides. that knowledge is fragmented over many people, primarily developers - and the problem with leaving that knowledge in developers' minds is that it is further fragmented by all the detailed knowledge of the past, present, and possible future innerworkings of the system. at least, i know that's the case for me. imo, i am of more value to the community maintaining the existing system and maybe working on new features than i am maintaining knowledge of the exact use patterns we expect everyone to follow for each and every case. maybe if this was my full time job, but...honestly, this is one of the (many, essential) roles that eliza411 has quietly operated in (for git-related functionality, at least) for years, and without her doing it, i'd have even less of a clue what's going on.

hence, product owners. plural. i would like part of the responsibility of this working group to be the creation of product owners "positions" (something like that) who are responsible for some sub-portion of (*.) functionality. that entails:

  • being the point of contact for the community wishing to expand or modify functionality in their area
  • being the final arbitrator, manager, and caretaker of BDD features defined that relate to their area of responsibility
  • being my point of contact, as an infrastructure team member, when i am implementing functionality they have defined

in two words: requirements definition.

one product owner will never be sufficient. first, because i'd imagine this being at least partially a community role, but also because there is WAY TOO MUCH functionality, way too many user stories, for one person to reasonably be able to maintain. and also, simply because whenever that person transitioned out and a new person came in, there'd be no continuity; much better to divide the responsibility into a group of folks who can support each other, train each other, and maintain continuity through transitions.

of the new groups being proposed here, it seems to me that this is the most appropriate one for this. if not...well, it's gotta go somewhere. i can't & won't speak for any other infra folks, but i need this in order to do anything more than maintenance on

sdboyer’s picture

oh, and one other thing...

this team of product owners really should be celebrated by the community at least as much as any developer. i know that i, for one, will be buying them lots of beer.

sdboyer’s picture

Issue summary: View changes

Initial draft

lisarex’s picture

Does this include Bluecheese theme maintenance/ improvements?

lisarex’s picture

Also, does this include the Solr search on d.o.? I believe that's one area users experience a ton of pain and it would be good to identify the group is responsible. The Content Working Group should be able to assist on the content strategy/UX side.

tvn’s picture

For Bluecheese yes, I think it falls under SWG. Not in a sense that 5 members of this WG maintain/improve it, but decisions like - do we use Sass? base theme? etc. Design decisions for specific pages/sections fall under CWG.
As for Solr search, it might be also something for Infra WG.

tannerg’s picture

I think sdboyer has put his finger on something here that makes a great deal of sense. Dries has the Drupal Association at the top of his diagram relating to governance and d.o on his blog here

However, I think this comment points out that there should be more specific "positions" within that association and the drupal community that oversee the different portions of d.o as a product. I have found strong product managers to always make a huge difference when working on projects over the years. Why would d.o be any different.’s picture

See my comment at #1929524: Infrastructure Working Group Charter (DRAFT) regarding neccessary collaboration with infra.

fuzzy76’s picture

I would think the Solr responsibility depends on which side of the Solr socket you are. Anything running inside Drupal should be SWG, while the stuff that happens in Java-land shoud be DIWG.

Other than that, I absolutely agree with sdboyer, including the part about the beers. :)

Crell’s picture

The charter as written feels very... vague to me. I don't get a good sense of what exactly is and is not in scope, perhaps due to verbosity. Moreso than the other charters I've read so far. :-)

Given that, copy sdboyer's post and put it here, too. *The* most important thing for * moving forward is clear, named product owner(s) and technical lead(s), who are known to be the Person/People Who Can Make A Decision(tm), and do so. Assuming that fits into this WG, making that explicit, using the terms Product Owner and Technical Lead, is critical to clarify where that authority lies.

I've been extremely critical in the past of the lack of a clear, understood human SOA for (Source of Authority, not Service Oriented Architecture, although that would be good too.) If we're establishing a governance process for, it *must* include clarifying those roles.

Also, same note as the DIWG: The text seems to imply * but doesn't say so explicitly. It should.

sreynen’s picture

As a maintainer of, I agree very much with #2. This cuts across all the WG charters, not just this one. Day to day operations of subdomains (and I'm talking specifically about domain names here, but I think the same is true of more general areas of focus) is almost completely autonomous right now, and I think that's mostly a good thing. We could probably use more communication between maintainers of the various sites, but each site has a distinct purpose and I don't see one group being able to effectively keep those as distinct and active as they are now. The focus of these groups should rightly be on proper, and that's already reflected in the charters, with plenty of examples referencing proper and none (that I can see) referencing anything about the subdomains.

But the charters also give these groups direct responsibility for and authority over the subdomains, which seems most likely to result in the subdomains being largely ignored. As a maintainer, I'm currently responsible for (to paraphrase) "Working with the target audiences to understand their needs and incoporate those into a feature backlog." With this charter, I'm no longer responsible for that. I'd be very happy with that decreased responsibility if I expected this group could feasibly assume that responsibility, but I don't see that happening. Instead, I think the current draft, without any mention of the role of project owners, could too easily promote neglect of subdomains like

webchick’s picture

Lots of great feedback here. We're currently revamping this charter to introduce more of a "federated" governance model of * that better matches our current structure a bit better. Stay tuned! :)

webchick’s picture

Issue summary: View changes

Changed "They also collaborate and provide support to ..." to "They also collaborate with and provide support to ..."

Dries’s picture

Angie and I drafted a new version of the DSWG charter that reflects a lot of the comments to-date. I updated the draft in the issue summary so please re-read it before commenting. You can view the "diff" of changes.

The changes keep the "spirit" of the DSWG as the ultimate steering committee for all websites, but also acknowledge the existence of and need for individual teams to take care of smaller aspects of the websites (major features, particular sub-sites). The new charter draft reflects the responsibility of the DSWG to create and remove said teams, as well as appoint positions within the teams such as technical lead and product owner (which may or may not be separate roles, depending on the team). These teams can then act autonomously in their own areas, but with overall strategy/coordination provided by the DSWG.

I'd love to know what you think. I'm aiming to finalize this within the next 2 weeks, so please continue to provide your feedback! Thanks everyone for your input to date.

Dries’s picture

Issue summary: View changes

Updated issue summary.

webchick’s picture

Status: Active » Needs review

Marking as needs review.

dww’s picture

Status: Needs review » Active

Generally, I'm thrilled to see this attempt to formalize the governance problems on d.o, which have always been a potential source of trouble.

From my perspective as someone who's spent a lot of time on both sides of this issue (both making and being subject to governance decisions regarding d.o software), here are some of the common sticky problems I've seen that I think this Working Group needs to be able to address. I don't (yet) have good solutions to propose, but I didn't want to let that stop me from enumerating some of the problems as I see them:

A) Existential crisis about what is d.o. For example, what features belong on "the mothership", what features should be split off into subsites, and what features should be outsourced to external services? I don't really see how this charter addresses this fundamental problem about trying to get things done on d.o. As a concrete example, it's not clear if this charter empowers anyone to make a decision like "let's use Github for all our Git infra."

B) I know this effort is about making the decisions, but a related problem is "enforcing them", by which I mean: who has the time/energy/resources to actually see feature X deployed live? It'll be great if we have a structure that allows the DSWG to make a decision to deploy feature X. But when the time comes, just because volunteers wrote the code doesn't mean that the (mostly over-committed) people who have full access to deploy changes to the site have time to review, deploy, debug, fire-fight, fix, re-deploy, etc. I wrote some related comments about the infra WG at #1929524-12: Infrastructure Working Group Charter (DRAFT).

Quoting webchick in #1243332-174: Deploy Project Browser Server and drupalorg_pbs on d.o:

Note that in order to try and pre-emptively address catastrophic failures like this issue, we are aiming to establish a Software Working Group governance structure.

I know I'm guilty and implicated in that "catastrophic failure" since I participated in the issue and it's still not deployed. I'm not taking such harsh language personally -- I know she's not calling me a "catastrophic failure", just our (non) process. ;) However, re-reading that issue, it's not entirely clear what the existing Infra Team did "wrong". As early as possible, we raised our (reasonable) concerns. They went mostly unaddressed for months. When they were answered, the biggest failure was simply that there was no one available to actually do the (many hours of) work to review all this new code for scalability and security concerns, deploy it, monitor it for trouble, fix whatever might arise, etc. Just because DSWG and/or the DIWG decide this feature would be a good thing doesn't mean we have time to do our due diligence and make sure the change isn't going to disrupt the functioning of site-wide. Yes, that'd support a cool feature for core, but supporting Drupal core features isn't the only mandate of the infra team. We have an entire community full of stake-holders and use-cases to support, and a lot of (usually conflicting) demands/mandates/requirements to try to balance.

So, in short: just because we have a plan for making decisions (although I agree with Crell that the plan as drafted here is still pretty vague) doesn't mean we have resources implement those decisions, and *that* seems like the biggest pain point in a lot of the cases people are (rightfully) concerned about trying to address through this governance structure process.

C) Who are appropriate members of this WG? I also raised similar concerns over at #1929524. I've been maintaining a large chunk of the d.o software stack for about 7 years now. I have a lot of experience and perspective on d.o software, the kinds of problems we face when we make changes, the concerns of the UX/UI team, the infra team, the sec team, long-term plans on how things Should Work(tm) that I've been trying to move us towards over the years, etc. I've thought *a lot* about Drupal contributors and the tools they want/need. Seems like I'd have a wealth of things to offer this working group. At the same time, I've often been hired by the DA to implement various improvements in the d.o software stack. So, I'd be one of the "hired guns" that would presumably be asking this WG for direction on how to implement various changes. Is that a conflict of interest? This is clearly much bigger than me personally, but I think I'm a useful case to consider. ;) Are people like me suited to be members of this group? Why/why not?

D) Maybe it's just been too conflated for too long and I no longer have clear perspective, but I still don't fully get the distinctions between this group and the infra group. I know the folks driving this effort want there to be a distinction, but in practice, I'm not sure the charters make it clear enough to be useful. It seems to basically be a question of "inside Drupal == DSWG" vs "outside Drupal == DIWG". But, many of the problem areas on d.o software are intimately interwoven with infra (either scalability or security) concerns. What module we choose to use to implement a given feature has a *lot* to do with how scalable/performant each choice is. There was a useful exchange between webchick and killes at #1929524 about what happens when infra needs/concerns conflict with the decisions this group wants to make. How are inter-governance working group disputes resolved?

There's probably more, but I need to get to work porting d.o to D7 again, so I should shut up here and resume hacking code. ;)

Again, I hope all these concerns and questions are seen as an earnest attempt to help this effort succeed. I'm not being contrarian, and I don't want to hold back progress. I've just been either in the middle of, the source of, or a victim of a lot of the problems on d.o, so I wanted to try to raise as many potential problems as I could. ;) If I come up with others, I'll definitely post here.


dww’s picture

Status: Active » Needs review

Argh, crap, x-post. ;) Sorry, I was writing all that before Dries's comment, so I haven't seen the new draft. From the sound of that comment, it doesn't seem like my concerns were preemptively addressed in the new draft, so I don't think it was all wasted "ink"... I'll review the new draft ASAP, but I need to get back to "real work" for now.


dww’s picture

I just read the diff and nothing in there invalidates or answers any of the concerns/questions I raised in #15... Phew. ;)

The diff mentions that DSWG can't make deployment decisions without consultation of the DIWG, but I don't think that really goes far enough. Infra concerns have to be baked into the earliest parts of the process for software changes on d.o to deal with the kinds of problems we want to solve. If the goal is "let's never have motivated volunteers sink 100s of hours into something that's going to be unilaterally shot down at the 11th hour by a benevolent dictator" then IMHO we can't just have the formal coordination between these WGs be left to the "deployment" phase.

That said, I like the concept of (sub)teams being elaborated in the new draft.

Hope this is helpful. If not, please let me know what I could be doing differently.


webchick’s picture

Just a quick note that the charter as it exists now has been committed to git at just to put a stake in the ground. We're wrapping up for the day but will try and respond to dww's feedback (and anyone else's) tomorrow.

dww’s picture

Cool, thanks. One thing that helps answer #17 is this:

The DSWG should also work closely with all other working groups, as well as Drupal Association staff, in order to determine overall needs and priorities for

So long as the DSWG is working closely with the infra WG/team to determine infra's needs/priorities (and in some cases, available resources), that's key. We don't need to more formally define that aspect, and I agree that the hard-requirement for coordination and agreement is on actual deployment.

However, I still think it'd be valuable to somehow formalize what happens when these two groups can't agree on a certain change.

Meanwhile, here's a minor patch to be consistent about referring to websites (plural), since that's clearly the mandate of this group.

Finally, when responding to my questions about if I'd be an appropriate member of this group, please focus on the aspects of the different hats I wear, possible conflicts of interest, etc, not the fact that I periodically take a few months off to be a professional musician, sometimes completely offline for a few weeks at a time. ;) That's a great reason for me to *not* be on this (or any other) governance body, but it's not an interesting one for this discussion.


Dries’s picture

Committed the patch in #19 to Git. Will try to answer your other questions shortly.

tvn’s picture

I like recent changes and addition of individual teams with authority to make decisions in specific areas.

My concern/question is kind of in line with dww's comments on "enforcing" the decisions made. So SWG prepares yearly feature roadmap/plan. Who is responsible for it's execution? And what exactly budget provided by the DA means for SWG? Is it a budget for hiring contractors to implement the feature plan?

sdboyer’s picture

read the new draft. it takes us in a better direction, i think, but but it lacks some key specificity. IMO, this should be the group that keeps the overall process of *.d.o maintenance "on the rails," but the description above is more like "this is the group to figure out the process to keep maintenance on the rails." we don't need an exploratory committee, we need an action committee. and while we cannot possibly expect that we come up with a fully detailed plan/set of responsibilities for this group before it is convened, we can do more than the outline that we have here.

in reading over dww's #15, i think this echoes at least some of his concerns, even if i call it "execution" instead of "enforcement."

i think a more detailed plan strive to define:

  1. what different types of changes there are to
  2. what the steps are, from initial proposal to final deployment, for each of these types of changes
  3. who is responsible for carrying the idea along at each step of the process
  4. how the different groups we have are interacting in the context of this process
webchick’s picture

Do you have a suggested patch to the current wording?

dww’s picture

Agreed with #22. I put "enforcement" in quotes in #15 -- "execution", "action", "getting things done", whatever you want to call it. :)

Of course, this group of people isn't going to personally carry out each step. But they should be able to clearly define each step and maintain the process, making sure we have enough of the right people available for all the aspects of getting things done. This group should be responsible for keeping the whole thing moving, unsticking projects that are hung on some key step, reallocating resources if needed, putting out the word for what volunteer help we could most use at any given moment, etc.

They should also ensure that the process is fully documented and easily understood by anyone who wants to contribute, including the criteria used to make decisions at any given point.

All of that sets the group up to actually be making decisions, since there's a framework to decide and a structure to put those decisions into practice. I know we're getting a bit out of the realm of governance and into an "executive committee", "steering committee", whatever you want to call it. But I think that's key, at least for this particular body. It needs to be able to see its decisions carried out and implemented, or there's no point deciding in the first place. I see that the term "steering committee" is already in the draft, but only with respect to the subteams it appoints. Maybe it should be broader than that. It's more the steering committee for making changes to *, period.

I can't wordsmith these thoughts into a specific patch right now, but some of this comment could be used to flesh out the scope or duties sections if people agree.


dww’s picture

Apparently this was all decided and resolved without really answering my questions and concerns:

This issue should now probably be marked fixed, but I don't want to be the one to do that. I'd rather someone actually tried to answer the questions first. ;)


sdboyer’s picture

no, needs review is good. if i were feeling particularly snarky-destructive, i'd even bump to 'needs work.' the summary on the association announcement especially seems to reflect that it's the "committee to form a committee to do the work," as opposed to the "committee to do the work." i've got some hope based on the names i see there, but that doesn't make the stated scope any less concerning.

i suppose it's on me that i didn't put up a patch to the wording...though i think that may have been because i wasn't sure how to write a such a patch without just starting from scratch.

holly.ross.drupal’s picture

Sorry guys - I did not realize we hadn't come back around here to try and close up this thread. We tried to get really specific in the slide deck about how exactly things would work, but I see we did not address your concern as clearly as we could have, so let me see if we can do that here.

In summary Sam, as you say in #26, it's not a Working Group that will execute all the decisions it makes. I think of the work these Groups will tackle in two buckets:

1. Policy and procedure clarifications/definitions. In other words - these Working Groups will be the arbiters for questions about what we CAN do on the site and HOW that work should get done. The work here will be researching the issue, developing a proposal, making a decision, and then communicating and enforcing it. This work is all the work of the Working Group members.

2. Internal Projects and Business Projects. The Working Groups will develop a plan for each year that details what projects should be undertaken for *.D.O. This could be a new feature to better serve a particular audience (Business Project), or it could be automating some infrastructure process (Internal Project). The Working Group members need to look at all the work that COULD be undertaken in the year, and align that with budget and resource availability to decide what to actually put in the plan. In other words, if the Software Working Group wants to implement FANTASTIC FEATURE Y, they should only include it in the plan if the Working Group knows that it can be built. There are a few ways that the actual work can get done:

a) By working group members themselves. Though I think we would all prefer that they spend their time on the strategic issues, and not in implementing the code.
b) DA Staff. Obviously, we've only got Drumm and Tatiana right now, but our single biggest focus in 2013 is defining new revenue streams that can support more tech resources for *.D.O in 2014. As we grow this team, we can handle more work internally to support the Working Groups.
c) Hiring developers. Working Groups will work closely with the DA to acquire the budget they need to achieve their goals. If we don't have staff expertise or availability for a particular project, we can try to budget for a developer who can make the project happen.
d) Volunteers. It's also possible that certain projects will have a volunteer champion willing to tackle the heavy lifting, though we should have strong plan-Bs in place for volunteer projects, because stuff happens.

So that's how we envision the work actually being handled. How does that sound?

sdboyer’s picture

thanks for the clarification, Holly.

So that's how we envision the work actually being handled. How does that sound?

somewhat better, and while i genuinely do wish i could say i'm content, i'm not. here's why:

Policy and procedure clarifications/definitions. In other words - these Working Groups will be the arbiters for questions about what we CAN do on the site and HOW that work should get done. The work here will be researching the issue, developing a proposal, making a decision, and then communicating and enforcing it. This work is all the work of the Working Group members.

it's good that this lists out the steps that there are to seeing something through from an idea to implementation. it's bad that this does not specify how those steps are to be handled, whose responsibility a given issue is at any given point in the process, and how handoffs occur in between the steps. without specifying these things, we are likely to fall back on the patterns we always have: requiring insiders, with insider knowledge, to champion an issue through the organic, underdefined, and generally opaque process that is getting something done on d.o. what you've described formalizes the cadre of insiders charged with the responsibility of doing that. which is actually not a bad thing - my whole objection here is that the process is not explicit enough, and formalizing the insiders makes it more explicit. it's just not enough.

my preference would be that we define the process, from ideation to deployment, explicitly and publicly (which may entail building/using some new systems to really make that clear, public, digestible and discoverable), then have the role of this group being well-defined in the context of that process. asking this group of people to continue figuring things out as they go along places the same numbing, burnout-inducing responsibility on their shoulders as we've always had.

moreover, without defining the process, we have no idea what steps in the process are our constraints (which does NOT mean they're not there - just that they're hidden). consequently, we have no ability to target specific steps in the process for improvement. and improvements made to any step that is NOT a constraint will only give the illusion of increased efficiency. yep, i'm talking about this.

dww’s picture

Thanks for the clarification, Holly.

Thanks Sam -- #28 is a great summary of remaining concerns I share. To quote myself from #24:

Of course, this group of people isn't going to personally carry out each step. But they should be able to clearly define each step and maintain the process, making sure we have enough of the right people available for all the aspects of getting things done. This group should be responsible for keeping the whole thing moving, unsticking projects that are hung on some key step, reallocating resources if needed, putting out the word for what volunteer help we could most use at any given moment, etc.

They should also ensure that the process is fully documented and easily understood by anyone who wants to contribute, including the criteria used to make decisions at any given point.

Fundamentally, this group needs to be about clearly defining, documenting, optimizing and maintaining the process for getting things done, including the criteria by which decisions are made at each phase. Some of those criteria can involve: "do we have the resources for that?" and "does this fit into a coherent strategy?" (although those aren't the only ones). But what was in the draft here, and what was publicly announced, was not that. It's currently formulated as the group to assign groups to figure out this stuff on the fly in their own distinct parts of the site, and to try to herd all those subgroups into a coherent plan. Coherent strategy/plan is important, and formalizing who comes up with it is good, but I think leaving it at that is really missing a lot of the pain points we've had up until now...


tvn’s picture

I think that both of you are right that we need clear and better documented processes. And I think this is one of the tasks for this Working Group. It might be not so prominent in the charter, but:

Architecture: Establish processes to ensure that we can efficiently make..

Development and Maintenance: Provide guidance and processes to ensure the smooth running of...

(Note as for the the rest of the charters, human-readable copy is located at

sdboyer’s picture

@tvn - i'm sorry to keep beating a dead horse, but...

yes, we all agree that we need better process. my frustration is that rather than defining the process first, THEN establishing this group to adhere to/enforce/ensure that process, we established the group, and are now expecting the group to define the process.

if the first action of the group is, in fact, to establish a clearly-defined process that meets or exceeds the criteria i/others have repeatedly outlined here, then great. otherwise, it's just more kicking the can down the road.

let me also be clear that we should not, in ANY way, be hamstrung by using d.o-based tools in order to get this process right. if our dog food is tastes like shit, then we need to own it. there is nowhere more important that we own it, in fact, because going somewhere else for d.o process is the single way most likely to ensure that we improve process ON d.o in general. not only could it make the change management process for d.o less onerous, but if we use an external service, it'll be an injection of fresh ideas. otherwise it's like we're sitting in a pile of our own filth, whining about how disgusting we are, but refusing to clean ourselves...except with the same old filth-ridden bar of soap.

sorry, just woke up. apparently today is gonna be a colorful day.

tvn’s picture

if the first action of the group is, in fact, to establish a clearly-defined process that meets or exceeds the criteria i/others have repeatedly outlined here, then great.

As a part of this group I can assure you said process is on our to-do list. I do not expect us to magically fix the current situation with D.o development in a week, but we'll be working on improving it and towards that clearly-defined process.

tvn’s picture

Issue summary: View changes


webchick’s picture

Issue summary: View changes
Status: Needs review » Fixed

Doing some clean-up of the queue.

This charter was committed, the group was chartered, and one of the many things this group is working on is indeed defining the development process and establishing leadership for various areas of the site. Therefore, I think it's safe to call this fixed, but if there are specific concerns about the charter itself, please file a patch, and if there are specific concerns with the D.oSWG itself, please let us know either in or in

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.