[IAEP] [Sugar-devel] 2017 Goals for Sugar Labs
Tony Anderson
tony_anderson at usa.net
Wed Apr 12 03:09:47 EDT 2017
I am extremely disappointed with the direction this thread is taking.
Based on our experience with the 2016 goals, this emphasis on starting
over will lead to a restatement of the 2017 goals which at the end of
the year will be as close to reality as they are today.
The heart of Walter's document is:
"We have several near-term opportunities that we should leverage:
* Raspian: The Raspberry Pi 3 is more than adequate to run Sugar—the
experience rivals or exceeds that of the OLPC XO-4 hardware, though
not the OLPC NL3 hardware. While Raspberry Pi is not the only
platform we should be targeting, it does have broad penetration into
the Maker community, which shares a synergy with our emphasis on
“doing”. It is low-hanging fruit. With a little polish we could have
an image available for download from the Raspberry Pi website.
* Trisquel: We have the potential for better leveraging the Free
Software Foundation as a vehicle for promoting Sugar. Their distro
of choice is Trisquel and the maintainer does a great job of keep
the Sugar packages up to date.
* Sugarizer: The advantage of Sugarizer is that it has the potential
of reaching orders of magnitude more users since it is web-based and
runs in Android and iOS. There is some work to be done to make the
experience palatable on small screens and the current development
environment is—at least my opinion—not scalable or maintainable. The
former is a formidable problem. The latter quite easy to address.
* Stand-alone projects such as Music Blocks have merit as long as they
maintain both a degree of connection with Sugar and promote the
values of the community. It is not certain that these projects will
lead users towards Sugar, but they do promote FOSS and
Constructionist principles. And they have attracted new developers
to the Sugar community."
Lionel Laske offered this response:
"Thanks a lot for this long proposal. Great to hear you on that.
I think that it's more a Sugar history than a goal/vision but it's good
to read it from a guy that was the major contributor of the history.
BTW I'm not agree with your goals.
My view is that it's not a good idea to limit Sugar/SugarLabs to
makers. We can't target a so small market:
- RaspberryPI ? RPI is a great tool. I personally used 2 RPI weekly for
my personal usage. But it's a tool for geeks not for learners. It could
be a good device as server (we're using it in classroom in France and in
Madagascar and it's good for XSCE too) but it's a very poor tools for
children: no screen, no keyboard, no mouse, not even a power adapter.
It's just a board ! So I don't see the interest of Sugar on it.
- Trisquel ? Probably a nice Linux distribution but how many users ? Not
at all a largely distributed distribution like Fedora or Ubuntu. Why
doing effort on it ?
I can't understand you even mention Windows support in your goals: just
99,9% of the PC market ! So if you're a Windows user you can't be a
target for SugarLabs ? Plus, regarding devices: we should be better on
touch devices because tablets is the favorite learning tools in
classroom today, not PC. It's why Android (80% of the tablet market) and
iOS are so important in my mind. We should go where users -
children/teachers - are !
We can't target makers just because Sugar has synergy with them and
because we hope they help us to spread the world tomorrow.
Our goals should be to deploy Sugar as a mainstream solution for
everyone not a solution for a bunch of geeks. It's the only way to
expand the Sugar community. You told about OLPC: the goal of One Laptop
Per Child was to give a laptop to EVERY child, our goal should be to
give Sugar to EVERY child too. The marketing effort should be in that
way, no need to do marketing for makers, I'm sure they found us themselves.
Lionel.
P.S.: Regarding Sugarizer maintainability, it's just your opinion. Not
sure it's the opinion for 20 others Sugarizer contributors. I don't
think you could judge Sugarizer maintainability only because you've not
successfully updated TurtleJS activity inside. I don't have success
running TurtleJS on my side and had a very bad experience when trying to
Sugarize it, it's not a reason for me to give a judgement about TurtleJS
maintainability. "
Regarding Raspberry Pi, while of the millions in the wild certainly only
a small minority are used for education of primary school aged children,
the same is true for the number used to drive 3d printers. There are
computer labs in operation based on Raspbery Pi with hand-me-down
peripherals. Kids on Computers in Mexico supports several using XSCE as
the school server (the KoC team never even considered Sugar as an option
for the clients). There is a specific opportunity in Kenya where
desktops are being used with hand-me-down peripherals. These desktops
could be replaced by RPi3 saving the difficulty in maintaining old ATX
boxes (and making use of the peripherals where the desktop is not working).
Lionel expresses concern that Trisquel is not well known in our
community. However, the newbies to Sugar are unlikely to have a clue
about the difference between Trisquel, Ubuntu, Debian or Fedora (let
alone Arch or Gentoo or OpenBSD). What is critical is that it be dead
simple to download and install Sugar and that Sugar works reliably.
The maker community has MakerFaires. These are very effective
opportunities to show what makers can do and to invite visitors to make
something on the spot. Adam Holt and the XSCE team have demonstrated
Sugar at several. The idea is that the exhibitor offers an opportunity
for visitors to 'make' - something we can do easily with Sugar. Typical
visitors are school-age children.
I think our single goal is to escape the perception that Sugar is tied
to the XO and establish the perception that Sugar is a viable learning
platform available to the mainstream user. Continuing to tie Sugar to
NL3, Infinity or Positivo (Rwanda) is wrong. We need to make Sugar a
platform available independent of particular suppliers (the Achilles
heal of OLPC).
I think it is easy to understand what is needed to move toward this goal:
Provide an image for the RPi3 which can be downloaded, copied to an
SD microchip, and booted on an RPi3 configuration with an HDMI screen,
usb keyboard and mouse. Sebastian Silva has offered some technical ideas
on how to implement this. The XSCE team is very familiar with this
process in connection with XSCE.
Currently on the website we mention Fedora, Debian, and Ubuntu. At
http://wiki.sugarlabs.org/go/Downloads#Do_you_use_GNU.2FLinux we mention
a potpourri of options including Trisquel. We need to have one. If there
is disagreement with Walter's choice of Trisquel, let's have that
discussion. In the meantime let's release a supported version of Sugar
and document it as the choice on our website.
Sugarizer. We need to work out with Lionel Laske if Sugarizer is an
alternative to Sugar or is Sugar for mobile devices or is the successor
to Sugar. Sugarizer has a unique advantage in that it does not need to
be installed. However, Sugar offers a rich library of activities that
will not be available to Sugarizer without a major investment in
developer time.
It is possible that Turtle Blocks is a standalone project but it is also
a Sugar activity. Making Music Blocks a Sugar activity should not be
difficult. The important aspect is that both add to the educational
benefits offered by the Sugar platform.
I would only add to Walter's document two observations.
One, to attract potential new users and deployers of Sugar, we must
remake the website so that it is easy for the curious to see what Sugar
is and how to bring it to their own computer. To accomplish this, it
must be possible to obtain the current release directly from our
website. We need a user forum and a means for users to report problems
similar to other open source projects.
Second, we need a version for Windows. This is the most likely place
potential deployers will stumble upon Sugar (remember, Negroponte's
encounter). If possible it should be a Windows 10 application. Samuel
Greenfeld suggests Sugarizer as the version for Windows. Sugarizer can
be experienced by anyone with a browser and internet access - including,
of course, Windows users. This user experience of Sugar can be featured
immediately on our site.
This thread needs to become a discussion of how our goals can be reached
in 2017 and the pragmatic steps needed to get there.
Tony
P.S. What is the role of SOAS?
On 04/12/2017 07:22 AM, Mariah Noelle Villarreal wrote:
> Hey everyone,
>
> As promised, I've started the wiki based on the conversation that's
> been happening on the thread. I hope this helps out. I haven't had
> time to go through the 2016 Goals or to add all of the information
> that was presented yet. Any help would be much appreciated!
>
> https://wiki.sugarlabs.org/go/2017_Goals
>
> - Mariah Noelle
>
> On Tue, Apr 11, 2017 at 10:34 AM, Mariah Noelle Villarreal
> <villarrealmn at gmail.com> wrote:
>
> I will take time this afternoon to combine all of what is being
> said in the thread at wiki.sugarlabs.org/go/2017_Goals
> <http://wiki.sugarlabs.org/go/2017_Goals>
>
> This way we can move over to the wiki and add our particular
> goals, objectives, and actions in one place.
>
> Also, I would really appreciate the bickering and insults on this
> thread to come to an end. This is an international volunteer
> community. We should be mindful of language barriers and cultural
> differences between us.
>
> I've followed this thread for years and don't jump in often
> because of the constant bickering. The time is better spent
> formulating these ideas, documenting them and then actually doing
> them.
>
> Look out this afternoon for updates on the wiki a the address I
> mentioned above.
>
>
> Best,
> Mariah
>
>
> On Apr 11, 2017 9:51 AM, "Caryl Bigenho" <cbigenho at hotmail.com
> <mailto:cbigenho at hotmail.com>> wrote:
>
> Hi Folks,
>
>
> First, thanks go to Walter for the very comprehensive review
> of Sugar Labs and what has been done and is currently being
> done. It is very helpful. However, it, in no sense of the
> words, represents goals and objectives for SL going forward.
>
>
> I know Sameer really does want to share more with us to assist
> in developing a viable list of goals and objectives, but I
> also know he is very busy with his teaching job. So, I have
> taken the time to find a couple of resources from education
> that show what goals and objectives really are and how the
> activities we choose to undertake are related. These resources
> are attached.
>
>
> The next thing that needs to be done is to go through Walter's
> fine document and identify all the specific areas Sugar Labs
> works with and write one goal for each. Don't do anything else
> until these goals are written. These should be done in a
> sharable online document. Everyone who wants to participate
> should be encouraged to do so. There should be no special
> priority attached to any of these goals. At this point they
> would be of equal value.
>
>
> There should be one goal for each area... I suggest we start
> with these 4 broad areas:
>
>
> 1. Sugar
> 2. Sugarizer
> 3. Stand Alone Projects
> 4. School Server
>
>
> Each goal should be concise and precise. _Preferably one
> sentence._ Under each goal go objectives. There can be _more
> than one_ objective per goal.
>
>
> An objective should follow the form of *Who* is going to do
> *What* by *When* and *How* will success be measured.
>
>
> A goal can have several objectives under it... for example,
> the objectives for Sugar could have objectives addressing
> both Raspian and Trisquel (two separate categories).
>
>
> Once the objectives are filled in, it will be time to start
> working on activities. These will include actual activities
> like producing a new version of Sugarizer, conducting a Music
> Blocks workshop, showing Sugar Labs "products" and recruiting
> users and volunteers at Linux conferences and educational
> conferences, etc.
>
>
> After this every project proposed can be analyzed with the
> question in mind, "How does this project help Sugar Labs
> achieve its stated objectives (and thus its goals as well).
>
>
> Please! Someone start a doc for this to all happen. Begin with
> just the 4 (or 5 if you want to separate Raspian and
> Trisquel). Make a simple goal for each. Then collaborate on
> getting the goals "just right" before moving on to objectives.
>
>
> Then do the same thing for objectives.
>
>
> This may seem like a lot of "busy work." But, trust me it
> isn't. It will give Sugar Labs a strong platform to work from,
> enabling the best use of limited time and resources.
>
>
> Caryl
>
>
>
> ------------------------------------------------------------------------
> *From:* IAEP <iaep-bounces at lists.sugarlabs.org> on behalf of
> Laura Vargas <laura at somosazucar.org>
> *Sent:* Monday, April 10, 2017 7:31:18 AM
> *To:* Samson Goddy
> *Cc:* SLOBs; iaep; sugar-devel; Dave Crossland
> *Subject:* Re: [IAEP] [Sugar-devel] 2017 Goals for Sugar Labs
> Thank you Samson
>
>
> Then I guess the email format is not the best choice. Could
> you please document it on a wiki page at the Sugar Labs wiki?
>
> Blessings and a nice week to all
>
> Laura Victoria
>
>
>
> 2017-04-10 8:25 GMT-05:00 Samson Goddy <samsongoddy at gmail.com>:
>
> If i am wrong, walter made it clear earlier that this is a
> "draft proposal" meaning you can input.
>
> Samson
>
> On Apr 10, 2017 2:15 PM, "Laura Vargas"
> <laura at somosazucar.org> wrote:
>
>
>
> 2017-04-09 19:03 GMT-05:00 Walter Bender
> <walter.bender at gmail.com>:
>
>
>
> On Sun, Apr 9, 2017 at 7:56 PM, Dave Crossland
> <dave at lab6.com> wrote:
>
> Hi
>
> Thanks Walter. I'd like to better understand
> some additional context before diving in :)
>
> Does this mean Sameer you have stopped the
> project planning process you started, and we
> should not expect you to restart it again?
>
> At the most recent SLOB meeting Samson brought up
> the fact that we were still waiting and so I
> volunteered to write something up to get the
> conversation going again.
>
>
> Thanks for doing this Walter,
>
> After a quick read, I have to confess I feel sad and
> excluded because none of the projects I have worked on
> [1] is mentioned on your view of Sugar's history.
>
>
> Regards and blessings,
>
> Laura V
>
> [1] http://pe.sugarlabs.org/ir/Proyectos
>
>
> Walter, are these the goals for this year, or
> are they your proposal for the goals for this
> year?
>
>
> Not sure I understand what you are asking. I wrote
> up a draft of goals but they are not "the goals"
> until we agree to them.
>
> regards.
>
> -walter
>
>
>
>
> On Apr 9, 2017 3:31 PM, "Walter Bender"
> <walter.bender at gmail.com> wrote:
>
> As per the discussion in the last Suagr
> Labs Oversight Board Meeting, I had agreed
> to write a draft statement of goals for
> 2017. The document below includes feedback
> from Samson G. I hope this document can
> serve to revitalize our discussion from
> 2016 that never reached resolution.
>
> Sugar Labs Plans, Goals, Aspirations
>
> What is Sugar Labs?
>
> Sugar Labs creates, distributes, and
> maintains learning software for children.
> Our approach to learning is grounded in
> Constructionism, a pedagogy developed by
> Seymour Papert and his colleagues in the
> 1960s and 70s at MIT. Papert pioneered the
> use of the computer by children to help
> engage them in the “construction of
> knowledge.” His long-time colleague
> Cynthia Solomon expanded up his ideas by
> introducing the concept of engaging
> children in debugging as a pathway into
> problem-solving. Their 1971 paper, “Twenty
> things to do with a computer”, is arguably
> the genesis of contemporary movements such
> as the Maker Movement and Hour of Code.
>
> At the core of Constructionism is
> “learning through doing.” If you want more
> learning, you want more doing. At Sugar
> Labs we provide tools to promote doing.
> (We focus almost exclusively on tools, not
> instructional materials.) However, we go
> beyond “doing” by incorporating critical
> dialog and reflection into the Sugar
> learning environment, through mechanisms
> for collaboration, journaling, and portfolio.
>
> Sugar Labs is a spinoff of the One Laptop
> per Child (OLPC) project and consequently
> it has inherited many of its goals from
> that project. The goal of OLPC is to bring
> the ideas of Constructionism to scale in
> order to reach more children. A particular
> focus is on children in the developing
> world. In order to meet that goal, Sugar,
> which was originally developed for OLPC,
> was by necessity a small-footprint
> solution that required few resources in
> terms of CPU, memory, storage, or network
> connectivity. The major change on focus
> from the OLPC project is that Sugar Labs
> strives to make the Sugar desktop
> available to multiple platforms, not just
> the OLPC XO hardware.
>
> Who develops Sugar?
>
> Sugar Labs is a 100% volunteer effort
> (although we do occasionally raise money
> for paid student internships). Sugar
> development and maintenance is incumbent
> upon volunteers and hence we strive to
> provide as much control as possible to our
> community members, including our
> end-users. (In fact, one of our assertions
> is that by enabling our users to
> participate in the development of the
> tools that they use will lead to deeper
> engagement in their own learning.) Towards
> these ends, we chose the GPL as our
> primary license. It has been said of the
> GPL that it “restricts my right [as a
> developer] to restrict yours [as a user
> and potential developer]”, which seems
> ideal for a project that wants to engage a
> broad and diverse set of learners. But at
> Sugar Labs we go beyond the usual goals of
> FOSS: a license to make changes to the
> code is not enough to ensure that users
> make changes. We also strive to provide
> the means to make changes. Our success in
> this goal is best reflected in the number
> of patches we receive from our community.
> (We achieve this goal through providing
> access to source code and development
> tools within Sugar itself. We also
> actively participate in workshops and
> internship programs such as Google Summer
> of Code, Outreaching, and Google Code-In.)
>
> Who uses Sugar?
>
> Ultimately, our goal is to reach learners
> (and educators) with powerful tools and
> engage them in Constructionist learning.
> Currently we reach them in many ways: the
> majority of our users get the Sugar
> desktop preinstalled on OLPC XO hardware.
> We have a more modest set of users who get
> Sugar packaged in Fedora, Trisquel,
> Debian, Ubuntu, or other GNU/Linux
> platforms. Some users get Sugar on Live
> Media (i.e., Sugar on a Stick). Recently
> Sugarizer, a repackaging of some of the
> core Sugar ideas for the browser, has been
> finding its way to some users. There are
> also a number of Sugar activities that are
> popular outside of the context Sugar
> itself, for example, Turtle Blocks, which
> has wide-spread use in India. Harder to
> measure is the extent to which Sugar has
> influenced other providers of
> “educational” software. If the Sugar
> pedagogy is incorporated by others, that
> advances our goal.
>
> Who supports Sugar?
>
> When we first created Sugar Labs, we
> envisioned “Local Labs”—hence the name
> “Sugar Labs”, plural—that would provide
> local support in terms of local-language
> support, training, curriculum development,
> and customizations. This model has not
> ever gained the scale and depth envisioned
> (we can debate the reasons why), although
> there are still some active local
> communities (e.g., Educa Paraguay) that
> continue to work closely with the broader
> community. There are also individual
> volunteers, such as Tony Anderson and T.K.
> Kang, who help support individual schools
> in Rwanda, Malaysia, et al. An open
> question is how do we support our users
> over the long term?
>
> What is next for Sugar?
>
> We face several challenges at Sugar Labs.
> With the ebb of OLPC, we have a
> contracting user base and the number of
> professional developers associated with
> the project is greatly diminished. How can
> we expand our user base? How can we
> attract more experienced developers? Why
> would they want to work on Sugar as
> opposed to some other project? The meta
> issue is how do we keep Sugar relevant in
> a world of Apps and small, hand-held
> devices? Can we meet the expectations of
> learners living in a world of fast-paced,
> colorful interfaces? How do we ensure that
> it is fulfilling its potential as a
> learning environment and that our users,
> potential users, and imitators are
> learning about and learning from Sugar.
> Some of this is a matter of marketing;
> some of this is a matter of staying
> focused on our core pedagogy; some of this
> a matter of finding strategic partners
> with whom we can work.
>
> We have several near-term opportunities
> that we should leverage:
> * Raspian: The Raspberry PI 3.0 is more
> than adequate to run Sugar—the experience
> rivals or exceeds that of the OLPC XO 4.0
> hardware. While RPi is not the only
> platform we should be targeting, it does
> has broad penetration into the Maker
> community, which shares a synergy with our
> emphasis on “doing”. It is low-hanging
> fruit. With a little polish we could have
> an image available for download from the
> RPi website.
> * Trisquel: We have the potential for
> better leveraging the Free Software
> Foundation as a vehicle for promoting
> Sugar. Their distro of choice is Trisquel
> and the maintainer does a great job of
> keep the Sugar packages up to date.
> * Sugarizer: The advantage of Sugarizer is
> that it has the potential of reaching
> orders of magnitude more users since it is
> web-based and runs in Android and iOS.
> There is some work to be done to make the
> experience palatable on small screens and
> the current development environment is—at
> least my opinion—not scalable or
> maintainable. The former is a formidable
> problem. The latter quite easy to address.
> * Stand-alone projects such as Music
> Blocks have merit as long as they maintain
> both a degree of connection with Sugar and
> promote the values of the community. It is
> not certain that these projects will lead
> users towards Sugar, but they do promote
> FOSS and Constructionist principles. And
> they have attracted new developers to the
> Sugar community.
> * School-server: The combination of the
> School Server and Sugar desktop is a
> technical solution to problems facing
> small and remote communities. We should
> continue to support and promote this
> combination.
>
> Specific actions: After last year’s Libre
> Planet conference, several community
> members discussed a marketing strategy for
> Sugar. We thought that if we could reach
> influencers, we might be able to greatly
> amplify our efforts. There are several
> prominent bloggers and pundits in the
> education arena who are widely read and
> who might be receptive to what we are
> doing. One significant challenge is that
> GNU/Linux remains on the far periphery of
> the Ed Tech world. Although the “love
> affair” with all things Apple seems to be
> over, the new elephant in the
> room—Chromebooks and Google Docs—is
> equally difficult to co-exist with.
> Personally, I see the most potential
> synergy with the Maker movement, which is
> building up momentum in extra-curricular
> programs, where FOSS and GNU-Linux are
> welcome (hence my earlier focus on RPi).
> (There are even some schools that are
> building their entire curriculum around
> PBL.) We can and should develop and run
> some workshops that can introduce Sugar
> within the context of the Maker movement.
> (Toward that end, I have been working with
> some teachers on how to leverage, for
> example, Turtle Blocks for 3D printing.)
> It is very much a tool-oriented community
> with little overall discussion of
> architectural frameworks, so we have some
> work to do. But there is lots of
> low-hanging fruit there.
>
> regards.
>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
>
> _______________________________________________
> IAEP -- It's An Education Project (not a
> laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop
> project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
>
>
>
> --
> Laura V.
> *I&D SomosAZUCAR.Org*
>
> “No paradox, no progress.”
> ~ Niels Bohr
>
> Happy Learning!
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
>
>
> --
> Laura V.
> *I&D SomosAZUCAR.Org*
>
> “No paradox, no progress.”
> ~ Niels Bohr
>
> Happy Learning!
>
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org <mailto:IAEP at lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/iaep
> <http://lists.sugarlabs.org/listinfo/iaep>
>
>
>
>
>
> --
> Mariah Noelle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20170412/bc517806/attachment-0001.html>
More information about the IAEP
mailing list