To repeat Mimi's point about welcoming proactive ideas, we're definitely open to proposals and ideas from any interested party -- a good idea is a good idea, whoever proposes it. ;) Just as we would do with code submissions, we want to make sure that any design proposal has merit and fits with the overall goals and design of Chandler before adopting it. As Mimi mentioned, we're trying to work out a process that allows for collecting a variety of ideas, and then evaluating and iterating on those ideas. The process for incorporating design ideas will differ from the processes we will use for patch code submissions.
Sheila just sent out a request for participation in brainstorming and prioritizing calendar enhancements in 0.7. It will be our first attempt to use the wiki in conjunction with the list as a way to flesh out design issues. We'll see how it goes :o)
I think sometimes design list discussions will have to be more "time- based" or proceed in phases that are set by a moderator. (As we did for the Branding exercise.) For example, for calendar enhancements we are going to first open up the wiki page for people to add their own feature ideas before asking people to prioritize the list. We want to make sure that everyone has an opportunity to contribute ideas before we set about trying to prioritize them.
We will also want to schedule IRC office hours where we discuss issues as a group anything from Brainstorming use cases and ideas to heuristic evaluations and workflow walkthroughs.
In this way, the design discussions will probably feel more moderated and coordinated than some of the Devlist discussions.
Mimi :o) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
