[IAEP] Some curious social-psych research, with applications to OpenHatch, Nell, and...?
Asheesh, Karen, (and various other friends interested in learning... :-) If you haven't already done so, you folks should think about finding yourselves copies of Carol S. Dweck's book: Self-theories: their role in motivation, personality, and development [1,2]. The punch-lines that I see for OH [3,4], Nell [5], and friends include: a) When faced with challenging problems, some people become frustrated, bored, or distracted while others become patient, focused, or excited. b) Variation in (a) can be predicted by measuring the subjects' agreement with statements about the malleability and nature of intelligence or by measuring preferences for learning goals vs. performance goals, e.g., via the following measure, taken from the book's appendix: Task-choice Goal Measure: (suitable for ages 10 and older) Sample instruction: We have different kinds of problems here for you to choose from. There is no right answer -- different students make different choices. Just put a check in front of your choice. Question: I would like to work on: __ Problems that aren't too hard, so I don't get many wrong. __ Problems that I'll learn a lot from, even if I won't look so smart. __ Problems that are pretty easy, so I'll do well. __ Problems that I'm pretty good at, so I can show that I'm smart. c) People who preferred opportunities to learn over opportunities to look smart or to avoid looking dumb were unaffected by treatments designed to increase confusion (like being asked to learn from a booklet containing an intentionally confusing paragraph) while people who stated the other preferences were quite negatively affected by the confusion treatment. d) Subsequent interventional studies showed that the correlation described in (b) survived treatments designed to shift people's beliefs and preferences in both directions, like being asked to read appropriately crafted stories about how recognized geniuses accomplished their intellectual feats. Items (b) and (d) certainly seem like they might motivate some new OH / Nell tweaks, no? Regards, Michael [1]: http://www.amazon.com/Self-theories-Motivation-Personality-Development-Psychology/dp/1841690244 [2]: Caroline (cc'ed) introduced it to me in response to a recent bit of gentle provocation [5] on the part of myself, Chris, and Scott... [3]: http://openhatch.org [4]: http://lists.openhatch.org/pipermail/devel/2010-December/001703.html; better citations welcome [5]: http://cananian.livejournal.com/66008.html ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Google Summer of Code 2011
On Tue, 8 Feb 2011 at 00:11:13 +0100, Dinko Galetic wrote: On Mon, Feb 7, 2011 at 11:54 PM, Chris Ball c...@laptop.org wrote: Hi Michael, This reminds me -- it looks like Dinko's changes were not merged into Pippy mainline. Can you tell us about the status of his work? There were things which were in my original plan for the GSoC, but I didn't manage to finish. My university obligations have kept me from getting back to it (more due to the drain of motivation than due to the lack of time), but it's been on my mind lately and will get back to it in the next few days. Chris, Dinko, Here's what Dinko accomplished: * In June, Dinko wrote several new Pippy examples and, with my help, solicited a round of review from Anish, which Anish kindly provided. Dinko later wrote back that he had implemented the requested revisions. * In July, Dinko worked on Python tutorial content. Later, Caryl offered (and Dinko responded to) several threads worth of comments on the content of three of the tutorial files that Dinko sent to sugar-devel@. * In August, Dinko reported that his health declined and that he got stuck several times while trying to figure out how to build his planned game. * Finally, in September, Dinko published his examples, his tutorial content, and his initial work on the planned game here: http://google-summer-of-code-2010-sugar-labs.googlecode.com/files/Dinko_Galetic.tar.gz So far as possible next steps are concerned: 1. Someone needs to publish Dinko's examples in the form of an activity bundle, so that they are useful to people who consume activity bundles (as opposed to text files, tarballs, patches, and/or git repos). 2. Someone needs to write an interpreter for Dinko's tutorial content, so that it can be usefully distributed as part of an activity bundle. 3. Some Pippy maintainer needs to decide how to go about merging Dinko's work, so that we can wind up with a proper Happy Ending. Further questions? Regards, Michael P.S. - @Dinko, Anish, Quozl: Interested outside folks (including me) are probably able to outright /do/ one or more of these tasks, but I know that I feel reticent about picking them up for fear of stepping on toes. Therefore, could you please be a bit more vocal about what kinds and amounts of help you'd like with these tasks? ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Gnome vs Sugar -- The judgement day
Teachers demand a technological mean to solve a problem of discipline and computer literacy. Launch GNOME under a separate account with a quota and with limited or no sudo access. This will cut out most of the mayhem, thereby buying you time to work out a more integrated solution. Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Proposal release management
Simon wrote: What do others think about this? I'm glad that you have a proposal that excites Bernie, Bert, and Tomeu. I'm not sure what to think for myself because I don't know whether I correctly understood your intent from my reading of your, Bernie's, and Tomeu's words. (See below.) Bernie and Tomeu wrote: Regarding proposed patches, during our development cycle we have collected a number of patches fixing bugs and adding small features. Just in case, note that the RM doesn't really care about what code goes in as long as features have been approved and we are in the right moment in the cycle (no freezes apply). Let's be clear: I want *nothing* to do with any software process that works this way -- you've described a bad shell-script, not a release manager. However, I'm not sure that this description is actually what Simon was talking about. Perhaps we should instead be talking about whatever role describes the people who /do/ care about the code that goes in? Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Devel Team vacancies + On sugar-0.90.
On June 7, Simon Schampijer wrote: On 06/06/2010 10:30 PM, Tomeu Vizoso wrote: SeanDaly if tomeu were here, he would say: we need someone experienced, who knows the open source way, and does not need lots of briefing to get up to speed (he will correct me if I err) You can count on me for that :) So the idea of team coordinator is that of someone who takes care for: * keeping the list of team members updated in the wiki, * making sure the mission statement is in sync with the team's activities, * announce and moderate regular meetings and publishing its minutes. So I don't think you need any special skills, just be willing to donate a few hours per month. If we had a community team, we would have a structure for the people who want to work together on such issues ;) cjb (I think the most important job the release manager does is decide whether a late change constitutes acceptable risk, and I think doing that requires deep understanding of programming and the complexity of a given bug/solution.) There seems to be a misunderstanding, maybe because OLPC had a position with the same name (and maybe our use of it is not totally appropriate). In Sugar's case, who decides what goes in and what not is the schedule, the maintainer and the release team, with input from several others. The schedule says what kind of changes can go in at every moment in the release cycle, the maintainer is expected to have enough criteria to classify every change accordingly and the release team votes on exceptions to the schedule. All about releases: http://wiki.sugarlabs.org/go/Development_Team/Release New features process and what is the release manager: http://wiki.sugarlabs.org/go/Features/Policy In this way, the release manager doesn't have as much responsibility as was implied in the meeting but he's mainly responsible for making sure that the process _for proposing new features_ is followed. It's largely an administrative role, but much more exigent than coordinating a team. The reason for having a weaker release manager and relying more on the criteria of maintainers is because by SLs being an upstream these decisions won't affect as directly to our users as downstreams are anyway expected to do integration, testing and maybe some amount of patching after each release is made. For a downstream such as OLPC or Fedora, someone needs to control very strictly what gets in at the end of the cycle because there's more pressure to get stuff in and because once you have sent the image to the factory or have started to seed a torrent it's much harder to go back and fix some bug. In the Sugar case, if a maintainer made a goof and introduced a major bug just before release, it will take some time before the code is packaged, then distributed to testers, then submitted to a stable release that users will use with some expectation of not finding major regressions. It would be great if people could search the wiki before entering in discussing a process or a role, because as you can see from the link above, that took someone quite a bit of time to write and would be sad to waste time discussing something else. Also, the docs in the wiki indeed could be clearer and any help will be welcome. To make it clearer: * the release manager is not needed to make module releases, * the release manager doesn't decide by herself if a change goes in or not, * the release manager makes sure the feature process is followed. Maybe a more appropriate name for what we call the release manager would be new feature process manager but as it's a bit long and we don't have a release manager, we ended up using that name instead. Regards, Tomeu Thanks for taking the time to lay this out as detailed. Indeed, thanks! It is true indeed that the main role of the release manager, as Sugar Labs interpreted that role... The stumbling block for me for several other people here is this line from the current Feature Policy: The main goal of the feature policy is to make systematic and predictable the process by which community ideas on how Sugar should evolve get transformed into actionable proposals. and its emphasis on process, predictability, and rigid schedules. Why is predictability the thing we want to optimize for here? You see, I want us to create a Sugar release that is *as much improved as we can get in the time allowed*, even if it winds up being improved in ways that we didn't foresee -- that we merely recognized and adopted immediately as they were suggested. To do this, we should concentrate on building the leanest, meanest, fastest coding and integration machine that we can so that we create as much opportunity as we can stand to make changes that will really improve the user experience and technology that we're providing. Velocity, momentum, and ferment should be our bywords. The reason why I want these things is that there are still
[IAEP] maintenance
Tomeu, Hi, follows a plan about how to improve the situation regarding maintenance of our software modules. If you care about it, please reply even if only to say so... I care. , or even better, comment on it and suggest improvements. I will assume that lack of replies mean people don't care about it and will stop caring about it myself. == The problem == The process by which our software reaches to children is complex and involves several organizations. Sugar Labs is one of those and its responsibility is to provide the raw sources that organizations downstream such as OLPC, Fedora and Paraguay Educa will modify, package, ship and install. It's very important that modifications done downstream are kept to a minimum so that all downstreams share as much work as possible. This means that the raw sources we provide need to contain the features that downstream need in each release and that it contains as few bugs as possible. One comment: for me, downstream modifications represent both essential sources of knowledge about what actually matters and the emergence of new contributors. Hopefully we agree that assisting and rewarding these tentative efforts (as you, Daniel, and Bernie have done in your many visits to Uruguay, Nepal, and Paraguay) helps us to gain contributors and to better understand what downstreams need? In order to provide good raw sources, we have a series of processes that assure that the expected features are present and that the worst bugs are either fixed or at least well-known. These processes include testing, bug triage (keeping the bug database in order), source release, code review, user experience design and code development. We disagree about the details of how these processes should be concretely implemented but we substantially agree on the list of processes. (That being said, I would probably add evangelizing and experimentation to the list.) An important role present in most of those processes is that of the module maintainer. A module maintainer takes responsibility for a part of the source code. The maintainer will release code at known times and will have worked so it has gone through the processes outlined above. Of course, the maintainer cannot do all the work by herself, but is ultimately responsible for it. Normally the maintainer will have spent most of her time triaging and fixing bugs, and will be trying hard to keep the module in order so that in future releases the maintenance burden doesn't grow too much as new code gets in. An important process in keeping the maintenance burden in check is code review, by which the maintainer checks that the new code that gets in a release won't increase the maintenance burden too much. I agree that responsible people are important but I don't really agree with this characterization of how a responsible person does their work: I want my maintainers to be spending most of their time merging patches, giving feedback, or making awesome new contributions of their own. (I also don't know precisely what you mean when you say maintenance burden. Could you please say a bit more?) The problem is that very few people in Sugar Labs are willing to do that maintenance work. We have people keen on packaging Sugar, deploying it, training teachers on it, developing new activities and new Sugar features, people write books about Sugar, setup help lines to support Sugar users, universities are given grants to study the use of Sugar, load machines with it, etc. Big amounts of volunteer time and money are being spent around Sugar but almost nothing is going to maintenance. Paradoxically, any use of Sugar requires that it is reasonably stable and most investments are made with the assumption that Sugar will keep being developed. This mainly says to me that Sugar is at best partially ready for use. It also says that people still feel an urgent need to change it a lot more before they are sufficiently satisfied with it to commit to maintaining a stable branch of it. Why not just accept this and move on? I also want to make explicit that almost all maintenance effort has come from a few volunteers that are tired and disappointed about the little importance that has been given to this work. We are very close to have no maintainers at all in Sugar, meaning as well that nobody with the needed experience will be around to mentor new maintainers. Again, this really says to me that people think that, today, Sugar most desperately needs things other than maintenance. Also, isn't experience maintaining other projects largely transferable to this project? If so, I believe that new maintainers will appear when they are truly needed. - Now, a quick comment on your plan: I still think that you're putting the cart before the horse; namely, as I wrote in my most recent essay [1], If, as Walter quips, we learn by doing and learn best when motivated by love (rather than duty) then
Re: [IAEP] sustaining development
How can we reach sustainability on the rest of the process? Take employment elsewhere and work on Sugar in your remaining time if you still feel moved to do so. Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar
Dear Sugar folks, I have avoided wading into this discussion for some time because I wanted to see where it went without my interference. Therefore, before I say anything else, thanks for the entertaining show. :) Next, here are some thoughts for you, based on my own work, uses of Sugar, and past conversations with other principals. Regards, Michael Dan wrote: It will affect packaging and distribution. My suggested model (as employed all over the open source world) is that the developers would release source distributions and let distributions do the packaging and distribution. My suggested model, employed all over the real open source world, is that people write web pages (the most popular kind of open source software!), publish them at URLs, and feed those URLs to interpreters. Only people with unusual quality or distribution requirements release or package their web pages. Most people just write them and fix problems that people yell about. Consequently, I want to make using activities more like web pages. That's why I work on rainbow and on networking design. NB: ZeroInstall, which was mentioned earlier in this thread by Ben, sure seems to me like it comes from the kind of world that I want to live in, even if Bernie isn't so sure because the page he tried to visit contained an broken link. Remember, the web used to be that way too! Even though a Sugar system with distro-installed packages is crippled (activities cannot be erased or updated through any realistic means), Then we should not rely on distros for dealing with activities. (They're absolutely a great thing to build Sugar Platforms out of; they're just not so useful for this other crazy thing we want to do. This is fine. Browsers are also an absolutely great thing which is not right tool, today, for the activities problem.) But we also have activity authors that don't want to go through the hassle of learning git :/ This is getting completely ridiculous. So how do they manage the versions and releases of their packages? They don't. In my opinion, ideally, they click a URL and the software they clicked runs most of the time. They don't care what version is underneath. If they want to change it, they hit view source and edit. If they want to share it, they share the URL, however they like. If they want to merge their changes with those of other people or if they want their software to run on the computers of people with wildly different setups, then, eventually, they learn more about the art of building portable software. The point is that none of version control, packaging, releases, and so on are necessary for having fun writing software or for learning; they're just useful for engineering. Do these get put on a.sl.o? Probably not. Many of the people doing the work won't even have internet access, though they will have local networks. Take Peru as a simple example. If so how do we verify the source code and whether it can be distributed? We don't and we can't. But other people can and will anyway. How do we verify any binary content they might include? We don't and we can't. But people will happily use it anyway. What they do privately is their own business but if it appears on a.sl.o it needs to be verify able and trackable. Sure. Ben's point is that supporting this personal hacking is A PRIMARY USE CASE. If we're not doing it, we should give up and go home. However, take heart: there is a DIFFERENT primary use case; namely, supporting distro-based engineering efforts useful to deployments, which is quite amenable to the sort of solution you're comfortable with. I believe that these are compatible points of view as soon as we admit that different mechanisms are needed for the differing use cases. What's the problem here? There needs to be a minimum set of requirements. Your set of minimum requirements is a good set of requirements for engineering a great distro like Fedora, but that's not the only thing we're doing here. In particular, your minimum requirements violates Sugar's design goal of low floor, high ceiling. Them's the breaks. And even worse, we want people who are not yet able to create activities from scratch to do simple modifications to existing activities and redistribute them. That's fine. Its open source and it then becomes their problem but it shouldn't be a central issue what they want to do with modified activities. It's a central issue because, as Ben explained, supporting it is a fundamental principle of our work. Consequently, we're allowed to solve other parts of our problem in different ways, but not in ways that are incompatible with it. The activities hosted on a.sl.o should meet a minimum requirement. Otherwise we get into a situation where there's no guarantee of the Activity whether that been the source or the stability of it. Please read Stuart Cheshire's law of
Re: [IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar
Ben wrote: Michael Stone wrote: Consequently, I want to make using activities more like web pages. That's why I work on rainbow and on networking design. ... In my opinion, ideally, they click a URL and the software they clicked runs most of the time. They don't care what version is underneath. If they want to change it, they hit view source and edit. If they want to share it, they share the URL, however they like. Thank you for this perspective. I think this is a very helpful way to think about our software behavior goals, especially if we imagine our URLs as being a bit content-addressable. I'm glad that you find it helpful and would be curious to know whether other people feel the same way or differently. Lastly, about the idea of shipping everything in Python, or Java, or Smalltalk: Give up -- this works for mobile phones, not for things to think with! Programming languages are prime examples of things to think with. We're trying to provide people with lots of these, and with the best ones that we can find, remember? Hmm... but surely web pages are the prime example of a medium that contains an extremely limited variety of languages? Not really. On the client side, there's HTML, CSS, Flash, PDF, Javascript, various video formats, various image formats, various sound formats, Java Applets, ActiveX controls, integration with mail and news clients, and more. On the server side, there is even greater diversity. We can argue about whether this collection is a small or large number of languages. I don't really care. It suffices for my argument that the web does not contain One Language To Rule Them All and that there are extremely well-known conformance problems in the interpreters for these languages and yet things basically work out anyway because there are so many redundant ways of accomplishing the goal, which is learning. I have come to accept that we should provide people with lots of languages, but I think we can, and should, choose our interpreters to retain independence of platform, and isolation from distro issues. Even x86 assembler can be such a language, given an appropriate interpreter. For a particularly strange glimpse into the future: http://www.codebase.es/jsgb/ [1] http://www.qemu.org/qemu-doc.html#SEC69 Neat examples. I'm glad that we agree that more languages is basically good. As for interpreters -- I absolutely agree that they should be chosen carefully. I just think that the interpreter that we choose carefully should be the one that prepares to run a program (e.g. by fetching and installing it, or by caching it, etc) rather than the one that runs it. Does this distinction make sense? Kind regards, Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] SoaS as a Sugar Labs project.
Tomeu, Frankly Michael, the only way I can read these posts from you is that you are frustrated because we aren't churning more work, regardless of how much we have achieved that is relevant to OLPC deployments. Correct. I do not accept that work I have managed to do in the past is sufficient simply because it was the work that I was able to do. Instead, I form or disintegrate this acceptance with reference to three external measures: * absolute standards of quality, e.g. as formed by acceptance testing against written design goals or user experiences, * relative standards of quality as evidenced by the respect and participation of specific individuals whose judgment I trust and whose biases seem to me to control for some of my obvious biases, and * freeform standards of quality as evidenced by what other people have made from the work. I am therefore frustrated, for the reason you mention, because I believe that our work is achieves none of these standards of good enough. (Unsurprisingly, I'm frustrated for some other reasons too, but that's neither here nor there.) Do you have any actionable ideas about how to work better for our users? I perceive a double bind: I have lots of ideas, but ideas are cheap and seem most unwelcome here -- they're just talk instead of do, aren't they? Michael P.S - Maybe a reasonable compromise on the double bind would be for me to share a small number of ideas, or to share as many ideas fit into a fixed duration conversation in a different medium? ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] SoaS as a Sugar Labs project.
Gary, I'm tired and sad from talking on this subject but I still don't feel that I've been understood. (Or, if I have been, I haven't understood the rebuttals of my position, in which case I apologize for being so dense.) Anyway, here's one more try: Wow, blast from the past :-) Actually I'd strongly disagree here. Having re-read through most of what is listed here, much progress has been made on a large number (dare I say majority) of these items! We count differently, so I'll try to make myself understood in a different way. Other than view source improvements, which I think everyone agrees are significant, how is Sugar actually better for reflecting, collaborating, and discovering than it was a year ago? Has the ceiling gotten appreciably higher or the floor lower? Are there really noticeably more activities to choose from? Can a teacher actually rely on the networking protocols (over wireless networks) enough to justify spending classroom time on it? Finally, is Sugar any closer to achieving any of its major technical goals, like easy code sharing, click-to-translate, interoperability with regular Linux apps, or real ease of authoring? Notes: * I haven't formed an opinion of silbe's versioning work yet so I can't yet say what I think of it other than to mention a degree of limited hope based on his decision to avoid addressing the interoperability goals that Scott's approach to versioning sought to address. * I can see how the toolbar redesign might help with the discoverability and low-floor goals. Does it? If so, how much? * I can see how the ePub support and support for Flash activities could be counted as progress toward more content. Still, it seems at best half-finished without knowing what the content to send with the support... * Some people would argue that Sugar's integrated file-sharing support is a major improvement. I will agree with these people when they explain why they think that this file-sharing technology will function more reliably than our current presence and collaboration technology in realistic networking scenarios encountered in school-scale wifi-based deployments. * I understand that people here have accomplished lots of other hard and valuable things in the intervening year; I just really, really, really want people to remember which are the problems that we actually set out to solve, at least as I have understood them so far, and I want us to be doing work that is good enough to retain the interest of the best people in the world, in all relevant fields, which I fear that we are not. Are these not reasonable criteria on which to base judgments of progress? The problem is that you need to to be using 0.84 to benefit from most, with the approaching 0.86 solving a bunch more. The difficulty, unfortunately, seems to be much more about getting XO-1 QA'ed release rollouts available for deployments. At least 0.84 does seem to be in the OLPC pipeline, due to XO-1.5 needs, with volunteers*** pushing on the side of existing XO-1 hardware. Let me share a brief story... I became OLPC's release manager for a brief time last year because I realized that all of * Marco's, Tomeu's, Eben's, Sayamindu's, and Simon's hard work on the shell redesign, control panel and Browse certificates, * my work on Rainbow, and * Scott's work on the activity and distro updaters, * Chris' and Richard's work on power management, * Richard's and Andres' work on touchpad bugs, * Bernie's work on X, * Bert's work on EToys, * Dennis' work on Fedora packaging, * Michailis', Ricardo's, and Marvell's work on new wireless firmware, * Collabora's work on fixing up Gabble and Salut, and * Martin's work on backups wasn't going to matter a whit unless someone organized a full-blown distro release (and associated assurance process) in order to deliver this work in a form usable by the people who might benefit form it. I still subscribe to this position today, more or less. [1] However, to my great sadness, I don't see any changes in the past year (or in the foreseeable future, though 0.86 brings us somewhat closer) that are compelling enough for me to encourage or support a serious effort to create and to assure a deployable distro release to carry changes to XO-based end users. (Do you see anything that I don't? Do you value things differently?) ***F11_for_XO-1 build 5, from Steven Parish, was the last available dev release, and is running pretty well on an XO-1 and an XO-B4 here. Thanks very much for helping to test it. (Seriously.) In your testing, have you experienced any notable regressions from 8.2.1 that will make it hard for deployments to adopt, given the sorts of things that you see deployments asking about on the Features page that I cited? Regards, Michael [1]: I can imagine how SoaS, Sugar-via-LTSP, and
Re: [IAEP] SoaS as a Sugar Labs project.
Gary, Your reply just made my evening, and even more amusingly, I now think that we may both be right. Regards, Michael (In what ways are we both right, you ask? Very well: You're right that some real progress has been made -- you've assembled quite a list of Gregorio-approved features about which Things Have Been Done, which, it seems to me, might prove to be very useful to have around when when trying to start conversations with existing XO deployments... but, unfortunately, I'm now reassured that I'm right that most of the really big interesting Sugar-defining stuff like networking, collaboration, hackability, customizablility, performance, simplicity, security, etc. was delightfully labeled as either wet string or pass. :) Are we in agreement now? ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Sugar packaging in Squeeze, Karmic
Bernie, 1) Is anyone routinely testing Sugar in Debian? Yes, though not deeply. I conduct my occasional rainbow/sugar integration testing in Debian chroots via the instructions written down at http://wiki.sugarlabs.org/go/Development_Team/Chroot which I am in the process of automating as mentioned on that page. For the interested: * the Debian automation is usable by me and /might/ be usable by someone else. * the Gentoo automation builds Gentoo chroots but Sugar is not presently emergeable in them either due to Blocking conflicts among e2fsprogs and friends, which might, in turn, be due to my installation mistakes. * I haven't worked on Ubuntu automation but it should be trivial given the Debian work. * Fedora is not cost-effective to automate without functioning distro packaging of yum. (Interested listeners -- please fix up rpm and yum packaging enough to make either mock or febootstrap function properly on Debian so that I and people like me can have an acceptably usable means to test Fedora packaging of our software.) 2) Is anyone routinely testing Sugar in Ubuntu? I'm not presently, though I hope to get there soon via the plan mentioned above. The full list of Sugar related packages in Debian is quite impressive... It's actually more impressive than you can see -- Jonas' packaging logic, which may be found in various sugar* repos at http://git.debian.org/ arranges things very nicely for building and maintaining debs from the upstream git branches on the same footing as he and his collaborators maintain simultaneous packaging of all Sugar releases. Regards, Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] A security vs. functionality question
Lucian, Ben: Here are a bunch of reactions. Apologies for the delay. :) Michael Lucian Branescu wrote: A chroot because afaik rainbow doesn't really work outside the XO distro My impression may be wrong, though. Would you mind taking a look at http://wiki.laptop.org/go/Rainbow for me and letting me know what questions you are left with? Ben Schwartz wrote: Rainbow is not currently used much outside of the XO, but it should be, and it can be. Michael Stone, who developed it, no longer works for OLPC, but he has continued to update it. It can be packaged for any distro. There has been some bitrot; Sugar needs to be tweaked to regain compatibility. Someone will have to be bold enough to write the patches. Sascha and I actually wrote the most important patches several months ago and Tomeu merged them last weekend in response to #593. (Thanks, Tomeu and Sascha!) (That being said, there's more fun to be had -- check out the next steps Rainbow page!) Lucian Branescu wrote: I had assumed everyone has root access, it is such a basic need for a machine you own. The most notable existing Sugar users I know of who lack easy root access are the kids using Sugar in Uruguay and Ethiopia. It's an unfortunate situation. Ben Schwartz wrote: To educators: How concerned are you about a feature that allows one student to invite others to play on their computer? Remote access is only granted if the user chooses to share a specific activity. The effect is similar to letting someone walk over and type on your keyboard. With current technology, it's a bit more like letting any stranger with a nametag that reads Jimmy walk over and type on your keyboard when you actually meant to invite your friend Jimmy over to help you. (Also, do note that your simile also describes the current security properties of activity installation, web browsing, Adobe-Flash playing, and perhaps of plugging in USB sticks -- that is: non-existent.) Ben Schwartz wrote: To engineers: Is sharing an activity a sufficient indication of intent from the user to execute a potentially dangerous action, such as sharing Terminal on a public collaboration server? Let's start with a more basic question: what mental model(s) of software do we want to share with our learners? Ben Schwartz wrote: An Activity can easily be stopped by a single click at any time. Pff. On Sugar today, an activity can probably reformat your hard disk, reflash your BIOS, or make toast on your IPv6-enabled toaster. (Such, by the way, is the general state of desktop security.) Your only hope of stopping a malicious activity is to cut the power. Ben Schwartz wrote: One possibility that has occurred to me is to permit unsafe sharing only with users who have already been designated as Buddies. Instead of Share with My Neighborhood, the toolbar would only offer Share with My Friends. A good design exercise that I think might shed some light on your situation would be to analyze your SharedTerm system, in both its current and in this proposed form, in terms of Ka-Ping Yee's design principles for usable security: http://zesty.ca/sid/ (Also, do let me know if you would like to pursue this course -- I would enjoy practicing with you.) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] A Fine Tradition...
Carrying on a fine tradition of July-based Sugar reflections [1, 2], I'm going to offer some mostly unsolicited advice. (Sorry, Tomeu, but you asked me to write. :^) Dear Sugar Labs, In the past year, you succeeded in removing two important barriers to entry for new developers: you have created a distinctive brand and you freed Sugar from the XO. What's next? Here's a four-part RFC: 1. Could we embrace POSIX and the RESTful Web throughout our software [3]? POSIX and HTTP are the mother tongues of our ecosystem and developer base. By embracing them, we make our software much cheaper to explore and to modify. 2. Could we live more within our packaging? This way, our packaging gets tested more quickly, we become more expert /at/ packaging, we make friends in our distros, we get better packaging, and our releases become easier! 3. Could we make ourselves more interesting to be around, for example by saying maybe we could... or I have... (and you can too...!) more frequently than we say I can't.? Our strengths lie in our big, sexy, /powerful/ ideas. We can't shrink from these ideas; they sparked our desire to contribute and they will do so for others. (Otherwise, we will fade.) 4. We could do more to help one another to develop as may be necessary to advance those big, sexy ideas. (Anecdote: I don't think any of us here today started off understanding much about communities, UI design, networking, release management, quality assurance, or large-scale coding; I just see lots of people who looked for people who were smarter and more knowledgable than they were and who worked really hard to catch up. We should do more of that.) xoxoxo, Michael P.S. - In the spirit of walking the walk, I'll also share one of my own recent puny efforts in the direction outlined above: http://wiki.laptop.org/go/Network2 Regards, Michael [1]: http://lists.laptop.org/pipermail/sugar/2008-July/007304.html [2]: http://lists.laptop.org/pipermail/sugar/2008-July/007390.html [3]: (With suitable hacks under the covers of FUSE and DNS.) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Unified Objects (was Unified bundles)
Wade, Here are a couple of /very/ quick thoughts for you. Please let me know which ones are helpful and which are simply confusing (or misguided). Michael The basic premises of this rant are that we need to be able to mix, match and dissect activities so therefore activities should consist of remixable facets, i.e. nestable layered segments. Furthermore, Filesystems rock for nestable layered segments, so let's use more of them! Now here's a mess of ideas from which these three basic intuitions originate: 1. It would be nice to be able to generate various views of what the user can do with shell globs rather than by writing complicated queries over in-memory data-structures that have to be fully loaded and locked into RAM before you can render anything... 2. Activities need to expose their API to the shell. In particular, we /need/ to be able to get an activity to self-test a system for deps, to run non-graphical tests, to run graphical tests, to run network tests, to run a demo or tutorial of itself, to show its source, ... 3. One interesting way to think about (1) and (2), which I have previously discussed with Eben, is in the context of the Plan 9 plumber. Go read about it. 4. Modifying activities is currently a pain in Sugar because you have to reboot sugar for changes to take effect. Let's use inotify/dnotify/FAM/ or git-like fast change detection to fix that. 5. Scott has worked out some cool ideas for browsing, tagging, and version control in his journal2 and olpcfs2 work. Scott -- did you ever implement the GIO-based launcher? 6. Filesystems can be efficiently and incrementally shared over networks in standard ways; e.g. 9P, rsync, cerebro. Furthermore, we can ride the wave of advances in network filesystem research over the coming years. 7. If activities are supposed to have per-activity or even per-instance permissions, then Rainbow really needs a way to authoritatively distinguish activities (instances). This certainly means that some control of permissions is needed. If networks are involved, then this also means cryptography. Naturally, the crypto can be optional, can be implemented later, etc.; however, the spec still needs to define something workable. The major thing needed at the moment is a per-thread public key to be used to sign manifests of updates and a minimum cover over which to generate a manifest. (We might also specify a more inclusive cover as a handy error-detection mechanism.) 8. Pursuant to (7), it would be really good to use the same format for journal entries as for activities themselves. That way, the search, plumbing, network browsing, version control, permissions, and crypto stuff can be shared. 9. A rough list of facets that this format should expose: translations, HTML help, automated tests, permissions, integrity data, arch-specific optimizations, public APIs (incl. data, e.g. sound or icon libraries) for other activities, and UI continuations, i.e. resumable instances, i.e. Journal entries ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] http://www-testing.sugarlabs.org/
On Fri, Feb 27, 2009 at 11:56:52AM -0500, Benjamin M. Schwartz wrote: David Farning wrote: Sorry there was a typo in my last email the site is actually http://www-testing.sugarlabs.org/ I forcefully object to everything about this website. It is ugly, off-putting, unnavigable, unreadable, buggy, empty of any helpful information, and in many other ways among the worst websites I could possibly imagine for this purpose. It is a very cool javascript tech demo, which is not at all useful here. Meanwhile, the front page of the wiki is beautiful. It presents the visitor immediately with a statement explaining what Sugar is, and a bunch of clearly named links to learn more about Sugar and Sugar Labs. Scrolling down presents a wealth of introductory information about Sugar, presented in a logical fashion. It does all of this in a non-headache-inducing color scheme, using complete sentences. Clearly a lot of work has been put into this, and it shows. Christian, I wish I felt differently, but I agree with pretty much everything Ben said. In fact, I found myself so put off by the new design that I left the site after reading no more than two entries. I was particularly frustrated by the meaningless colors, the dark - light background transition, the useless sound bytes, and the invisible one-word menu that overlaps other text when I scroll. In more detail, this is not the Sugar design that I enjoy -- in Sugar: * Colors denote individual identity and contribution; they aren't uniform over a page and they aren't randomly regenerated on each visit. * Contrast is used carefully: I would never see a black menu with yellow text over a pure white background, nor a yellow menu with white text on a white background. (Both of which I observed.) * Text colors are never reversed for emphasis. * Views are scoped and zoomable, and information is usually arranged in visually pleasing layouts with gray-out filters or search; not organized hierarchically. (The exception is toolbars, which Eben redesigned in a fashion much more consistent with Sugar's design imperatives: http://wiki.laptop.org/go/Designs/Toolbars ) (At any rate, contrast the hierarchy-free Neighborhood View and the Home View with semi-hierarchical Journal or the (deeply hierarchical) source code layout.) * For better and for worse, icons are used everywhere in place of short text. Short text is presented only on hover. Now, as an alternate suggestion: why not use the desire for a nicer website as an opportunity to test out our actual underlying UI design principles? For example, I'd love to see a Sugar front-page that used the Frame and its zoomable Views for navigation, perhaps organizing hierarchical content with Eben's Toolbar design. Regards, Michael P.S. - Just think of the educational opportunity that's slipping away by not dogfooding the existing design work. :) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] RFC: Supporting olpc-ish Deployments - Draft 1
Folks, Pia Waugh (greebo) and I have spent a fair bit of time in the last month talking and thinking about what we can do in the next few months to best support present and future olpc-ish deployments (typically with XOs, typically running Sugar) and we'd like to share some of our thoughts with you. These thoughts are presented in draft form in order to solicit your feedback, which is eagerly awaited, and will likely be incorporated into future drafts. Regards, Michael -- 1. Motivation We think that many deployment-related needs are not being adequately met, particularly in the areas of: * knowledge-sharing and the ability to benefit from others' mistakes. * volume and quality of aid available for conducting deployments. * bandwidth, latency, and SNR of channels to other communities which work with deployments; e.g. other deployments, educators, software teams, distributions, researchers, consultants, and volunteers 2. Use Cases We're particularly interested in addressing these situations and needs: D1) I'm running a deployment... a) ...and I need help! Who shares my problem? Who can help me? b) ...and I want to do more! Who/what can I work with? c) ...and I want to share! Where do I go? What is needed? D2) I need to talk to people deploying XOs. a) Where do I go? b) What can I expect? D3) I'm working on a deployment plan. a) Where to I start? b) What have I forgotten? c) Am I using best practices? d) Can I get a review? D4) I need to know... a) real deployment numbers, b) maps, c) examples, d) photos, e) techniques, f) contact info, ... 3. Existing Resources for Use Cases Before we started, there were three basic mechanisms for addressing these use cases: 1) read the Deployment Guide and the Deployments page(s): http://wiki.laptop.org/go/Deployment_Guide http://wiki.laptop.org/go/Deployments http://wiki.laptop.org/go/Deployments_support 2) ask olpc-techsupp...@laptop.org. (Only available to large deployments?) 3) poke people on IRC. These three mechanisms are problematic because none of them can be relied upon, alone or in combination, to adequately address any of the use cases listed above. 4. New Resources for Use Cases So far, we've created two new resources which help bridge the gap: 4) weekly deployment support meetings, with minutes at http://wiki.laptop.org/go/Deployment_meetings#Meeting_notes which get aggregated each month into 5) a Deployment FAQ, http://wiki.laptop.org/go/Deployment_FAQ similar in form and spirit to the G1G1 http://wiki.laptop.org/go/Support_FAQ We think that these two new resources, in combination with the pre-existing resources, will help us provide the next level of support for our use cases. 4. Projects We presently have several ongoing (interrelated) projects which you might like to become (more deeply) involved in: P1) Keep improving the deployment support meetings -- so far, so good! -- your participation in these meetings is our best current source of new content for the Deployment FAQ and for... P2) Organize material captured in the meetings as FAQ entries -- the meeting minutes are chronological, which is good for minutes, but not particularly helpful for random-access reads. -- FAQ entries seem like a good compromise between maintenance cost, timeliness, and satsifaction of the use cases P3) Update the Deployment Guide -- The Guide is now ~1 year out of date -- and it leaves too much to the imagination: just look at its advice on critical areas like connectivity, content acquisition, and means of participation in the larger community of 1-1 educational laptop programs in general and XO deployments in specific. 5. Status Project P1 (meetings) is rolling along quite happily only one month after its inception but it could use your help in order to become even more vibrant, dense, and ingrained in the olpc-psyche. Project P2 (FAQ) is just beginning -- we've done a first rough-cut which you should review for us and help us edit down into something awesome! Project P3 (Guide updates) is just a twinkle in our eyes -- and it needs your help to fly! In particular, three different mechanisms have been tentatively proposed for how to accomplish the update(s): a) By sprints, like the FLOSS Manuals sprints that created the XO and Sugar manuals. b) By accretion, like the rest of the wiki, performed on a piecemeal basis by participants in the deployment support meetings. c) By issue-tracking, like
Re: [IAEP] [SLOBS] Governance.
On Sat, Jan 31, 2009 at 08:14:22PM -0500, Walter Bender wrote: Here is my short-term suggestion: Why don't we appoint you as a monitor of the slobs list. No, thanks -- I don't feel that I can be responsible for SL's organizational conscience. Instead, I believe that this is something that we each must be responsible to ourselves and to one another for maintaining. Any message that you think should be public, send to iaep (blipping out names if necessary). I wouldn't want such a monitor to publish documents that the audience couldn't agree among themselves to publish -- that would be neither transparent nor consensus-based. On the other hand, if the audience can agree to publish the materials, then why not just send the messages to iaep@ in the first place? That'll prevent us form inadvertently keep secrets from the community. More likely, it will lead people who are on the fence about transparency and consensus-based decision-making to communicate by means of a different side-channel than sl...@. Perhaps a better solution would be to find ways for people who are on the fence about transparency to adjust to its requirements while still achieving their true ends? Regards, Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] How to Make Activity Designers Happy , Parts I and II
On Fri, Jan 02, 2009 at 12:25:13PM -0800, Bryan Berry wrote: On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote: (3) We need lots more Activities. While there is consensus on this point, there is not consensus on the best way to get a lot more Activities. That is, pulling a lot more developers into building learning activities that run on Sugar. I see some orthogonal proposals at work: a) supply better compatibility with existing X11 apps. b) offer genuine support for popular software platforms (e.g. flash and java?) even on space-constrained hardware platforms like the XO. c) catalyze the creation and improvement of free authoring and remixing environments for popular mime-types uncovered by existing free offerings or the available environments are unusable on the available hardware Consequently, it seems to me that the most useful political discussion we can have now is over how to work through the obvious conflict between the libre folks and the usability folks. Thoughts? Michael P.S. - (By all means, please continue the practical idea-by-idea brainstorming occuring on Tomeu's thread in parallel with this meta-thread!) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] How to Make Activity Designers Happy , Parts I and II
On Fri, Jan 02, 2009 at 04:01:34PM -0500, Walter Bender wrote: On Fri, Jan 2, 2009 at 3:52 PM, Michael Stone mich...@laptop.org wrote: On Fri, Jan 02, 2009 at 12:25:13PM -0800, Bryan Berry wrote: On Fri, 2009-01-02 at 15:18 -0500, Walter Bender wrote: (3) We need lots more Activities. While there is consensus on this point, there is not consensus on the best way to get a lot more Activities. That is, pulling a lot more developers into building learning activities that run on Sugar. I see some orthogonal proposals at work: a) supply better compatibility with existing X11 apps. b) offer genuine support for popular software platforms (e.g. flash and java?) even on space-constrained hardware platforms like the XO. c) catalyze the creation and improvement of free authoring and remixing environments for popular mime-types uncovered by existing free offerings or the available environments are unusable on the available hardware Consequently, it seems to me that the most useful political discussion we can have now is over how to work through the obvious conflict between the libre folks and the usability folks. Thoughts? I guess I am slow. Can you spell out this obvious conflict in the context of this discussion? Sure. Basically, I think we're in an iterated prisoner's dilemma situation. The dilemma arises from the facts that a) Sugar exists in both one global and myriad local environments and b) Pairs of people frequently have access to resources which they are unable to share; e.g. expertise, time, or non-redistributable code. Fact (a) affords us a range of strategies during each iteration varying between the hypothetical extremes of acting locally and acting globally. Fact (b) means that acting locally frequently affords us payoffs which cannot be shared with our partners in the game or which are actively detrimental to those other players. The situation is iterated because we seem to have to make decisions along these lines every month or so. The connection to the libre vs usability dichotomy that I mentioned above is that I see the libre folks as asking all players to choose strategies which optimize global payoffs at the (great) expense of local payoffs; and vice-versa for the usability folks. Does this explanation help clarify things for you? Would a different metaphor be more helpful? Regards, Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] How to Make Activity Designers Happy , Parts I and II
On Fri, Jan 02, 2009 at 06:12:40PM -0500, Walter Bender wrote: Can you please cite a few examples to help ground me further? Let's try: * the Etoys/Debian fight? * the F6/F7 timeframe Java fight? * the Debian/Fedora fight? (and the Ubuntu/Debian fight?) * the activity packaging formats fight? * the initscripts fight? * the vserver fight? * the libertas fight(s)? * the Bitfrost/ fight? * the Journal/file manager fight? * the livecd-tools / pilgrim+puritan fight? * the stock vs. patched kernel fight? * the UY, ET, and NE modification fights? * deciding how and where to seek donations to OLPC (or alternately, to market and sell XOs, depending on your perspective). (2) to what extent they incur great expense. I agree that it's hard to measure. (I still think it's worth trying to think about.) The most significant factor seems to be whether and how you count opportunity costs. Three random examples: * The early Smalltalk vs. Python arguments * Bryan's point about choosing a PyGTK stack vs. a Javascript-ish stack * Fedora vs. Debian Presumably the 2007 decision to not aggressively pursue Flash support on the laptop is an example of a choice in the libre category? I'm counting it as such. (Although, at the time, the decision was driven as much by some pragmatic integration concerns as by ideology.) As with some current debates about key autonomy, the ideological battle strongly influences our willingness to do the implementation/integration work. And the decision to use a GNU/Linux distribution as oppose to XP (we would have had to have designed a different laptop had we gone down that path). Yes. But this is water that is over the dam, not a recurring theme. It seems to me to be a recurring theme for OLPC; perhaps Sugar Labs will do better. There have been local decisions that have incurred expense, e.g. Uruguay made changes to the base image (not many that are relevant to Sugar) due to the needs of their deployments. As I see it, it had everything to do with exploiting local opportunities vs. acting globally. Libre-ness is just one reason that a _few_ people (who are active here) seem to put forward for why we _shouldn't_ exploit those purely local opportunities. But this had nothing to do with libre vs. usability. libre-prizing and usability-prizing are just contingent attitudes which seem to me to bias people towards optimizing for specific locales (including, occasionally, the global one). Lots of other contingent attitudes have the same effect. I brought up libre and usability because they seemed to me to be prominent in the current thread. Bryan's point about drag-and-drop and the lack of applications addressing fundamentals don't seem to be correlated to this dichotomy. Correct -- it's an interesting and worthwhile but unrelated criticism of the status quo. Michael P.S. - Please let me know if you'd like to me to try to analyze some of the examples I suggested in more detail, e.g. if it's unclear what I mean, why I think they're relevant, or if you're bothered by the fact that they can be interpreted in several valid ways. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] a (distro) release with sugar 0.81?
On Sat, Nov 29, 2008 at 09:20:34PM -0500, Luke Faraone wrote: According to http://sugarlabs.org/go/Image:Sucrose-0-82-roadmap.png , no new features were developed in sugar after 0.81.3, we were in a feature freeze until the 0.82 release. All changes after then are translations or bugfixes. There were, however, a lot of bugfixes. Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [sugar] OLPC + Sugar
On Thu, Nov 27, 2008 at 03:16:09AM +0100, Ivan Krstić wrote: it's hard to divine whether your statement in this matter -- or, in fact, a statement made by anyone but Nicholas -- carries any weight whatsoever. Such is life; I see no reason to let such doubts stop me. For 500K kids, Sugar+OLPC is a great thing and making Sugar better is one of the easiest ways for me to make that already great thing an even better thing for those kids. Honestly, for the present moment, that's enough for me. Michael P.S. - Would you find it helpful if I included a force majeure clause in any similar remarks I make in the future? ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [sugar] Sugar Digest 2008-10-27
On Mon, Oct 27, 2008 at 08:12:37PM -0400, Walter Bender wrote: 2. What would creating a Sugar Activity require from me and what benefits would it bring? I've been pondering this question in some depth for the last week using my list summarization problem as a model. In hopes of offering something useful to other people facing this question, I have also started an outline covering some of the challenges and goals I have discovered http://dev.laptop.org/git?p=users/mstone/summarize-activity;a=blob;f=NOTES;hb=HEAD in preparation for a talk that I intend to give on this subject in November. Would you care to speak alongside me? 7. ¿Qué? ¿Cómo? ¿Por qué? ¿Para qui?: We also discussed the role that a portfolio might play in Sugar. What? How? Why? For who? are questions that are part of the teacher/student discourse in Peru. They are also questions that are important to the select-reflect-perform cycle of portfolio assessment. Scott, Rafael, Sebastian and I spend quite a bit of time discussion possible approaches to building a Portfolio Activity (we agreed that it makes sense to make it a separate Activity from the Journal for the time being). My hair-brained idea is to make a Turtle-Art-like snap-together programing Activity to create narrative presentations from items selected from the Journal. I'll make some sketches in the coming days and post them to the wiki. The team at the ministry was very upbeat about portfolio tools, regardless of the implementation details. This work sounds like it complements another talk I hope to give in November describing several conversations I've had recently with a mixed tech/learning-team audience on the subject of how can small activities be combined to make bigger activities?. We have proceeded by identifying three model use cases: 1) Going on a hike: a) Making a manifest of what to take which can be refined for future trips. b) Recording beautiful scenes that I pass. c) Taking measurements at my destination. d) Returning and combining my measurements and observations with those of friends who went on similar hikes to other destinations. 2) Developing a recipe: a) Writing a recipe draft and recording the stages of preparation. b) Sending the draft to a friend who will try to follow the recipe and who will suggest improvements. 3) Running a physics jam: a) Preparing for the jam by snagging some sample physics-based activities. b) Making a new physics-based activity, perhaps by modifying one of the samples. c) Capturing developer commentaries and screenshots explaining the new activity as it is created. d) Publishing the results to, e.g., a wiki. which we are in the process of exploring with paper mockups. Questions: * Do you have favorite model interactions that you'd like to share? * Anyone else want to talk about this subject in November besides Walter and me? 9. On collaboration : Juliano Bittencourt has stirred the pot regard the Sugar collaboration model. In a discussion on the developers mailing list (http://lists.laptop.org/pipermail/devel/2008-October/020588.html) he raises the issue of synchronous vs asynchronous collaboration, arguing that too much emphasis has been given over to the former, when the latter is generally more useful in a school setting. I agree with him to a great extent. I agree. (Tangentially, one fundamental goal for my summarization project (described above) is to experiment with async-collab in the sense in which summarization collaborates with the data being summarized as more data accumulates over time. (If I have success in this area, then I might try something fancier too. We'll see.)) To some extent, Juliano's point was less in regard to synchrony and more in regard to the lack of any means within Sugar to maintain persistence of a collaboration over a longer time frame than a single interactive session. This omission is will in part be filled by services external to Sugar, such as Moodle or AMADIS. However, some aspects of the yet-to-be-implemented Bulletin Board would also meet these needs. (Better versioning in the Journal/Datastore—in the roadmap for 0.84—will play a role as well.) The Bulletin Board is designed to be a place for the persistent sharing of objects and actions between a group of collaborators. In some sense, one could think of it as a share, persistent clipboard. Bulletin Boards would be created in support of group projects that involve multiple activities and multiple sessions. We should develop a requirements document and architectural description of what is needed in order to both best leverage existing tools and set realistic goals for any Sugar developments. I think that the technologies you mention are all incidental to the essence of asynchronous collaboration, which I take to be diff-and-merge (or perhaps 'guided-cut-and-paste'). To see why, consider the
Re: [IAEP] Narrative.
Bill, Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, and Bobby Powers on my interpretation of narrative as it might apply to a user interface designed for engaging children in the world of learning: http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 === Highlights * By narrative, I mean a rational sequence (or graph) of events. * It's rather hard to use XOs to prepare direct lessons. By direct lesson, I mean a guided learning experience, usable in variable network conditions, which minimizes the amount of decision-making and navigation that the end-user needs to perform in order to experience 'the whole thing' regardless of what software implements each individual experience contained in the lesson. === Toy Problem Concretely, suppose I invent a new Python trick like the ones at http://wiki.laptop.org/go/User:Mstone/Tricks How might a prepare a slick explanation for an inexperienced user? * I might write up a web page for my trick, then write a Pippy bundle showing off the trick in a toy program, then give a pointer to a git repo containing an instance of the trick in 'production'. Question: How do I write web pages on an XO? Question: Do I have to be able to read in order to find and run the Pippy bundle? * I might write up a larger Pippy example for my trick in the literate style. I might also create a puzzle revolving around integrating the trick into some sample code. I might include links to 'advanced reading' or more examples in comments in the source code. Question: Pippy doesn't know anything about hyperlinks. Will my readers? Question: I must either comment out my puzzle so that the example can run or I must provide it in a separate bundle. How many users would figure out how to try both the example and the puzzle? * While not obviously applicable to this specific example, two other common solutions to this sort of problem include the scripted transitions between freeform experiences idea common to wizards and role-playing games and the 'build a custom but user-editable program' idea underlying most EToys lessons. === Larger Concerns Since Sugar is strongly concerned with UI unification, it's worth spending more time thinking about how well each of the solutions to your favorite toy problem integrates with encompassing narratives of reflection, criticism, and human collaboration. (None of the solutions I've proposed above satisfy me in any of these regards.) In any case, I hope this followup helps explain the motivation and 'line-of-thought' behind my initial email. Please discuss. Regards, Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Narrative.
Bryan Berry wholly captured my attention tonight when he said (in summary): Sugar offers an excellent mode for discovery but no excellent way to manipulate narratives. Both discovery and narrative are essential for learning. [1] This statement seems to me both indisputable and damning; if true, it strikes to the core of the claim that Sugar is appropriate for learning. Even though Bryan has already found some partial solutions to this problem [2], we should take time to debate the more primitive thesis that: Narrative is a basic component of much educational material which Sugar ought to 'natively' recognize, respond to, and manipulate. so that we may decide whether this issue should receive a greater share of our limited design and implementation resources. Regards, Michael [1]: Sugar presently records actions which may occasionally be decomposed into narrative or situated within an external narrative; however, Sugar is presently blind to these relationships. [2]: Bryan is currently encoding narratives in HTML and is attempting to use Offline Moodle to make this cheaper to support. I decided to write this email because I believe that it might well be worth our time to either give him a hand with his effort or to bake support for similar use cases directly in to Sugar. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Teacher in OLPC-Sur list enchanted to see his idea integrated, into global Sugar update [First approach] (luis ACEVEDO)
On Fri, Sep 26, 2008 at 12:57:45AM -0700, Edward Cherlin wrote: On Wed, Sep 24, 2008 at 9:29 AM, Walter Bender [EMAIL PROTECTED] wrote: There are still a few loose ends to tie with the Turtle Art modification. I am trying to make it into somewhat of a case study that can be hopefully a catalyst not just to rote imitation but also to some deductive or model-based thinking about thinking. Also, the exercise has raised a few questions for me about our process that I hope to address/document. I realize that teachers don't have time to be developers, but I aspire that everyone will move towards all kinds of appropriation. I'm looking forward to the day when our graduates start to take over the teachers' colleges, and all of the teachers who have been programming since third grade or so get together to share the development of new interactive textbooks based on software that is built for children to modify. Alas, I wish that OLPC had included the chapter on Modifying Sugar in their Help activity... Second the motion. Walter, Luis, I just checked with Seth who mentioned to me that a 'Modifying Sugar' exists but that it has been excluded from Help to date because it seemed immature in comparison to other chapters. Fortunately, we have an activity updater! Therefore, if folks on this list can get that chapter into shape then I can easily imagine including it in a future version of Help which might be downloaded by every user of 8.2.0 who manages to find fast network access. Regards, Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
