[Design] Collaborative design list management and other cross-silo workflows to consider as tenets

[selva r]

That’s actually close to what I was thinking about as a possible aid for collaborative project planning for Chandler.  However, instead of managing it solely by email, I was wondering about the possibility of having a server based edition of the previously discussed “Cactus” or “Tree” application that’s modified a bit to allow for voting of items within the Cactus by Chandler email list members.
 
 For example, a server based Cactus app could have features similar to the previously discussed desktop Cactus app so that ‘Now’ items are say Green color and furthest raised above the background with the largest drop shadow.  ‘Later’ items might then be Yellow color with a smaller drop shadow, and finally ‘Done’ items might be grey color and at the level of the background.  
 
 Again, the background might be branches of a virtual tree or cactus where title bars of proposed Chandler features & solutions are embedded onto, or we could just start with a plain background to get things rolling faster.
 
 If the Now-Later-Done filter is then toggle switched by way of a pull down menu to a ‘Voting’ filter, then this could then allow Chandler list members to vote on the various proposed Chandler features.  
 
 Under the Voting filter, list members could then cast their assigned quota of votes per month to what ever features they deem most important to address first.
 
 Under the Voting filter, those title bars that get the most votes could be depicted as furthest raised off the background with the largest drop shadow and be presented in say the darkest hue of a single color such as red.  Title bars of items getting less votes might be less raised off the background with a smaller drop shadow and be presented in a less intense hue of the same color using a gradient system.  Of course a numerical voting tally of each item could also be included within the item's title bar.
 
 Design list management personnel would then have the responsibility to tally up the voted upon items and decide whether or not to veto some of these items due to reasons not accounted for by the general design list, and then re-classify the Cactus / Tree items each month so that items are continuously triaged through the Now / Later / Done workflow as the branches of the Cactus gradually expand.
 
 Similar to the previous discussions on a desktop Cactus / Tree application, we could present the server based group edition also in tabbed format so that, for example, we could group email items tree on one tab, a datebook items tree on another tab, and so on.
 
 One important issue to sort out here would be who has authority to add items to a server Cactus / Tree app.  Can any Design member add items on their own?  This might result in too much noise to signal ratio problem.  Perhaps items should first be discussed informally in the Design email list first and then the author could then present a final proposal for the item and the proposal should then carry at least two other list members' support before it can be promoted to the web based Cactus application for general voting and triaging.
 
 Functionally, this would sort of be like a wiki but more graphically organized in terms of triaged workflow to help with project planning and also allow for group voting input capabilities as well as vetoing capability by Design management staff prior to actual triaging of items.
 
 A quick overview of the web based Cactus / Tree app also allows Design list members to see which items are currently in the Now box to help orient their discussions.
 
 Cheers,
 Selva

Mimi Yin <mimi at osafoundation.org> wrote: In response to some of the emails that have been flying around, particularly concerning whether we should or shouldn't do certain features, such as free-busy, email or PDA sync, I'd like to propose an alternate way to frame the conversation.


Rather than talking about how technically, we really need to start on email now if we want to have it in 1.0, how about throwing some ideas around for how we could have immediately usable and useful email as a part of a more horizontal or cross-silo usage scenario? That way, we would have some concrete and practical reasons to work on multiple areas of the app at the same time while maintaining a clear end-user focus and goal? 


Below are some examples of what I'm talking about, examples of how we might "get to more users" in 0.7 by going cross-silo and addressing some user needs that currently lack solutions. I offer them in the hopes of generating a wealth of examples through a group brainstorm.


The criterion for this exercise are that the scenarios are cross-application, requiring functionality in more than one traditional application area, but are simple enough that we can attain usability in 1 release.




SOME EXAMPLES:
 

COLLABORATIVE DESIGN LIST MANAGEMENT
Could we as an organization experiment with sharing the Design list as a shared collection?
- Where Sheila and I act as mailing list shepherds, triaging mailing list topics between Done, Now and Later to help focus the conversation? 
- Where people can submit crazy ideas so that we have them recorded and stored in the Later area, but the list and community don't feel compelled to stray away from the topics that need to be discussed Now.
- Where people can look in the Done area for "closed issues". 
- Where people can tag and label emails by topic area and other people can come search through the list for their pet topic (this would require making tags shareable in some way).
- Where we can stamp certain mailing list items that are time-sensitive and put them on a Design list calendar of events or milestone dates. (ie. this brainstorm will end on Friday at 2PM, the Dashboard presentation will take place on the 22nd.) 
- Where we can stamp certain mailing list items as tasks and maintain public, task lists showing how we're responding to the list and delegating responsibility in the community as a direct result of the list. ie. Heikki to look more into short-term PDA strategies 

I think this is something we could all use that would directly help in our efforts to moderate and faciliate open-source design.


SHARED TASK MANAGEMENT
What about shared task lists for collaborative projects. ie. upcoming CSG meeting or PyCON presentation tasks
 - We would want some rudimentary emails to be able to send and receive capital N-notifications.
- We would want stamping to work so you can put tasks on the calendar.
- We would want basic ability to triage tasks

 
SHARED RESOURCE AND CONFERENCE ROOM COORDINATION
Can Chandler be a compelling way for people to share resource calendars for conference rooms and projectors and things. So that you could reserve a projector or conference room and then send an email out to ping whoever needs to be pinged, right from the app. 



I think some attributes that are common to all of these scenarios are:
- They solve some very serious problems that people have (ie. mailing list overload), therefore, the scenarios are compelling enough for real and serious use of the app.
- But the area of information we touch on is not so near and dear to them that the bar for usability is unrealistically high to attain in 1 release (ie. my personal email). 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design



		
---------------------------------
Find your next car at Yahoo! Canada Autos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20051202/73a1155f/attachment.htm