[Grassroots-l] Information flow problem

[Sameer Verma]

On Thu, May 14, 2009 at 3:12 AM, Bastien <bastienguerry at googlemail.com> wrote:
> 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.
>

+1

> 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.

The first step, as you said, is in defining roles. These need to be
clear, even if they overlap (which is the case in many scenarios). The
second step is to have a person behind the role. That problem is not
fixable via technology :-) However, if the first step is done right, I
think it helps with the second one. For example, at OLPC-SF we have
had a problem for a few months. After the SF hippie style (ie
freeform) meetings were over, we really didn't know why we should be
meeting! We had done mesh, distance, solar, etc. and now had a sense
of "I want to be doing something" but didn't really know what. One of
our members, who has a strong background in marketing and product
management suggested that we make a list of potential projects and
prioritize them. Then we put these up on a flagpole and see if they
flutter. Sure enough, the energy has come back, with renewed focus. We
now have a list of things. Next, we intend to have a series of "Start
here" type guides so that newbies know what they are signing up for.

http://wiki.laptop.org/go/OLPC_SanFranciscoBayArea#Projects

cheers,
Sameer
-- 
Dr. Sameer Verma, Ph.D.
Associate Professor of Information Systems
San Francisco State University
San Francisco CA 94132 USA
http://verma.sfsu.edu/
http://opensource.sfsu.edu/


>
> 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
>
> --
>  Bastien
>