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.



















Thank you very much for the excellent and useful subject. alışveriş
There are a few different web conferencing tools available for use and they all have different features. The key to finding a compatible system is to really think about the types of things you want to be able to do during your gotomeeting linux meeting or conference. Are you going to need to upload any type of visual presentation with sound? A well organized meeting or conference requires many documents and a good agenda, and everyone will likely need access to those materials. You should also remember that not everyone is using the same type of computer. Be sure to pick a GoToMeeting system that can share materials across Mac and Windows operating systems.
Big API Change is similar to the UX team work .
Free Movies Online