home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!spool.mu.edu!agate!anarres.CS.Berkeley.EDU!bh
- From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
- Newsgroups: comp.edu
- Subject: Re: collaborative work
- Date: 5 Sep 1992 13:51:48 GMT
- Organization: University of California at Berkeley
- Lines: 22
- Message-ID: <18ae1kINNfln@agate.berkeley.edu>
- References: <20161@plains.NoDak.edu> <67712@hydra.gatech.EDU>
- NNTP-Posting-Host: anarres.cs.berkeley.edu
-
- gus@prism.gatech.EDU (gus Baird) writes:
- >It depends on the objective of the exercise. If you're in a lower-division
- >course where the objective is learning the basic skills, then group projects
- >are counterproductive. [...]
-
- It depends on how you organize and supervise the groups. I agree that if you
- leave them to their own devices each person will do what s/he already knows
- best. But there's a lot of research literature about how to avoid that. For
- example, you figure out subtasks, such as (in the case of programming) making
- up test data, preparing program documentation, etc. Then you do several
- projects and you insist that the students rotate the tasks so that everyone
- does everything once. Another technique is to offer bonus points if every
- member of the group improves on the next test (compared to that person's
- previous test); that encourages the better students in the group to teach
- the others, instead of doing everything themselves.
-
- The trouble I've had is that it's very hard to do this kind of cooperative
- organization in a large class, where I don't really work directly with
- students at all, but only through teaching assistants. Another thing I
- read in the literature is that you should expect a few frustrating years
- while you're learning how to make cooperative learning work well, and
- indeed I'm experiencing some of that.
-