| Here's another one: One take on why it's important that Chandler is a platform Q In general in the Slides 13-17 section and in the associated slides, you have used tasks, bugs and issues. Would it be appropriate to change these to something else? I think it may be harder for someone that is not a developer to see the ideas in the slides and the text. A Okay, maybe just Shared Documents and Shared Project manager? I wanted something that tracked fairly low-level things. I guess it's one of my own pet theories about High-level managers, is that they don't have very good visibility into bottom-up realities (ie. bugs). If there was a way for people up the chain to get real-time overviews of low-level things like bugs, it would give the executive summaries they're used to a little more depth and nuance. Re: A While high level people should be more concerned about low level items, it may not be possible for them given they have to be aware of so many different projects. They are only human after all. Often the issue is too many levels of management between the top person in the hierarchy and the people doing stuff. That's my experience at least. I think for a CIO, they are probably tracking their own tasks, and project from their various managers. They may have one or two projects that are currently the hot items for them, ones that they are getting pressure from the Chancellor, state government officials, or faculty. Re: Re: A Re: slides 14-17...A caveat on what I said earlier, I wouldn't expect a CIO to be tracking progress on individual bugs. The idea is more that by pulling together information from disparate sources, Chandler allows them to easily review the overall status of ALL bugs in relation to different project areas. The assumption is that a lot is lost when bottom-up status is dumbed down and encapsulated into a written executive summary. But what if Chandler could pull together bottom-up, data-driven high-level summaries that were higher resolution, yet easily digestible? What if higher-level managers could use high-level views of low-level issues as a supplement to their executive summaries and status overviews? ie. You know Project Part A is due in 3 weeks, it would be nice to see that you actually have 4 weeks of bugs still open for Part A. You know Project Part B is going to have a long release cycle, but looking at the bug list, there is really 1 huge bug that everything else is dependent on. How can you decouple dependencies such that the success of Part B isn't bottlenecked by that single bug? etc... Such views don't really exist today, so I can understand how this might be too difficult to convey in a short presentation. Here's an example that might help: http://www-personal.umich.edu/~mejn/election/ How do these illustrations (especially the ones lower down in the page) better represent election results than the following written executive summary: Bush won with 28 states and 254 electoral votes. Kerry lost with 20 states for 252 electoral votes. Are you familiar with Edward R. Tufte's analysis of the Columbia Shuttle powerpoint presentation given to higher-ups at NASA before the launch. His thesis is that the powerpoint format actively made it harder for people to understand the seriousness of the problems being described. More specifically, the text-based, summary-based, linear structure of powerpoint presentations makes it almost impossible to overlay related issues. As a result, individual problems that seemed "not-so-bad" when presented in isolation turned out to be "critically dangerous" when taken in sum. But the structure of the presentation itself made it hard for both the presenters and the reviewers to see the causal relationships, the very chain reaction that ultimately did the Columbia in. http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001yB&topic_id=1&topic=Ask+E%2eT%2e This is my personal bias wrt why people should care that Chandler is a platform. It's not just that outside developers will be able to customize Chandler to meet particular personal and organizational needs, but that the aggregation of the community's efforts will result in:
On Sep 16, 2005, at 2:59 PM, Mimi Yin wrote:
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
