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 <[email protected]> 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 <[email protected]> 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 <[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 > _______________________________________________ > Marketing mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/marketing > > _______________________________________________ > Grassroots mailing list > [email protected] > http://lists.laptop.org/listinfo/grassroots -- Bastien _______________________________________________ Olpc-open mailing list [email protected] http://lists.laptop.org/listinfo/olpc-open
