On Thu, Apr 23, 2009 at 9:55 AM, Caroline Meeks <carol...@solutiongrove.com> wrote: > One of the topics in my class at HGSE this semester is the use of protocols > to support group work by teachers and administrators in schools. > > What is a Protocol? > > It took me half the semester to figure this out! It is such a common > practice in schools that apparently nobody bothers to definite it. It is > basically any predefined series of steps that a group would go through to > work more effectively. Its a lot like a lesson plan but for groups of adult > peers. > > One "Protocol" we are probably all familiar with is "Brainstorming" where > you put up ideas quickly without evaluating them, then as a separate phase > evaluate them. There are lots of different protocols to facilitate > different sorts of work and to solve different sorts of problems. The kind > of "problems" they might help with are: > > a few people dominate the conversation; > people just repeat what everyone agrees on already and there are no new > ideas coming out; > conflicts are making people uncomfortable and reducing group effeciveness; > the group talks but there is no work product at the end of the time. > > Why do Educators Use Protocols? > > We were not explicitly taught this answer, its apparently well enough > estabilshed that no one asks this question anymore. In the US teachers have > traditionally been isolated in their classrooms doing thier own practice. > Recently there has been an introduction of "common planning time" across > grade levels and often subect based teams but getting a bunch of people who > have always worked alone together in a room doesn't garentee effective > collaboration. We have used many of these protocols in class. Once you try > them its pretty easy to be sold that they can be effective then unstrutured > meetings or one person in front with a powerpoint meetings. > > Why should we use protocols? > > We have a lot in common with educators. We mostly work alone and > occasionally come together for common planning time. > We want educators to learn from our Open Source processes, we should model > that by learning from them. > We want to understand our users, doing things the way they do it is a good > step. > They work. They can be more effective, fun, interesting and less stressful. > > How can we use protocols? > > First remember its not an all or nothing, its just another option, we don't > have and to use a protocol for everything!
Successful community building is premised on the notion of protocols. Sugar Labs primary protocol is 'Honor the release cycle and keep it on schedule!' A functioning Sugar Labs ecosystem requires many participants all working together to push and pull the necessary bits through the distribution chain. 1. Developers must know and agree on when the merge window opens and closes. 2. Localizers must know and agree on string freezes and ship date. 3. Activity developers must know when APIs freeze so they can update their activities. 4. Distribution and system integrators must know when Sugar ships so they can coordinate and plan for their releases. 5. .... The second protocol is 'Good results beat great ideas!' Good results tend to attract more participants who turn the good results into great results. Great ideas tend to languish in ivory towers and think tanks. The third protocol is 'Make it possible for others to learn something new, do something useful, and have some fun!' People who are learning, doing, and enjoying, tend to attract like minded people. On a less meta level, Sugar Labs also has several protocols which we follow on a daily basis. The over sight board makes decisions based on consensus. If the board can not come to consensus, the Executive Directory has final say. Interestingly, I don't think Sugar Labs has ever gotten to the point where Walter had to use his executive authority to settle a dispute. Problems and reported and tracked via a bug tracker. Because of the large number of new participants we a bit relaxed on this issue. Bug reports often come in the form of mailing list posts. A good portion of the time, Tomeu, or someone else, will ask the ml poster to follow up with a formal bug report to insure that the issues does not get lost. Mailing list discussions should be respectful and useful. Are there any regular contributors who have not gotten a 'Please let this thread lie' request from me? As soon as a thread starts to develop into a flame, I try to ask the participates to wait at least 12 hours before posting a follow up to let the thread settle down. Protocols are interesting in that good ones become invisible. Mel Chua is the master of protocols. She calls it 'Capacity Building.' Basically, she takes a 'good enough' process, simplifies it, and shares it with others working on similar problems. > I did my first practice at Olin last week: > http://wiki.sugarlabs.org/go/April_17_Olin_Play_Session > > If anyone presenting in Paris would like to try some group protocols to > facilitate group work around thier topic rather then, or in addition to, > doing a stand in front of the room presentation please let me know. I'll > bring my books of protocols and we can see which ones might fit. I'm very > interested in learning how to do this better and will help facilitate for > anyone interested. Yes, I would like to strongly encourage leader and participates to think about how to most effective solve their problems at Sugar Camp Europe. Vote with your feet! The number of required events should be as minimal as possible. fedora did a really good job at FudCon Boston by having attendees vote on which sessions they would like to attend. Sessions are set in several parallel rooms. Participants are encouraged to come and go throughout a session depending how useful the session is for them. It takes surprisingly little time for the community to self select the useful leaders, participants, and sessions. Keep track of time! Sessions should begin and end on time. There is nothing that communicates a lack of respect for your fellow community members like starting a talk 20 minutes late because you were having a private discussion about about what you had for lunch yesterday. End sessions on time. Everything we do is subject to finite resources. We can talk all day about what we want to do. At the end of the day what is important is what we have accomplished with the resource we had available. I would suggest that for this SugarCamp, we focus on these two protocols. Anything else would be cake. david > Resources: > Web Site with free protocols : > http://www.nsrfharmony.org/protocol/sitemap.html > Data-Driven Dialogue: A Facilitator's Guide to Collaborative Inquiry - > http://mivasecure.abac.com/miravia1/merchant.mvc?Screen=PROD&Product_Code=DD&Category_Code=P > > The Power of Protocols: An Educator's Guide to Better Practice - > http://www.amazon.com/Power-Protocols-Educators-Better-Practice/dp/0807743615 > > > -- > Caroline Meeks > Solution Grove > carol...@solutiongrove.com > > 617-500-3488 - Office > 505-213-3268 - Fax > > _______________________________________________ > IAEP -- It's An Education Project (not a laptop project!) > IAEP@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep