[IAEP] Group Protocols that support group learning and learning communities

[David Farning]

On Thu, Apr 23, 2009 at 9:55 AM, Caroline Meeks
<caroline at 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
> Caroline at SolutionGrove.com
>
> 617-500-3488 - Office
> 505-213-3268 - Fax
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>