[IAEP] Child in charge of FOSS or Sugar
paperless at timmcnamara.co.nz
Fri Sep 17 18:31:35 EDT 2010
You raise some concerns that I have had. Over of time, I have come to
slightly different conclusions.
On 18 September 2010 01:27, Søren Hougesen <soren.hougesen at gmail.com> wrote:
> For about a month ago, I asked as a curious outsider, if kids were actually
> hacking sugar.
It is almost certainly the case that learners are hacking while using Sugar.
I see less evidence that learners are hacking Sugar itself, but there is a
lot of it: We often receive feedback through teachers. From my experience,
Activity developers are more than willing to incorporate feedback from
My personal feeling is that Sugar Labs needs to have systems that are clear
and consistent.. But responsibility for teaching those systems to learners
should be pushed onto teachers.
In my search for bugging/debugging in Sugar I found the
> ‘BugSquard/Bugreport’ on wiki.sugarlabs and it says:
> “If you're using Sugar on a Stick<http://wiki.sugarlabs.org/go/Sugar_on_a_Stick>or another distribution
> of Sugar <http://wiki.sugarlabs.org/go/Supported_systems> and find
> specific you think could be improved—maybe something isn't working the way
> you think
> it should work, or you have an idea for how something could be better—you
> can file a *ticket. *
> A ticket is a way for anyone to suggest to the software or project
> developers that *they should work*
> on something […]".
> “[The tickets]” is the *most* important part—because reading the title of
> a ticket *is how a developer decides*
> if he or she is going to work on it”.
> I thought it was the child/sugar-user that should *decide on working on
I agree with the force of your argument. Interesting, I think that this
process facilitates lots of involvement.
I feel that our approach is reasonable, because it balances several forces.
For example, some learners do not want to develop software. Making it easy
to receive feedback is important. This explains the emphasis on tickets.
Tickets also centralise the feedback, which helps to avoid duplication.
Also, this quote does not imply that learners are not entitled to become
developers, just that developers do development. Lastly, we operate under a
volunteer model. This means that it's important to recognise that developers
do decide which tickets to fix.
There are other forces at play. I recall one thread on the development list
that said there should not be in-code documentation in order to maintain the
quality of the contributions of prospective developers. The reasoning was
that if individuals are not able to understand the code by reading the
source, then they are not qualified to contribute to Sugar's core.
As Papert says on debugging: “Errors benefit us because they lead us to
> study what happen,
> to understand what went wrong, and, through understanding, to fix it”
> (Mindstorms - 1980 (1993): 114),
> which is essential for learning learning.
> I have trouble seeing the correspondence between the child/sugar-user
> taking charge, debugging
> in Sugar-FOSS as a computational environment and a distant Sugar-developer
> deciding on
> debugging or making improvements. To me the ticket doesn’t look like the
> child is taking charge.
"taking charge" is part of the story. Tickets do allow people to participate
at the level that they wish to. If learners would like to learn how to fix
the problems that, I think their teachers should guide them. I'm not
convinced that Sugar Labs should be in charge of educating learners. I think
we need clear, consistent instructions that can be taught to learners who
wish to contribute.
> I have 4 assumptions about this:
> 1. The BugSquard doesn’t mean that the sugar-user/child can’t be in
> charge and taking control
> and doing own improvements and bug-fixing in Sugar-FOSS- environment. If a
> child wants to release
> Sugar 6.1 then by all means. The BugSquard is just there to help and assist
> the child/sugar-user who
> doesn’t have the technical know-how to do improvements.
> 2. Not everyone can release Sugar 6.1, 6.2 etc. That’s the mission of
> the Development Team. They…
> “build and maintain the core Sugar environment. This includes specifying
> and implementing new features
> in conjunction with the Design Team<http://wiki.sugarlabs.org/go/Design_Team>,
> fixing bugs as they are found by the Testing team and the Sugar community
> 3. Debugging and improving Sugar-OS is different from debugging and
> programming as a learning-process
> *in* a Sugar-activity like “Turtle Blocks”, which is the reason why..
> 4. …it is possible to run Sugar-activities on Windows. It’s not
> possible to debug, improve, program and
> hack Windows (not legally anyway). But you can still debug and program
> Turtle as a Sugar-activity that
> runs on Windows.
> If I’m right about assumption 2,3,4 then children doesn’t benefit from
> Sugar as a FOSS. That’s mainly
> for Sugar-developers and the benefit of changing and reshaping Sugar for
> specific cultural needs i.e.
> languages, national curriculum-adaptation etc., a top-down-proces in a
> specific cultural context, that
> exclude children’s points of view. more like a 'cultural empowerment'.
I don't agree with these three.
2: there are no technical restrictions to new people experimenting with
development builds. There may be restrictions imposed by teachers on
3: I see Turtle Blocks and other visual programming languages as steps up to
other text-based. In versions 44+, it is possible to use Python code in
Turtle Blocks, meaning that the distinctions are increasingly narrowed.
4: Very few Activities can run on Windows. Generally they are were neither
designed for Sugar or Windows. For example, if I understand correctly,
Turtle Blocks runs on the Smalltalk virtual machine - which is independent
from the operating system.
> Last assumption:
> 5. Children benefits from Sugar because it’s a specific designed
> learning environment, but children
> (most of them) couldn’t care less about FOSS, and they are not in charge of
> the FOSS-environment.
> They are in charge of the progamming and debugging Turtle not the
> Sugar-activity itself,
Probably not. Is that important?
Identi.ca / Twitter @timClicks
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IAEP