All Hands Meeting March 11 2004
1. Working Group Summaries. Going forward, we'll ask the working group heads to give a brief summary of what's been going on in the working group since the last All Hands meeting.
2. No All Hands meeting next week.
3. 0.4 Timing. It will take longer than the original 3 month plan since we've expanded the scope of 0.4 to include authentication, access control and sharing. This is some number of weeks of work to develop, then the apps group needs to test and iterate, then we need some UI added, etc. Part of the 0.4 planning process is to get a level of granularity that allows a realistic plan.
So 0.4 will take some amount of time between 3 months and 5 months, sometime in summer. After the 0.4 planning is done, we'll do a general re-plan through the 1.0 release. It may be that the plan of going through 0.3, 0.4, 0.5 and then 1.0 will be reconsidered. It could be we'll do something like the Mozilla project did, where there was a long period of time in the 0.9 timeframe. During this time the releases were not yet at a 1.0 level, but were good enough for to very high numbers of early adopters to use as their default. Chandler may follow this model; it's something we'll need to look into.
4. Development "traction" in general. It seems to Mitch that 0.3 represents an enormous step forward. We achieved our goals for 0.3, with confidence we can do more and better with 0.4. High level goal for 0.4 is to be experimentally usable for some end user tasks around the calendar, plus other stuff. We have a ton of organizational growth to do, but we're on a good path and we have traction. This is an enormous step forward form six months ago. (It is sobering of course to look at the ambitious goals of the project, which we'll have to manage by being very disciplined.)
5. The wiki. Mitch noted that there's a noticeable level of unhappiness with it. We'll need to work on this, but in a way it's a relief that this is what's high on people's minds; it suggests that some more basic elements are under control. We had a discussion about the Wiki which is summarized below.
- A wiki is a single collection of information to which people can contribute without a common (or sometimes any) view of how information ought be organized.
- One person noted a high level of frustration as a user because it's so hard to find anything and docs don't look good. Also a high level of dissatisfaction as a contributor because the wiki loses the formatting of text. It's hard to make text look good or to design them for easy reading when they are destined for a wiki.
- Also, the mechanics of editing within the wiki context are very awkward. The problem with attaching documents to the wiki was also noted, because it's hard to edit them.
- Someone else noted that there are two separate issues. One issue is creating a rational organization of data that can be navigated easily. The other are problems with the wiki itself. We should keep these two things separate, that changing tools won't solve the navigational issues.
- We took a poll about the degree of dis/satisfaction with the wiki and found we have a bell curve. One person noted that it might be possible to improve the experience by helping people to get documentation in the right place.
- We can try some experiments to improve the overall experience.
-
- Identify types of docs that belong in the wiki.
- Create a wiki survival guide and best practices doc at OSAF: how to make the best of it.
- Figure out types of docs may not make sense for the wiki (like product documents) and what to do with them.
7. Discussion of Copyright Ownership and OSAF. OSAF's plan of record has been to require copyright assignment; after research and reconsideration Mitch has decided that this may be a barrier to the project's vitality and is not necessary. Mitchell will write up the results of this and get it posted in the next week or so.
8. Community Working Group has an action item to provide empirical data regarding the current reality of the community. This will help us make involvement with other potential participants How an important input into our planning and working processes.
--
MitchellBaker - 11 Mar 2004