[IAEP] [Sugar-devel] 2017 Goals for Sugar Labs
Samson Goddy
samsongoddy at gmail.com
Wed Apr 12 07:12:41 EDT 2017
I was going around youtube and i saw this video [1] (Sugar Labs Vision 2016
proposal Hangout). I think towards the technical aspect of Sugar Labs, this
video explains everything walter was trying to point out.
[1] https://www.youtube.com/watch?v=ENLWvPV8jrI&t=10s
Samson
On Wed, Apr 12, 2017 at 8:09 AM, Tony Anderson <tony_anderson at usa.net>
wrote:
> 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>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
>>
>> 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> 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>iaep-bounces at lists.sugarlabs
>> .org> on behalf of Laura Vargas < <laura at somosazucar.org>
>> 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>
>> 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>
>>> laura at somosazucar.org> wrote:
>>>
>>>
>>>
>>> 2017-04-09 19:03 GMT-05:00 Walter Bender < <walter.bender at gmail.com>
>>> walter.bender at gmail.com>:
>>>
>>>>
>>>>
>>>> On Sun, Apr 9, 2017 at 7:56 PM, Dave Crossland < <dave at lab6.com>
>>>> 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/i>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>
>>>>> 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>http://www.sugarlabs.org
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> IAEP -- It's An Education Project (not a laptop project!)
>>>>>> <IAEP at lists.sugarlabs.org>IAEP at lists.sugarlabs.org
>>>>>> <http://lists.sugarlabs.org/lis>http://lists.sugarlabs.org/lis
>>>>>> tinfo/iaep
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Walter Bender
>>>> Sugar Labs
>>>> <http://www.sugarlabs.org>http://www.sugarlabs.org
>>>>
>>>>
>>>> _______________________________________________
>>>> IAEP -- It's An Education Project (not a laptop project!)
>>>> <IAEP at lists.sugarlabs.org>IAEP at lists.sugarlabs.org
>>>> <http://lists.sugarlabs.org/lis>http://lists.sugarlabs.org/lis
>>>> tinfo/iaep
>>>>
>>>
>>>
>>>
>>> --
>>> Laura V.
>>> *I&D SomosAZUCAR.Org*
>>>
>>> “No paradox, no progress.”
>>> ~ Niels Bohr
>>>
>>> Happy Learning!
>>>
>>>
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> <Sugar-devel at lists.sugarlabs.or>Sugar-devel at lists.sugarlabs.org
>>> <http://lists.sugarlabs.org/lis>http://lists.sugarlabs.org/lis
>>> tinfo/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
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>>
>>
>
>
> --
> Mariah Noelle
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20170412/8975cb46/attachment-0001.html>
More information about the IAEP
mailing list