Too Many Cooks in the Kitchen!

MGParisi's picture

Improving and its sub sites can be difficult if not impossible at times. Solving small issues with any project are usually easy. However I have noticed that dealing with larger more complex issues (many of them presented in the Prairie Initiative) become very hard to implement because everyone has an opinion on how it SHOULD be. If a solution is presented a single individual has the ability to drag out the problem simply by continuing the debate.

I think debate can be healthy, but some issues have existed for a very long time (YEARS) and no solution will make everyone happy. Doing large scale changes by committee is a major issue in the rapidly changing CMS environment when the Committee acknowledges an issue, but no solution is "good enough".

Simply put there are too many cooks in the kitchen. We need the Green Light to go ahead with a project and then find a small group of people to get it done. It may not be the perfect solution, it may even end up failing, but the failure to act is almost always worse then failing while acting.


I agree wholeheartedly. I

theresaanna's picture

I agree wholeheartedly. I think we've all seen this type of thing happen time and time again.

I wonder if it wouldn't be worth exploring making the project more "official", sort of in line with this concept of initiatives that Dries has talked about for D8. I, too, have concerns about some major bikeshedding in this initiative and good plans never getting implemented.

I suppose that Leisa would know best the likelihood of this manner of project and what it would entail and the best ways to go about it!

Agreed, to an extent. I don't

davidhernandez's picture

Agreed, to an extent. I don't think anything should be above open discussion, and don't think anything should be decided behind closed doors, but there is a lack of movement on so many issues. We need more admins or committees that can participate in/watch discussions, but at the end of it make actual decisions and move ahead with a project.

Time limit on comments to new proposals

tsvenson's picture

Maybe one way of getting around this, while still allowing a free and open debate would be to set a time limit on how long the community has to come in with comments. Lets say it could be something like 7-14 days depending on how big the change is. Then the comments in the official post is closed and the initiative owner does the adjustments.

It might also be needed to combine it with guidelines about that just say "no" is not enough, members need to come up with good reasons to why they are against it or an alternative solution.

This way there will be defined "rules" to help speed up these things.

T: @tsvenson | S:

Openness + Decision making

leisareichelt's picture

This is an interesting and important discussion.

I'd love if this initiative was made more 'official' and if someone like Dries helped make A Big Deal about it so that we can try to get a big blast of activity/interest from the community at the point that it is most needed which is right about now, rather than at the point when we're just about to try to get things implemented which is where it is least helpful (if not simply because people jump in and comment on the implementation without understanding the back story and rationale).

I have no idea how we might make this happen and, frankly, I don't think it's my place to jump up and down and say This Is An Important Initative That Requires Attention. I think I'm already saying that just by trying to drive this forward. If people agree that this is the case, then they need to help draw the attention of the relevant parties. If that makes sense.

I am approaching this project with a view to trying to get to implementable and achievable change relatively quickly, while taking the time to properly understand the problem from a range of perspective and as systemic issue (not something an interface change here and there can fix). I am hoping that by devising a 'framework' around the problems that we're solving here we'll be more able to make it evident why the approach we are taking is the correct one (or as close to that as possible), and that it's not just a random, subjective thing we'd like to do. I know this is far from bulletproof, but I'm hoping it will help.

I'm not at all clear on how we're going to resource this (from a development perspective that is, who's going to write the code) or what the 'approval process' might look like (if it's anything different to usual). It would be interesting to get some buy in from Dries and others who look after the D.O infrastructure, (and other relevant parties i'm not thnking of now) as to what this might look like.

My approach to doing design work with the Drupal community has always been to be as open as possible. I feel like we're moving the furniture around in people's loungerooms when we make the changes we're talking about in this project, so to not involve people in the design process is nuts. I think I'm gradually getting a little better at trying to facilitate this (thanks to a couple of years of experience!)

For me, the biggest problem is how many people won't find out about this project until the granular changes start filtering through the issue queue and into reality - then they'll react to the various implementations in isolation rather than understanding the entirety of the challenge and how that 'piece' fits into it.

This is part of our design challenge for this project, but how we can attempt to overcome it in the meanwhile... I think is initially mostly about promotion - getting the word out that we're working on this and how significant it could be - and then later, if we do start getting bogged down and need it - look at implementing some kind of 'leadership' system to enable good ideas to get pushed through and reducing bikeshedding.

So, action points:

help get the word out to ppl in the Drupal community - not only those active in the issue queue but those who should be and are not.
talk a little more about whether we should/want to 'formalise' some leadership in this initiative and perhaps talk with dries about it.


leisa reichelt -

One small avenue to get the word out ...

eliza411's picture

User groups are one way to get the word out to people who could be active in issue queues but aren't ... the Portland group has newcomers each month as well as regulars who don't participate in the queues. I've seen a fair amount of support traffic on the PDX group site from people who have articulated that they feel far more comfortable seeking help from people whom they've met in person.

We'd be happy to reach out to our local community both via Groups and the meet-ups. I suspect there are other user groups that would as well.


Michelle's picture

I do think this is a big problem. Not so much too many cooks as the fact that every cook is the head chef. One of the reasons I don't get too excited about big initiatives is that I've seen so many attempts to make change die a slow death of No One In Charge. Lots of great ideas, sometimes even people willing to implement them, and then the endless debate of should we or shouldn't we and maybe green is a better color...

I've run into this on a smaller scale as well. I'll see someone on IRC trying to accomplish something and they don't know the procedure and maybe don't have the community connections so I'll use mine to try and help them and just run into dead ends because no one knows and no one wants to make a decision.

It's extremely frustrating and a big part of why I don't venture out of contrib much these days. In contrib, there is always a clear project owner to make the final decision.


My blog, mostly about Drupal: Shell Multimedia

Totally agree, and would like

naught101's picture

Totally agree, and would like to add to the comment noise, in order to make sure that nothing eventually gets done.
blah blah blha

[my one valid point]There's a poll function there, use it. Obviously it's not a valid decision making tool, but a straw poll can be valuable on the path towards a decision[/my one valid point].

blah blah noise, nonsense blah

ahem CVS replacement

Dave Reid's picture

ahem CVS replacement selection process ahem

The distributed version control system selection process involved a large amount of people, and I can't remember if the Drupal Association had selected Angie to lead the process or not at the beginning. The important thing is that we have people who step up to lead. And when I say lead, I mean they are the ones who listen, evaluate, and then make an informed decision. They don't order people around to do things. This is also how core development happens. Dries doesn't tell me to 'patch this core bug.' I patch it, post the results, Dries evaluates and makes the decision if it's acceptable or not. We are at our best when the community participates in the decision-making process, and when we have the leadership that leads not by dictatorship, but by evaluation.

Senior Drupal Developer for Lullabot | | Gittip me!


Michelle's picture

Not really a fair comparison. It's my understanding that git was chosen primarily because that's what the people willing to do the work wanted to use. But what if it wasn't a lot of work? What if it was just a matter of pushing a button to switch to git or to bzr or anything else? And what if we were still on CVS in 2020 because there were enough vocal people wanting bzr to keep the people wanting git from having a true consensus and there was no one empowered to Just Decide Already and those who had access to the button said it was up to the community to decide? How many people would have given up in frustration and just moved to github by then?


My blog, mostly about Drupal: Shell Multimedia


MGParisi's picture

Techniques for consensus decision making in large groups: the spokespersons council method

Owner of Toastyart a Drupal based High Quality Art Gallery.

Prairie Initiative

Group organizers

Group categories

Prairie tags

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week