[Marketing] [Grassroots-l] Information flow problem

[Frederick Grose]

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/organizacionabiertaoriginal
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/marketing/attachments/20090514/58e6f693/attachment-0001.htm