The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

Mini Drupal cycles

Submitted by nk on Fri, 2009-11-27 20:38

Continuing my previous post here are some ideas on how could Drupal development process happen in the future. Let's say on January 1 the UX team begins to work on a design. As reusable UI patterns are part of the framework, I am not specifying whether they work on the framework or the product, they work on better user experience. Their goal is to come up with wireframes, getting feedback and getting some simple mock/skeleton implementation. Basically, express their ideas, get feedback, act on the feedback and finally come up with something that can loosely guide the implementation. Come April 1, the main body of core development is asked to turn their attention on implementing them. To emphasize this, the framework will enter a 'slush': only cleanups, speedups and the changes necessary for the design enter the framework during the next three months. On July 1, the cycle starts again -- and the product enters a slush.

Hopping back for a second to the first three months, of course it's not like we seal the UX team in a room for three months and they can't come out until they have a formal specification. For one, we don't formal specs also communication between the framework people and the UX people is very important so that the framework people can lay some grounds for what the UX team will likely need and the UX team wont go to places where the framework can't go yet.

On April 1 while the mass of the implementors are busy on realizing the UX ideas, the deep framework people began to ponder on the Next Big API Change. Their work is remarkably similar to the UX team: express their ideas, get feedback, act on the feedback and finally come with something that can loosely guide the implementation. And indeed, on July 1, the main body of core development turns to implement these ideas.

It really should be clear that we won't tell anyone what she should work on. We ask the community to focus their attention on a few things. Things, and not just one thing because it is quite possible that multiple projects will emerge from the pondering phase. That's just good. So everyone can still work on what they find fun. If they are working on what's not in focus at the given time they will be politely told that the other half (product or framework) is in focus right now and we will get back to it in due time. My hopes are that we can lure more people into core development because If you are working on the framework you do not need to update your patch to keep up with the product changes and vica versa. Also, some guidance is helpful so people can have a sense of where we are going and whether we are already there. Also, we might be able to lure in domain experts if we can put out explicit lists of things we are working on.

Finally note please that all this is already happening, I am just giving it a little bit more formalization. For example, the early menu discussions were such, there was a design sprint for field API and there was a design period for D7 UX too.

Ps. One such six months cycle is not a release, more like 2-3 of them.

Commenting on this Story is closed.

Submitted by Anonymous on Sat, 2011-12-10 09:48.

chx, i agree 100%.

What is missing (from my point of view) is just coordination.

With coordination, i do not address orders people should obey, but coordination in the sense, i can get the information i need easily:

What initiatives are on their way (i think it is not possible to find this information easily)?

Where and how can i address requirements towards the initiative or my need to figure something out with this inititiative? Now way in the moment - things are too far away spread around: initiative pages, blogs, chat, repository, issues …

When will each initiative / team decide and 'release' their stuff? What is on the roadmap of the initiative?

For your example:

I like a list with all initiatives (could be part of groups.drupal.org)

and i like a coordination of the decisions of all teams: like we are going to change the api and the other team is going to change the UX, so the effort to implement the UX changes has to be done only once.

I like to see more efficiency, without loosing the freedom of each person.

-> so i think we need roadmaps and coordination / discussion between the teams to implement these roadmaps.

And also a beat for the meetings, decisions and 'releases' of the different teams would help a lot.

In the moment the 'beats' for all teams are the releases of drupal core - and these are a too low frequency tao organize what I and perhaps you have in mind.

So how can this become reality?