[Olpc-open] [Grassroots-l] [Marketing] Information flow problem

[Bastien]

Just to make sure: maybe I misunderstood Sameer's email.  My point was
about fixing OLPC's information flow management, not Sugar's.

Frederick Grose <fgrose at gmail.com> writes:

> According to http://wiki.sugarlabs.org/go/Sugar_Labs#Principles, participants
> and contributors will.
>
> One problem might be where best to document. The pending reports should help us
> sort out that issue.
>
> === Principles === In order for Sugar to be successful, it needs the
> participation of a large number of people who share common goals while
> maintaining independence, so that each participant has the ability to act
> independently. For these reasons, Sugar Labs subscribes to the principles
> described [http://flors.wordpress.com/2008/05/04/
> the-paradigm-of-the-open-organization/ here], which are the author's own
> translation of an [http://web.archive.org/web/20050317231119/http://
> interactors.coop/organizacionabierta original text in Spanish.] ====Identity===
> = * Clear mission – Fully disclosed objectives. * Declared commitments –
> Affinities and aversions explained. * Declared outside connections –
> Relationships with other organizations explicitly listed. ====Structure==== *
> Horizontal organization – Teams and facilitators work on responsibilities and
> agreements. * Identified contributors – Who is who, people are reachable. *
> Clear responsibilities – Who is in charge of what. * Activities described – All
> of the ongoing work is acknowledged. See [[http://wiki.sugarlabs.org/go/
> Wiki_Team/Guide/Wiki_Structure | Wiki Structure]] for a guide to how the wiki
> models Sugar Labs' structure. ====Operation==== * Open participation – Anybody
> can access the information and get a first responsibility. * Meritocracy –
> Responsibilities are acquired (or lost) based on one's skills, results, and
> contributors’ support. * Voluntary (non-)engagement – Nobody is forced to be
> involved or to keep responsibilities. ====Information==== * Regular reports –
> Reported activities and future plans allow monitoring and participation. *
> Information accessible – Even internal operational information is available by
> default. * Explicit confidentiality – It is explained what matters are
> confidential, why, and who can access them. ====Goods==== * Economic model –
> Feasibility and sustainability plans are exposed. (Please see/contribute to the
> discussion [[Sugar Labs/Funding|here]].) * Resources – Inventory of items
> detailing who contributed what and why. * Public accounts – It’s clear where
> the money comes from and where it goes. * A special [[Sugar Labs/Thank You|
> thanks]] to our contributors.
>
> On Thu, May 14, 2009 at 6: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.
>    
>     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
>    
>     --
>      Bastien
>     _______________________________________________
>     Marketing mailing list
>     Marketing at lists.sugarlabs.org
>     http://lists.sugarlabs.org/listinfo/marketing
>
> _______________________________________________
> Grassroots mailing list
> Grassroots at lists.laptop.org
> http://lists.laptop.org/listinfo/grassroots

-- 
 Bastien