[IAEP] Contents of Sugar Labs 2010 Goals Review

C. Scott Ananian cscott at cscott.net
Sun Jul 18 11:59:39 EDT 2010


On Sun, Jul 18, 2010 at 4:14 AM, Tabitha Roder <tabitha at tabitha.net.nz> wrote:
>> >    * Encourage new people to join our project
> I am an educator.
[...]
> I have come to the conclusion it is perception of olpc and Sugar being for
> technical people. The reason I am now seeing a shift and getting more
> educators and translators is because I am more able to see the ways
> educators can contribute.
>
> The olpc and Sugar wikis are both wikis, that requires a level of computer
> literacy that a lot of teachers don't have. It is not easy to find
> information. It is not possible to make Sugar on a Stick without another
> level up again of computer literacy. I can't just try Sugar on a website, or
> buy a live CD (I learned how to use Ubuntu with a live CD). There is a level
> of hand holding required for teachers to get started. I follow a lot of
> mailing lists and many posts are duplicates of others and written in geek
> speak so I have to ask for help to understand what is going on. The join
> sugarlabs page does not welcome educators at all, it seems to be some sort
> of geek idol, or maybe a metal monster (really, should it be a picture of a
> computer rack?).

This is a fantastic "to do" list for us all, thank you Tabitha!

I've used wikis with non-technical people before.  There's usually an
initial "it looks hard" hurdle, and then they get excited ("it's so
easy to make a webpage").  It depends a lot on the exact type of media
wiki, and even the way things are arranged and how "stylish" it is.
If we use a lot of templates and advanced features on the wiki, it
makes the pages look "pretty" but it can be much more alienating for a
novice user, who opens up the page to see lots of non-text stuff they
don't understand.

So one takeaway from the mediawiki side might be to try to minimize
the use of templates and other "advanced" features, especially on
pages teachers might want to contribute to -- and also to have more
gentle introductions to "how to edit a wiki".  Once you learn it, it's
like riding a bicycle, so we all tend to forget how hard it is to make
that first edit.

Guiding new users to the places they can contribute and having them
make edits to add their information is key.

In the "non-programmer" wiki projects I've participated in, one of the
first tasks is "sign up on the web page", which usually just means
editing a particular wiki page to add your name to the bottom.  This
is an easy way to get people's feet wet in wiki-editing, and once
they've done it once they're more likely to feel confident in making
small changes to other pages.

"Try sugar on a web site" is tricky.  Making Sugar on a Stick easier
to try is an ongoing project that I'm sure lots of people are
interested in helping improve.

Mailing list etiquette is hard.  I think the feeling is that we want
fewer lists so that important information doesn't get discussed "only
among teachers" and the programmers never find out about it.  But,
like you point out, the drawback there is that the mailing lists get
dominated by programmers (who are more comfortable with the medium in
the first place) and then the culture shifts to drive away the
teachers.

I don't have good answers here, but I do have one suggestion: the
http://groklaw.net/ website had a similar culture conflict -- in that
case, between lawyers/legal experts and programmers/techie types.
Following their lead, it might work to have a "teacher-driven" regular
blog, with the content 100% by teachers.  Both programmers and
teachers should be encouraged to comment on the stories, exchanging
ideas.  But teachers can follow the blog to get a "teacher friendly"
view on the project, without being overwhelmed by discussion (unless
they want to drill down into the comments to read it) or duplicate
stories/conflicting information.

It would be a way to provide a lower-traffic moderated
teacher-friendly source of information.  For teachers, by teachers.

> I don't have any answers sorry, but hope talking about it helps us find
> some.

So do I!

[...]
> I can't do everything in Sugar currently. One day I might be able to. As a
> teacher, I need: tabbed browsing, skype, irc, jabber client. I live online
> and every tool is somehow related to collaboration and connection.

As an emissary from the techie community, let me take the opportunity
to introduce a bit of techie jargon.  We call this "dogfooding".  When
a software project is getting really robust and good, and most of the
bugs are out, then the coders can "eat their own dogfood", which just
means that the coders themselves are regularly using the software they
write.  Any problems with the software then become problems which the
coders see immediately and are motivated to fix, because they're using
the thing every day.

Here's another link with a definition:
http://catb.org/jargon/html/D/dogfood.html

One of SugarLabs goals this year was to "eat more of its own dogfood".
 It's a bit contentious in the community, I think partly because of
the coder/teacher culture gap.  We're hesitant to make SugarLabs
"taste to good" to us as coders, for fear that we'll be making
something which is less good for kids and teachers.  Similarly, some
argue along the lines of "Sugar's for kids, not teachers" and so think
that we shouldn't spend too much effort making Sugar good for
teachers.

My personal feeling is that the "low floor, high ceiling" goal for
Sugar means that we can make a system which works for the youngest
kids, and "grows with the kids" so that you can turn on new features
or install new activities to keep raising the ceiling.  When the kid
grows up to be a teacher (or programmer!) they can keep using Sugar --
they're just using different activities.

But whether you agree with me or not, this is an excellent topic for
debate.  I think there are certainly some people who are interested in
making Sugar work better for the things you want to use it for -- and
you've given us a great list.  I *think* that you can actually already
install activities to do most of what you want to do --- but obviously
we haven't made it clear how to do so, or you'd have done it already.

Hopefully someone with more Sugar knowledge can help out here.  Can we
make a "Sugar for Teachers" web page, making it easier for teachers to
do the sorts of things Tabitha wants to do?  (And phrased in
teacher-talk, not coder-talk?)
  --scott

ps. I've only responded to a few of the many great points you raised.
I'm hoping others will take you up on the others!

-- 
                         ( http://cscott.net/ )


More information about the IAEP mailing list