Re: [IAEP] SoaS as a Sugar Labs project.
On Mon, Aug 24, 2009 at 01:50:25PM -0400, Greg DeKoenigsberg wrote: Fedora aims for a lightweight [compromise to foster intiatives]: * Special Interest Group + Can be created by anyone + One leader (i.e. the person who requests the mailing list) + No governance expected or required + No accountability in particular + Can apply for Project status as it grows * Project + Usually starts as a SIG and is, at some point, blessed by the Board + Full governance + Weekly meetings and minutes mandated + Expected outcomes + Accountability to the Board Those seem like what Fedora gets out of SIGs / Projects. What does the group get out of being a SIG / Project? The next question will be: what does SugarLabs want to get and give from its Projects. --g Martin pgpkYbiNICqcC.pgp Description: PGP signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] activities.sugarlabs.org - xo
For some reason Browse on my XO is having difficulty getting anything from activities.sugarlabs.org but my PC with Firefox is OK. Its just activities.sugarlabs.org and its subdirectories http://www.sugarlabs.org/ is ok http://wiki.sugarlabs.org/ is ok can anyone confirm that there is a problem? Thanks Tony ___ 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.
On Tue, Aug 25, 2009 at 12:45, Martin Langhoffmartin.langh...@gmail.com wrote: On Tue, Aug 25, 2009 at 2:00 AM, David Farningdfarn...@sugarlabs.org wrote: This is the goal. But as Martin correctly points out, policies and rules come at a non-zero price, thus we must be careful that the benefits outweigh the costs. Thanks! Best summary of what I wanted to say :-) Some additional notes that may be of use. (My excuse? Code is compiling on the other window.) Thinking back on how large projects handle subprojects and component splits... there are clearly 2 ways of splitting things 1 - By 'architectural' and technical divisions -- the way you guys have sucrose, lactose and various pepsins :-) 2 - By responsibility, and here I mean we consider it important enough that we'll get it done, regardless of where it is in the stack. Many projects have a core and contrib split showing exactly this distinction. It is useful to be aware of the two approaches, and to use them where appropriate. Internally and technically #1 matters. User-facing #1 is endlessly confusing and IMHO #2 makes more sense. When, as a developer, you have 3 bugtrackers to look into for the _same_ bug in the same code (or in the interaction of 2 tightly coupled components) you are in a situation where #1 is being used, and does not help. At least as a developer you know the (architectura, social, political) reasons behind the proliferation of bugtrackers. Alas, only your most involved end users will know how to navigate them. (Small example: Right now, just one simple dev task we're coordinating with Hamilton involves 2 bugtrackers. With SoaS moving out, it'll involve 3 if we do things properly. Not the end of the world, and yet...) IMHO, having things neatly laid out for developers is not that important. We know that SoaS is actually a custom Fedora, and that Browse.xo is not Sugar. From a user's PoV, bugs in SoaS and Browse.xo are Sugar doesn't work. Of course, we'll educate the involved users so we can debug the problem with them. But a well defined point of entry for all things Sugar (docs, bugs, etc) is a major win -- if they knew all about your components and which one is causing the problem, they'd probably have a patch too :-) Users would enter any bugs they find in only one bugtracker, the one setup for the distro they are using: SoaS, Fedora, Ubuntu, etc. Developers would submit patches to the bug tracker of the module, if someone puts the energy required to debug and write a good patch, I think finding the right bugtracker won't be a problem for that person. If someone feels very strongly about having downstream bugs in the same bug tracker as upstream sugar, then that person is welcome to create a bug triaging team and keep the bugs triaged. Regards, Tomeu cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] activities.sugarlabs.org - xo
On Tue, Aug 25, 2009 at 08:52:08PM +1000, fors...@ozonline.com.au wrote: For some reason Browse on my XO is having difficulty getting anything from activities.sugarlabs.org but my PC with Firefox is OK. Do you mean you can't even open activities.sugarlabs.org page or you can't download .xo bundles? activities.sl.o could be on hard pressure due to many downloads at the same time, could you reproduce it now(it works fine in my case) Its just activities.sugarlabs.org and its subdirectories http://www.sugarlabs.org/ is ok http://wiki.sugarlabs.org/ is ok can anyone confirm that there is a problem? Thanks Tony ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Aleksey ___ 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.
On Tue, 25 Aug 2009, Martin Dengler wrote: * Special Interest Group + Can be created by anyone + One leader (i.e. the person who requests the mailing list) + No governance expected or required + No accountability in particular + Can apply for Project status as it grows * Project + Usually starts as a SIG and is, at some point, blessed by the Board + Full governance + Weekly meetings and minutes mandated + Expected outcomes + Accountability to the Board Those seem like what Fedora gets out of SIGs / Projects. What does the group get out of being a SIG / Project? The next question will be: what does SugarLabs want to get and give from its Projects. A SIG gets a mailing list and a corner of the wiki. That's it. A Project gets a mailing list, a corner of the wiki, a lot more focus on resources to accomplish their missions, and a bunch of headaches and people asking pointed questions. :) --g -- Computer Science professors should be teaching open source. Help make it happen. Visit http://teachingopensource.org. ___ 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.
El Mon, 24-08-2009 a las 20:58 +0200, Martin Langhoff escribió: And also... and completely from the outside... I'll apologise in advance for saying something I know might be controversial. I worry that SL seems to have -- for a external party like me -- more bureaucracy than it has people doing. IMHExperience, the projects I enjoy working on, and that I see being productive have a much lower procedure/label/committe : contributor ratio. I don't necessarily disagree with you, but just 2 days ago I was offered an advice on the other side of the spectrum by Michael: he notes that a lot of important things are falling through the cracks because nobody organizes the available resources. His suggestion is to introduce real project management into the game, which is basically what David's Projects idea seems to bring. My initial reaction was that community projects work by employing maintainers rather than project managers. The substantial difference between the two is that a maintainer does not proactively set priorities and allocate resources. There was an hidden assumption in my thinking that a maintainer /could not/ tell people what to do based on the fact that his workers are unpaid volunteers. But, as Michael pointed out, besides the volunteers who are strongly self-motivated, there are also many others who are seeking for guidance and would actually feel confused by the fuzziness and apparent lack of direction of an organization with plenty of individual freedom. Some wasted effort happens when a volunteer looses focus or motivation along the way and nobody else takes over. This is common even among highly successful communities such as the Linux kernel hackers. The job of any half-skilled project manager would be detecting these stalls and mitigate them whenever possible. Hopefully, the formalization of our development efforts into well-defined entities called projects led by officially appointed project leaders will help rebalance things. Time for me to shut up. From now on I assume you know about these risks, and won't mention the topic in polite company no more. After all, I am not working my ass off on SL, you are. Thanks for your patience :-) A meta-comment on your post: you don't need to apologize and be shy for offering your criticism, no matter how many people will disagree with you. A culture of open criticism is essential for improving our processes, especially when a good advice comes along with the critical part. I recently got useful criticism from Bemasc, Christoph and Daniel on #sugar regarding our relationship with Deployments. Their feeling is that we didn't do enough to get them involved, mine is that our efforts to reach out have been largely unsuccessful for reasons I do not fully understand. By discussing it through, it became apparent that we actually had in mind two fundamentally different things: I'm interested in getting *contribution* from deployments rather than offering them *support*. I now realized that the two things should go together and we probably shouldn't ask for contribution without offering some support in exchange for it. This is the essence of participation, the antithesis of passive dependence, which would be unsustainable both for SL and for its deployments. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ 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.
On Tue, Aug 25, 2009 at 4:13 PM, Bernie Innocentiber...@codewiz.org wrote: My initial reaction was that community projects work by employing maintainers rather than project managers. Exactly. A PM can only fire you. A maintainer/leader can show his/her priorities in showing areas of focus, encouraging some changes, discouraging others, and implementing strategies like newcomers have to maintain an unloved chunk of code for a while (and show maturity realising that a refactor may not be accepted) or before I take your feature patch, let's see that cleanup bugfix series finished first. There was an hidden assumption in my thinking that a maintainer /could not/ tell people what to do based on the fact that his workers are unpaid volunteers. Good leaders guide the project, sometimes softly and subtly, sometimes more... openly :-D At a very basic level, it's a carrot and stick thing. The job of any half-skilled project manager would be detecting these stalls and mitigate them whenever possible. With _what_ tools? A PM hasn't got the carrot (which is usually the recognition of the leader: Torvalds accepted my patch!). A PM is a manager. A manager is usually someone who can fire you if you don't do your job. A meta-comment on your post: you don't need to apologize and be shy for Um, I do. You guys are doing the work, so you know a lot more than me about how SL works, or doesn't. I've penned this reply because the SL crowd showed some agreement. If you guys tell me I am off the mark, well, I am outside and bound to misunderstand the org from here. It might tell you about external perceptions, but it would still mean that I am wrong. (And I think this kind of respect is important. All organisations are misunderstood. One only need to read olpcnews to see.) I recently got useful criticism from Bemasc, Christoph and Daniel on #sugar regarding our relationship with Deployments. Their feeling is That is interesting. I am starting to work more with deployments in LatAm, perhaps the deployments that are easier to help and easier to get help back from. Still, in general terms it might be years before deployments are in a position to repay your help. For SL sustainability in terms of effort, I'd cast a wider look. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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.
On Tue, Aug 25, 2009 at 16:40, Martin Langhoffmartin.langh...@gmail.com wrote: Still, in general terms it might be years before deployments are in a position to repay your help. For SL sustainability in terms of effort, I'd cast a wider look. I don't think we really expect to be repaid, at least my opinion is that it's sad to see so much duplicated work and wasted effort because knowledge is not where it's actually needed. Just that. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ 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.
On Tue, Aug 25, 2009 at 4:47 PM, Tomeu Vizosoto...@sugarlabs.org wrote: I don't think we really expect to be repaid, at least my opinion is that it's sad to see so much duplicated work and wasted effort because knowledge is not where it's actually needed. Just that. Completely agree with you. My point was about Bernie's statement; below slightly edited: I'm (mainly) interested in getting *contribution* from deployments In both aspects -- in the coming months I hope to be able to help better communication between the various parties. Deployments, OLPC, Sugar. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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.
On Tue, Aug 25, 2009 at 17:03, Michael Stonemich...@laptop.org wrote: El Mon, 24-08-2009 a las 20:58 +0200, Martin Langhoff escribi=F3: And also... and completely from the outside... I'll apologise in advance for saying something I know might be controversial. I worry that SL seems to have -- for a external party like me -- more bureaucracy than it has people doing. IMHExperience, the projects I enjoy working on, and that I see being productive have a much lower procedure/label/committe : contributor ratio. I don't necessarily disagree with you, but just 2 days ago I was offered an advice on the other side of the spectrum by Michael: he notes that a lot of important things are falling through the cracks because nobody organizes the available resources. His suggestion is to introduce real project management into the game, which is basically what David's Projects idea seems to bring. For the record, I consider my puny efforts to offer more support for Martin's and Greg's remarks than for David's. (The analysis is simply that our current situation is unsurprising given the facts that, first, SL seems to consist more of leaders than of followers and second, that there seems to be a real dearth of people who care more about getting other people unstuck than about making progress on their own pet projects.) (Though, obviously, I'm more guilty than most here.) A meta-comment on your post: you don't need to apologize and be shy for offering your criticism, no matter how many people will disagree with you. Actually, he does need to apologize and to be shy because doing so makes it easier for folks to hear what he's trying to say. (In our current environment, it works rather similarly to good-cop/bad-cop.) I recently got useful criticism from Bemasc, Christoph and Daniel on #sugar regarding our relationship with Deployments. Their feeling is that we didn't do enough to get them involved, mine is that our efforts to reach out have been largely unsuccessful for reasons I do not fully understand. Here's another reason for you to consider: I have come to believe that many people involved in deployments have *learned* that they're not going to get anything useful out of interacting with SL because: 1. SL has largely ignored the feedback supplied by these deployments in 2007-2008 and exhaustively documented by Greg Smith and S Page at http://wiki.laptop.org/go/Feature_roadmap#Roadmap and also because 2. most members of SL express comparatively little interest in developing seriously for the XO-1 and for the specific network, cognitive, and logistics resources of of these deployments. I don't understand how this helps to this discussion. It's obvious that Sugar Labs doesn't have the resources to take all software development for OLPC deployments. What we propose is NOT getting hired by the countries for taking over their responsibilities, but rather that working in Sugar Labs with other organizations with similar interests is favourable for them. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ 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.
On Tue, Aug 25, 2009 at 17:50, Martin Langhoffmartin.langh...@gmail.com wrote: On Tue, Aug 25, 2009 at 5:38 PM, Tomeu Vizosoto...@sugarlabs.org wrote: I don't understand how this helps to this discussion. It's obvious I think Michael just means that there are hints from coming deployments as to general priorities, and SL is setting priorities on a different schedule. Not about doing deployment's work. SLs is setting priorities? How so? Of course, there are various groups with ideas as to what's important, and one group (the doers at SL) wins by sheer force of... action. :-) The doers have asked for input on what they should work on and have setup a process for non-doers to manifest their views. Then doers have executed as much as they could. Some non-doers that expressed their opinions got some stuff they wanted done, the ones that didn't expressed their opinions might not have had that luck. Let me repeat that I don't think SLs is here to replace OLPC, just to provide a place for people who are investing in Sugar to do so more effectively. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] OLPC Bangladesh
Hi all, A quick announcement about the creation of a project to start OLPC in Bangladesh. A fan page has been created to foster, cultivate and develop a fan base for this effort in Bangladesh. http://www.facebook.com/pages/OLPC-Bangladesh/131357564135 Please join, to show your support. For those wishing to go beyond the fan page the following communication channels have been created: 1) Mailing list: http://lists.laptop.org/listinfo/olpc-bangladesh 2) Wiki page: http://wiki.laptop.org/go/OLPC_Bangladesh Please feel free to pass on the news! Best wishes. Faisal -- One Laptop per Child (OLPC) Opening new opportunities to children the world over. http://laptop.org/en/vision ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Identifying, engaging, and empowering
The mission of Sugar Labs® is to produce, distribute, and support the use of the Sugar learning platform; it is a support base and gathering place for the community of educators and developers to create, extend, and teach with the Sugar learning platform. Every day or so, I try to take a look at the Sugar Labs mission to help me keep my focus. There are millions things that I want to do, both personally and for Sugar Labs. But, I only have so much time (and money) I can afford to spend in a given day. Thus, I must limit myself. Sugar Labs faces these same sort of decisions. Sugar Labs is composed of participates who have both personal and Sugar related things they want to do. Sometimes, when I chose _not_ to do something, it is because it is wrong. Don't chop down your neighbour's tree. But, in the majority of cases I usually _don't_ find myself choosing _not_ to do something. Instead, thing don't get done because other activities more closely with my goals, available resources, and energy. This process seems to hold true for most people... and for projects such as Sugar Labs. I have been extremely impressed and inspired by many of the post on the recent SoaS as a project Thread at http://lists.sugarlabs.org/archive/iaep/2009-August/007842.html . 1. There are some widely differing viewpoints... but that happens whenever smart people engage in discussion. 2. There are frustrations about things not getting done... but there is a constant theme that personal work causes results. 3. There is extensive use of the word 'we'... as in by working together 'we' can solve the problem. 4. There is a reoccurring theme of I don't care what you do, just stay out of my way so I can get back to work. The take away that I got was the strong need, and desire, to Identify, Engage, and Empower _doers_. This aligns nicely with the idea behind projects. Sugar Labs is, by definition, the upstream of the rest of the Sugar ecosystem. As the upstream, there is, and will continue to be, a strong cultural emphasis on upstream activities. Sugar Labs is, by design, a participatory organization. As a participatory organization, there is, and will continue to be, a strong cultural emphasis on working together as a community rather then splitting the world up as producers and consumers. As we think about projects, let's think about how they can identify, engage, and empower _doers_ david ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] activities.sugarlabs.org - xo
Thanks Aleksey (for the benefit of others we discussed this offlist last night my time) Aleksey was able to access the site OK but it has been offline on my XO for 48 hours, there was a period last night of about an hour when it was offline on my PC too. It appears to be a routing issue between my ISP and the server. Tony On Tue, Aug 25, 2009 at 08:52:08PM +1000, fors...@ozonline.com.au wrote: For some reason Browse on my XO is having difficulty getting anything from activities.sugarlabs.org but my PC with Firefox is OK. Do you mean you can't even open activities.sugarlabs.org page or you can't download .xo bundles? activities.sl.o could be on hard pressure due to many downloads at the same time, could you reproduce it now(it works fine in my case) Its just activities.sugarlabs.org and its subdirectories http://www.sugarlabs.org/ is ok http://wiki.sugarlabs.org/ is ok can anyone confirm that there is a problem? Thanks Tony ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Aleksey _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] in the nicest possible way
This is a plea. Sugar has not built successfully for the last five days or so on Ubuntu904. All the changes that other devs have made cannot be tested because one(or more) dev didn't test the build after committing changes. We're all, AFAIK, volunteers. Devs, please try to make the volunteer tester's job a little easier; compile/build Sugar successfully before committing changes to GIT. http://dev.sugarlabs.org/ticket/1238 with regards, Dennis ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] in the nicest possible way
Every 12 hours or so sugar is build from scratch on several distributions via a buildbot. see http://buildbot.sugarlabs.org/ . It looks like 904 is build on a stock u904. Have you tried deleting your sugar-jhbuild dir and grabbing recloning from git? david On Tue, Aug 25, 2009 at 6:34 PM, Dennis Danielsdennisgdani...@gmail.com wrote: This is a plea. Sugar has not built successfully for the last five days or so on Ubuntu904. All the changes that other devs have made cannot be tested because one(or more) dev didn't test the build after committing changes. We're all, AFAIK, volunteers. Devs, please try to make the volunteer tester's job a little easier; compile/build Sugar successfully before committing changes to GIT. http://dev.sugarlabs.org/ticket/1238 with regards, Dennis ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ 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.
On 25 Aug 2009, at 16:49, Gary C Martin wrote: On 25 Aug 2009, at 16:03, Michael Stone wrote: El Mon, 24-08-2009 a las 20:58 +0200, Martin Langhoff escribi=F3: And also... and completely from the outside... I'll apologise in advance for saying something I know might be controversial. I worry that SL seems to have -- for a external party like me -- more bureaucracy than it has people doing. IMHExperience, the projects I enjoy working on, and that I see being productive have a much lower procedure/label/committe : contributor ratio. I don't necessarily disagree with you, but just 2 days ago I was offered an advice on the other side of the spectrum by Michael: he notes that a lot of important things are falling through the cracks because nobody organizes the available resources. His suggestion is to introduce real project management into the game, which is basically what David's Projects idea seems to bring. For the record, I consider my puny efforts to offer more support for Martin's and Greg's remarks than for David's. (The analysis is simply that our current situation is unsurprising given the facts that, first, SL seems to consist more of leaders than of followers and second, that there seems to be a real dearth of people who care more about getting other people unstuck than about making progress on their own pet projects.) (Though, obviously, I'm more guilty than most here.) A meta-comment on your post: you don't need to apologize and be shy for offering your criticism, no matter how many people will disagree with you. Actually, he does need to apologize and to be shy because doing so makes it easier for folks to hear what he's trying to say. (In our current environment, it works rather similarly to good-cop/ bad-cop.) I recently got useful criticism from Bemasc, Christoph and Daniel on #sugar regarding our relationship with Deployments. Their feeling is that we didn't do enough to get them involved, mine is that our efforts to reach out have been largely unsuccessful for reasons I do not fully understand. Here's another reason for you to consider: I have come to believe that many people involved in deployments have *learned* that they're not going to get anything useful out of interacting with SL because: 1. SL has largely ignored the feedback supplied by these deployments in 2007-2008 and exhaustively documented by Greg Smith and S Page at http://wiki.laptop.org/go/Feature_roadmap#Roadmap 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! OK, I took up my own challenge here... So, please do treat comments below as from the peanut-gallery, and not as authoritative responses to these ~82 feature requests – many of them significant compound feature sets in of themselves. I'd say close to 50% have been resolved, 10% are specifically XO hardware related, 10% XS server, 15% I don't know enough to confirm or deny, 5-10% are duplicates: FWIW: There's a cold beer waiting at the end of this email. -- Feature roadmap/Spell checker in Write: http://wiki.laptop.org/go/Feature_roadmap/Spell_checker_in_Write English checking is back in and working, though unsure about other languages, likely just down to availability of a dictionary file for a given language. -- Feature roadmap/Sugarized color picker: http://wiki.laptop.org/go/Feature_roadmap/Sugarized_color_picker Done and in working for Write, Paint Activity (and others that use colour) haven’t picked this up yet, just a matter of free time (I almost did Paint but keep getting distracted). -- Feature roadmap/Easy Sugarization: http://wiki.laptop.org/go/Feature_roadmap/Easy_%22Sugarization%22 How long is this piece of wet string ;-) But there has been lot’s of effort here. Off the top of my head I’d point to the switch to Metacity in 0.86, Tomeu’s GTK+ widget for making Gnash content into full Activities, Tomeu’s hellow-world PyQt based Activity example. Benjamin’s GSOC Groupthink workhttp://bemasc.net/~bens/groupthink/groupthink-module.html for solving collaboration simply (for the author) in many classes of Activity type. Lucian’s GSOC Webified work http://honeyweb.wordpress.com/ for creating custom site specific browser Activities. Universal bundle work from Aleksey came close but pused to 0.88 for time/ stability reasons. -- Feature roadmap/Activity updater improvements: http://wiki.laptop.org/go/Feature_roadmap/Activity_updater_improvements This was part of OLPC distro onlu for a long time, but is now recently over as a part of Sugar. Majority of work I’m aware of is to get it working smoothly with the activities.sugarlabs.org mozilla addons based site (a big improvement from all the manual wiki hacking). -- Feature roadmap/Concept maps:
Re: [IAEP] SoaS as a Sugar Labs project.
Wow! Thanks Gary. I'm adding my two cents in two spots! -- Feature roadmap/Single sign-on from Browse: http://wiki.laptop.org/go/Feature_roadmap/Single_sign-on_from_Browse Pass. I’ve seen work happening, but having never tested or tried this side of school server work so don’t know where we stand today. Yes, this is working. If you register with a school server you are automatically signed in when you browse to the Moodle on that server. -- Feature roadmap/Backup to Internet: http://wiki.laptop.org/go/Feature_roadmap/Backup_to_Internet Pass. Sorry don’t know enough to comment on status, though it does seem to be actively worked on (SoaS backup to a school server seems particularly active topic). When you are in the school server (Moodle) there is a tab to see your backed up files. This is working on the latest stick Solution Grove is building and the code has been submitted for review. I am pretty sure it already worked on XOs. --Gary P.S. Wow, you made it down the page! I fibbed about the cold beer, sorry, I needed it myself about two and a half pages back. You earned one for the next time your in Boston or we get to a camp together. Thanks :) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ 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, 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
