[Grassroots-l] Information flow problem

Bastien bastienguerry at googlemail.com
Thu May 14 06:12:29 EDT 2009

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 <sverma at sfsu.edu> 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 (marketing at 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


More information about the Grassroots mailing list