[IAEP] Fwd: Re: [Sugar-devel] 2017 Goals for Sugar Labs%
Tony Anderson
tony_anderson at usa.net
Mon Apr 10 19:12:06 EDT 2017
Sorry, this didn't get copied to IAEP as I intended but only webt to
Sugar-Devel
Tony
-------- Forwarded Message --------
Subject: Re: [Sugar-devel] [IAEP] 2017 Goals for Sugar Labs%
Date: Mon, 10 Apr 2017 10:52:04 +0800
From: Tony Anderson <tony_anderson at usa.net>
To: sugar-devel at lists.sugarlabs.org
Hi, Walter
Thanks for this. I feel at long last the community may actually get
involved in a serious discussion about what we are about and what we
need to do.
Discussion about whether to support Trisquel or Raspberry Pi or Windows
is a distraction. The fundamental requirement is that Sugar be available
on mainstream platforms. The perception that Sugar is software limited
to the XO should be replaced by Sugar as a effective learning platform
available to anyone and usable on their own computer, free and
unencumbered by eulas. Naturally, this requires that we make it so.
If a credible Raspberry Pi image is easy to do, for God's sakes do it!
if it can be distributed as a part of NOOBs, do it! If Trisquel is a
viable Sugar distribution, then for God's sake document where it can be
obtained and how to install it.
Aslam Kishwer told me, 'Make Sugar available on Windows.' It doesn't
matter if Windows is installed on 99% or 10%. Like it or not, Microsoft
has made learning 'Office' the sine qua non of using computers in the
classroom. It needs a Sugar image, installable as a Windows application
(a la wubi).
A Sugar image needs to be a file that can be installed from a local
computer. In remote locations, the internet may not be available. Even
with available broadband access, downloading software directly to each
of 40 computers is not practical.
A Sugar image needs to be supported by Sugar Labs and its community.
Currently, the XO provides 0.110 while SOAS and Ubuntu 16.04 provide
earlier versions. So the a Sugar release needs to be images for the
supported platforms. Sugar activities need to work on supported releases
(which will involve significant community effort to test in the release
cycle).
Our intended users are not software developers and so the installation
technique needs to be comfortable and not require steps unfamiliar to
the average computer user.There are simple gui versions of dd which
could be used. SOAS is installable by dd from an image. This is not a
conclusion you would reach from the Sugar Labs site which starts with
requiring the installation of Fedora!
In the context of 'making', I think we need to consider who are the
'makers'. The makers are our Sugar users - primary school children.
Unfortunately, Sugar Labs seems to be moving to a closed community of
software developers and computer science students. As a result our
support environment is evolving to tools not available to our users -
translate.sugarlabs.org, github, and our current mantra: 'build a
development environment'. All of these isolate our users from the
'making' of Sugar (esp. activities and localization).
Our focus in programming in visual languages. This is a great start.
However, it is what educators call scaffolding. We need to use the tools
we have and develop others to help our users program in text languages -
Python and Javascript (with HTML and CSS). Currently our focus is 'View
Source'. This is not a path to encourage making and violates the
constructionist principle to start from what the user knows. More
effective would be to focus on 'Making Your Own Sugar Activity' and the
supporting tools (PyTute, HelloWorld, HelloWebWorld, Pippy). Programming
today in text languages is not more difficult than it was in Basic or
Pascal on the Apple II.
One vehicle which supports the maker community is the Makerfaire. Adam
Holt and his team have effectively represented Sugar at some of these.
One requirement is to provide an opportunity for visitors to use the
available computers to do something with the computer. There ia a Pi and
More conference in Trier on June 24, 2017. I would love to be able to
show Sugar on the Raspberry Pi there. The essential requirement is a
viable and supported image that is available to the attendees. Ideally
such an exhibit would show a Raspberry Pi as a server with XSCE and
others as Sugar systems with monitors, keyboards, and mouses.
Tony
On 04/10/2017 08:03 AM, Walter Bender wrote:
>
>
> On Sun, Apr 9, 2017 at 7:56 PM, Dave Crossland <dave at lab6.com
> <mailto: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.
>
>
> 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
> <mailto: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 <mailto:IAEP at lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/iaep
> <http://lists.sugarlabs.org/listinfo/iaep>
>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20170411/e6a04a74/attachment-0001.html>
More information about the IAEP
mailing list