The design mailing list is proving to be very successful in my view as a way to gather input about Chandler. There are a lot of sympathetic, sharp-eyed, clear thinking folks who are making valuable contributions by asking questions, raising issues, making suggestions, and engaging in a critical thinking process. So, first of all, thank you.
It's clear there need to be additional forums and structures through which to coordinate the design process. No would argue that a mailing list is sufficient. As the pattern of recurring questions becomes clear, we will publish one or more periodically revised Design FAQs on the web site. Following usual net protocol, readers are advised to check there first to see whether a question has been answered or a suggestion made.
Using a Wiki to gather comment also sounds like a good idea if the details can be worked out. It would be possible, for instance, to start with a topically-organized outline covering the functionality of Chandler itself (e.g. it would have nodes for topics like replication and synchronization, serverless calendaring, Web and PDA access, etc.) in a then add comments. One aspect which has to be thought through are read/write/edit permissions. The Wiki we use internally is completely open to everyone. I think some kind of moderation and/or editorial control would be appropriate, but I'm not familiar with what the Wiki (or other tools) afford.
It also seems like a good idea to collate and summarize major feature requests and themes of the list. Ideally, each summary point could point back to the posts and./or threads where it was raised This project may have to wait until (1) there is someone who can do this, and (2) there is a tool which makes it easy to do.
I think it's important to maintain some distinction between the "what" and the "how" of Chandler functionality, with more the "what" on the design list and more of the "how" on the dev list. It's not possible or desirable to make a bright-line distinction between the two, but nonetheless, I am going to start suggesting certain conversation be moved from design to dev if they get immersed in the technical details of the best way to achieve a particular result.
Finally, you may notice this piece appears both in my weblog and on the design mailing list. I will occasionally cross-post. The weblog has a broader audience than the design mailing list, and it's a way of bringing aspects of the design discussion to a wider audience.
OSAF is covered in the New York Times of Monday, October 28. Said one expert "I haven't seen any evidence that there's a hole in the market here," he said. "But all the rational people have been completely wrong about most of these markets. So the fact that this sounds loony is probably a good thing."Posted by email@example.com at October 27, 2002 08:57 AM