Sounds interesting. It's a useful first step. IMHO the second step is to attribute clear responsabilities to real human beings: who does what when it comes to sending/receiving information.
I helped with maintaining the OLPC News page on the wiki for a while. It was not clear who was in charge of this; now that I declined doing it, it is still not clear who have to do it. Sameer Verma <[email protected]> writes: > Information flow is a critical problem for any organization. Some > researchers even point out that an organization is shaped by how > information flows within and outside of it. Free flow of information > builds networks. Restricted flow of information builds hierarchies. In > the OLPC context, information flow happens over several channels: > mailing lists, IRC, Talk pages, Wiki pages, phone calls, RT, > face-to-face, and IM (did I miss anything?). We all have preferences > for channels and applications. One can largely divide the channels > into synchronous (IM, Phone, etc) and asynchronous (e-mail, wiki) and > the applications that support these channels. We also tend to have > preferences for applications: wiki, forum, mailing list, IRC etc. > Then, there's the element of public vs private conversations. As a > researcher in Information Systems, I find these problems very > interesting. > > Two problems arise: > 1) too many channels (example: if I wasn't on the phone conference, > I'll miss out the details via IRC) lead to lack of critical mass and > fragmentation > 2) The application (wiki or IRC or mailing list) is a hammer and every > problem looks like a nail that it can fix. "Throw it on the wiki" is a > source of a lot of misery! > > Then there is the element of fashionable social networking (flickr, > twitter, tumblr, etc)...as if e-mail, IM, IRC, and chatter at cafes > aren't social networking! That topic is for another day :-) My > approach is that we figure out the problem first, and then find a tool > to fix it. Activity centric as opposed to application centric. Sound > familiar? > > So, this semester, I worked with five of my graduate students who > undertook a Information Systems Analysis and Design project to analyze > the OLPC information flow problem and come up with some design > concepts. All the students were new to the problem. This was useful > because their perspective was quite new and they asked some very good > questions. > > They used phone interviews, e-mails, in-person interviews, and > observations on the mailing lists, phone conferences, and the RT > system to gather data. A huge thank you to Adam Holt, Seth Woodworth, > SJ Klein and a bunch of other who contributed and facilitated. > > In brief, they have pulled together the following: > > A general problem mind map (Freemind) > Context map (Dia) > Data Flow Diagrams (Dia) > Entity-Relationship Diagram (Dia) > Prototype (Drupal) > Report and presentation (OpenOffice) > > Their semester ends next week, and the report and presentation are due > on the 21st. However, given that SugarCamp is this weekend, we'll try > to post bits and pieces on the wiki in the hope that it will help with > some of the discussion (market...@sugarlabs cc'd). In the spirit of > keeping things open and generative, we have decided to release the > documents, slides and diagrams under a CC license and also release > source files to make modifications easier. We've also stuck with FOSS > titles and open formats for all documents - this was a bit of a > struggle because some of the tools are not as mature as their > proprietary counterparts (Dia vs Visio) and the students were a lot > more familiar with the proprietary ones (Visio vs Dia). > > There are some unfinished pieces, which will hopefully be worked on in > the next few months to add better definition to the overall flow of > information. Stay tuned to this thread for updates. > > cheers, > Sameer -- Bastien _______________________________________________ Olpc-open mailing list [email protected] http://lists.laptop.org/listinfo/olpc-open
