Re: [IAEP] SoaS as a Sugar Labs project.

[Bernie Innocenti]

El Fri, 28-08-2009 a las 09:50 +0200, Martin Langhoff escribió:
> On Fri, Aug 28, 2009 at 9:32 AM, Bernie Innocenti wrote:
> > +1.  And after dinner we could get a laptop and write down some notes on
> > workable management practices for blessed projects like SoaS.
> 
> Get onto some coding -- it's more fun and productive than policy-ing :-)

You know how I'm all for a loosely managed community with low entry
barriers, informal rules and few policies, don't you?  In another life,
I was a manager, and ran away from it because it wasn't nearly as much
fun as real hacking for me.

Though, Michael proposed that traditional management practices might
increase our productivity.  It seems that David's idea of borrowing the
concept of projects from Apache and Eclipse would be a wonderful
opportunity to test Michael's proposal in practice:

- Mensaje reenviado 
De: David Farning 
Para: Bernie Innocenti 
Cc: Michael Stone , iaep 
Asunto: Re: [IAEP] SoaS as a Sugar Labs project.
Fecha: Sun, 23 Aug 2009 16:22:07 -0500

[...]

Bernie, would you be interested in creating the project policy for
Sugar Labs?  There is a very good page at
http://wiki.eclipse.org/Development_Resources . The 'Leads: Managing A
Project' and guidelines sections are very valuable.

If I were to work on the policy I would:
1. Take the Eclipse and Apache policies and strip them down to the bare minum.
2. Combine the Eclipse and Apache policies and modify them for Sugar Labs.
3. Identify two initial projects and make sure the policies work for
both of them.
4. Present the project policy for feedback on iaep.
5. Post the draft policy to the wiki

Something as significant as a project-policy will likely take several
iterations through 1-5.

[...]


___
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.

[Bernie Innocenti]

El Wed, 26-08-2009 a las 16:47 +0100, Martin Dengler escribió:
> On Wed, Aug 26, 2009 at 11:18:13AM -0400, Michael Stone wrote:
> > Tomeu> > 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?
> 
> I think you should share them.  "Talk" isn't bad unless it distracts
> or detracts from "do".

BTW, we already have a tool setup to organize and vote ideas:

  http://idea.sugarlabs.org

It's an instance of IdeaTorrent maintained by Dogi and shared with OLPC
(http://idea.laptop.org is another URL for the same site).

Perhaps we'd like to start using it?  There are two potential dangers:

 * people proposing and voting these ideas might get the false
   impression that top ideas will be worked on and become frustrated
   if that doesn't happen because nobody volunteers for the "do" part

 * when the list of voters is loosely defined, vocal minorities tend
   to drive the results.  IdeaTorrent is neither a democratic voting
   system, nor a scientific survey tool.

If we could make these two points *very* clear, for example by putting
notices on top of the front page, I think idea.sugarlabs.org might
become a useful tool and we could point people there from the wiki.

Ideas?

-- 
   // 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.

[Martin Langhoff]

On Fri, Aug 28, 2009 at 9:32 AM, Bernie Innocenti wrote:
> +1.  And after dinner we could get a laptop and write down some notes on
> workable management practices for blessed projects like SoaS.

Get onto some coding -- it's more fun and productive than policy-ing :-)



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.

[Bernie Innocenti]

El Wed, 26-08-2009 a las 18:54 +0200, Tomeu Vizoso escribió:
> > 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?
> 
> Maybe, though I don't see any double bind nor I'm having much luck
> understanding what you need to have a more positive position. Maybe
> Bernie and you could have a nice dinner and write together someone
> that both find actionable?

+1.  And after dinner we could get a laptop and write down some notes on
workable management practices for blessed projects like SoaS.

-- 
   // 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.

[Tomeu Vizoso]

On Wed, Aug 26, 2009 at 17:54, Martin Dengler wrote:
> On Wed, Aug 26, 2009 at 10:42:57AM -0500, David Farning wrote:
>> > [Michael and Tomeu talk]
>>
>> An effective way to become a respected member of on open source
>> community is to start with small ideas and implement them.  If the
>> deliverable works, is useful, and meets coding standards it will be
>> accepted. A couple of iterations through this:
>> a: Produce improvements to the product.
>> b. Help the contributor earn the respect of the current community so
>> they will be encourage to participate  and take on larger projects.
>>
>> That tends to open doors.
>>
>> Drive by ventings tend to shut them.
>
> These points are valid but not apt.  I don't think Michael's doing
> anything drive-by.  His (and Tomeu's of course) ventings are quite
> well-informed.
>
> Constructive disagreement is valuable.

Agreed, though unfortunately I'm not getting much value out of this
discussion to this moment :(

I sincerely don't know what I can do to address Michael's concerns, I
don't even think I understand them. Help most welcome because Michael
not only is a capable person but has already contributed quite a bit
to Sugar.

Thanks,

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.

[Tomeu Vizoso]

On Wed, Aug 26, 2009 at 17:18, Michael Stone wrote:
> 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.)

I'm sure everybody here would like to see more done, but I still don't
understand why the conclusion is that we don't care about our users.
Can you extend on this?

>> 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?

An idea is an idea, people who want to see an idea realized need to
take some kind of action. That doesn't necessarily mean to carry it
from start to end, they can find associates with whom to work
together. Search the archive for what I have said before about feature
champions.

> 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?

Maybe, though I don't see any double bind nor I'm having much luck
understanding what you need to have a more positive position. Maybe
Bernie and you could have a nice dinner and write together someone
that both find actionable?

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.

[David Farning]

On Wed, Aug 26, 2009 at 10:56 AM, Bert Freudenberg wrote:
> On 26.08.2009, at 17:42, David Farning wrote:
>
>> On Wed, Aug 26, 2009 at 10:18 AM, Michael Stone wrote:
>>>
>>> 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?
>>
>> An effective way to become a respected member of on open source
>> community is to start with small ideas and implement them.  If the
>> deliverable works, is useful, and meets coding standards it will be
>> accepted. A couple of iterations through this:
>> a: Produce improvements to the product.
>> b. Help the contributor earn the respect of the current community so
>> they will be encourage to participate  and take on larger projects.
>>
>> That tends to open doors.
>>
>> Drive by ventings tend to shut them.
>>
>> david
>
>
> I find dismissing Michael's points as "drive by venting" highly
> inappropriate.
>

During a thread in which someone expressed frustration about their
ability to affect the Sugar Labs community,  I pointed out two end
points, along a spectrum, for interacting with a volunteer
community... and the likely consequences of those interactions.

Nothing more, nothing less.

david
___
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.

[Bert Freudenberg]

On 26.08.2009, at 17:42, David Farning wrote:

> On Wed, Aug 26, 2009 at 10:18 AM, Michael Stone  
> wrote:
>> 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?
>
> An effective way to become a respected member of on open source
> community is to start with small ideas and implement them.  If the
> deliverable works, is useful, and meets coding standards it will be
> accepted. A couple of iterations through this:
> a: Produce improvements to the product.
> b. Help the contributor earn the respect of the current community so
> they will be encourage to participate  and take on larger projects.
>
> That tends to open doors.
>
> Drive by ventings tend to shut them.
>
> david


I find dismissing Michael's points as "drive by venting" highly  
inappropriate.

- Bert -


___
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.

[Martin Dengler]

On Wed, Aug 26, 2009 at 10:42:57AM -0500, David Farning wrote:
> > [Michael and Tomeu talk]
>
> An effective way to become a respected member of on open source
> community is to start with small ideas and implement them.  If the
> deliverable works, is useful, and meets coding standards it will be
> accepted. A couple of iterations through this:
> a: Produce improvements to the product.
> b. Help the contributor earn the respect of the current community so
> they will be encourage to participate  and take on larger projects.
> 
> That tends to open doors.
> 
> Drive by ventings tend to shut them.

These points are valid but not apt.  I don't think Michael's doing
anything drive-by.  His (and Tomeu's of course) ventings are quite
well-informed.

Constructive disagreement is valuable.

> david

Martin


pgplDTLlVUe7l.pgp
Description: PGP signature
___
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.

[Martin Dengler]

On Wed, Aug 26, 2009 at 11:18:13AM -0400, Michael Stone wrote:
> Tomeu> > 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?

I think you should share them.  "Talk" isn't bad unless it distracts
or detracts from "do".

> Michael

Martin



pgp9eJ2upYfuh.pgp
Description: PGP signature
___
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 Vizoso]

On Wed, Aug 26, 2009 at 03:22, Gary C Martin wrote:
> 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:

Thanks for taking the time of going through all that and sharing with us.

Regards,

Tomeu

> 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

Re: [IAEP] SoaS as a Sugar Labs project.

[David Farning]

On Wed, Aug 26, 2009 at 10:18 AM, Michael Stone wrote:
> 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?

An effective way to become a respected member of on open source
community is to start with small ideas and implement them.  If the
deliverable works, is useful, and meets coding standards it will be
accepted. A couple of iterations through this:
a: Produce improvements to the product.
b. Help the contributor earn the respect of the current community so
they will be encourage to participate  and take on larger projects.

That tends to open doors.

Drive by ventings tend to shut them.

david
___
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.

[Michael Stone]

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.

[Tomeu Vizoso]

On Wed, Aug 26, 2009 at 02:41, Michael Stone wrote:
> 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:

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.

Do you have any actionable ideas about how to work better for our users?

Thanks,

Tomeu

>> 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 buil

Re: [IAEP] SoaS as a Sugar Labs project.

[Martin Langhoff]

On Wed, Aug 26, 2009 at 3:47 AM, Michael Stone wrote:
> 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". :)

Those are also the hardest :-/ -- both to implement and to demonstrate
that the new implementation is better.



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.

[Bernie Innocenti]

El Tue, 25-08-2009 a las 20:41 -0400, Michael Stone escribió: 
> 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?

While I also see all these as very important technical goals, we
shouldn't forget that Sugar was improved in many other dimensions over
the past ~10 months:

1) Maturity & Polish: all the features we already had could not
even be used because Sugar 0.82 was so slow, buggy and incomplete that
you couldn't even demo it to a teacher without feeling a bit
embarrassed.

2) Ubiquity & Generality: Sugar 0.82 and its core activities ware
(badly) packaged only for one distro and contained plenty of assumptions
that made the platform unusable on anything but the XO-1.  Now anyone
can use Sugar on any kind of computer.

3) Identity & Branding: one year ago, Sugar did not even have its own
home page; it was not a project being led by its own community.  In
fact, Sugar did not even have a proper community and was completely
dependent on OLPC's infrastructure, resources and management.
We now have a well organized and productive community. Its growth is so
fast that I'm having trouble scaling the infrastructure up fast enough
to meet its needs.

4) Cadence & Rhythm: back in the OLPC days, we kept shifting release
dates, changing versioning schemes, and even adding or canceling random
features close to deadlines.  DeMarco would be turning in his grave if
he was dead.  We've now achieved on-schedule releases of the Glucose and
Fructose modules using a time-based development cycle of 6 months
synchronized with the mayor distros.  Along with feature proposals, this
makes our release engineering process more solid and predictable than
many high-profile commercial projects.

*These* were the most critical things that needed to happen in order to
make Sugar sustainable free software, and it seems to have successfully
achieved all of them in less than one year.  The project is now ready to
foster larger contributions like those you described.  Would you be
interested in taking any one of them on your shoulders, besides Rainbow?

Perhaps you remember John Gilmore betting with me on a pizza that Sugar,
within one year, would no longer be developed.  To his credit, many
others I spoke with one year ago were worried that this project would
fall apart shortly after OLPC would have stopped supporting it
financially.  Instead, today Sugar is quite healthy and flourishing
thanks to the hard work of several great volunteers, old and new.

H, a delicious pizza is coming soon ;-)

-- 
   // 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.

[Michael Stone]

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

Re: [IAEP] SoaS as a Sugar Labs project.

[Caroline Meeks]

>
> 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 C Martin]

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  

Re: [IAEP] SoaS as a Sugar Labs project.

[Michael Stone]

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, a

Re: [IAEP] SoaS as a Sugar Labs project.

[Tomeu Vizoso]

On Tue, Aug 25, 2009 at 17:50, Martin Langhoff wrote:
> On Tue, Aug 25, 2009 at 5:38 PM, Tomeu Vizoso 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

Re: [IAEP] SoaS as a Sugar Labs project.

[Martin Langhoff]

On Tue, Aug 25, 2009 at 5:38 PM, Tomeu Vizoso 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.

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. :-)




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.

[Gary C Martin]

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! 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.

***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.

Regards,
--Gary

> 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.
>
> Regards,
>
> Michael
> ___
> 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.

[Tomeu Vizoso]

On Tue, Aug 25, 2009 at 17: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
>
> 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.

[Michael Stone]

>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.

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.

[Martin Langhoff]

On Tue, Aug 25, 2009 at 4:47 PM, Tomeu Vizoso 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.

[Tomeu Vizoso]

On Tue, Aug 25, 2009 at 16:40, Martin Langhoff 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.

[Tomeu Vizoso]

On Tue, Aug 25, 2009 at 16:13, Bernie Innocenti wrote:
> 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.

I agree with that, though instead of Projects I was thinking of
feature champions to herd the cats that may be involved in getting the
feature completed. This job could be carried by anyone and would
consist on tracking the progress, documenting the need, bugging the
different people involved, etc.

> 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.

I think a maintainer is just a maintainer and we shouldn't overload
the role. No problem with some people having a more leading role if
they have the energy and wish to do so.

> 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.

Hmm, not sure how this would work. Improving the reliability of the
sharing experience could be one of those "projects"?

>> 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.

As Bernie said, a constructive discussion is a positive contribution,
no need to apologize.

> 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.

I agree with 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.

[Martin Langhoff]

On Tue, Aug 25, 2009 at 4:13 PM, Bernie Innocenti 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.

[Bernie Innocenti]

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.

[Greg DeKoenigsberg]

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 "Project"s.

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.

[Tomeu Vizoso]

On Tue, Aug 25, 2009 at 12:45, Martin Langhoff wrote:
> On Tue, Aug 25, 2009 at 2:00 AM, David Farning 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] SoaS as a Sugar Labs project.

[Martin Langhoff]

On Tue, Aug 25, 2009 at 2:00 AM, David Farning 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 :-)

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.

[Martin Dengler]

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 "Project"s.

> --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

Re: [IAEP] SoaS as a Sugar Labs project.

[Bernie Innocenti]

El Mon, 24-08-2009 a las 13:50 -0400, Greg DeKoenigsberg escribió:
> On Sun, 23 Aug 2009, David Farning wrote:
> > Eclipse and Apache both have criteria for becoming a official
> > projects.  In fact, they have a several step incubator processes to
> > help sub-project grow (or die grace fully.)  This strikes me as a
> > little heavy for Sugar Lab right now.
> 
> Fedora aims for a lightweight compromises:
> 
> * 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
> 
> To me, frankly, SoaS looks less like a SIG and more like a Project at this 
> point in its lifecycle.
>>
> > Bernie, would you be interested in creating the project policy for
> > Sugar Labs?  There is a very good page at
> > http://wiki.eclipse.org/Development_Resources . The 'Leads: Managing A
> > Project' and guidelines sections are very valuable.
> >
> > If I were to work on the policy I would:
> > 1. Take the Eclipse and Apache policies and strip them down to the bare 
> > minum.
> > 2. Combine the Eclipse and Apache policies and modify them for Sugar Labs.
> > 3. Identify two initial projects and make sure the policies work for
> > both of them.
> > 4. Present the project policy for feedback on iaep.
> > 5. Post the draft policy to the wiki
> >
> > Something as significant as a project-policy will likely take several
> > iterations through 1-5.
> 
> I would avoid elections for as long as possible.  Vote with your work. 
> The one exception should be the Board itself, which should use its power 
> to appoint very liberally.  My $0.02.

I agree with everything Greg said, except that we should require a much
larger bribe than $0.02 to make the board appoint someone "very
liberally".





































Yes, of course it was a joke ;-)

-- 
   // 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.

[David Van Assche]

Hmmm, maybe I'm missing something, but isn't the idea of creating
subprojects and projects an organisational thing that benefits everyone? I
don't really see it being too beaurocratic unless it starts to become about
tedious definitions. But if we are just saying, SoaS, Karma, and say Physics
are all to become subprojects for organisational reasons... that seems fine,
and might attract the doers as they will know what exactly is being worked
on from a big picture perspective. I can imagine using subdomains for this
stuff like:
karma.sugarlabs.org or soas.sugarlabs.org

These quicklinks could be great entry paths for eager devs or eager users.

my 2 cents...

David Van Assche

On Tue, Aug 25, 2009 at 2:00 AM, David Farning wrote:

> On Mon, Aug 24, 2009 at 3:22 PM, Tomeu Vizoso wrote:
> > On Mon, Aug 24, 2009 at 20:58, Martin Langhoff
> wrote:
> >> On Sun, Aug 23, 2009 at 11:22 PM, David Farning
> wrote:
> >>> Eclipse and Apache both have criteria for becoming a official
> >>
> >> Note that Apache's reason to run this "Apache Projects" is to _extend
> >> the legal protection shield to other projects_. If doesn't care one
> >> zot about what the resulting software _does_. And they only looked
> >> into that once they had their main mission (the webserver) pretty much
> >> cooked.
> >>
> >> I've advised several projects that wanted to "do like apache", and
> >> once they understood what apache does, they did not want to "do like
> >> apache" no more :-)
> >>
> >>
> >> 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.
> >>
> >> Boards, subprojects and such are good things to remember to do when a
> >> project gets big and tensions surface (aside from some specific things
> >> you want "right" from the start -- license, etc).
> >>
> >> This comment is not meant as a trolling attempt (though I fear it'll
> >> end up in tears). The core of what I am trying to say is: doing these
> >> things too early has some risks -- just off the top of my head
> >>
> >>  - The FOSS version of being top-heavy, the distraction
> >>
> >>  - Newcomers reading all these big names (board, procedures, the board
> >> blessing the SIG) and getting the wrong idea about the project -- this
> >> can discourage the go-getters that like get-it-done environments.
> >>
> >>  - Fostering armchair quarterbackers (like yours truly right now :-/ )
> >> and endless bickering (hmm! debian-legal) -- these are attracted to
> >> "big name" and "big infra" projects.
> >>
> >> I really like GregDek's line:
> >>> I would avoid elections for as long as possible.  Vote with your work.
> >>
> >> 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 :-)
> >
> > I think your concerns are reasonable, but as long as we keep being an
> > organization where people who want to do things are enabled to get
> > them done, I don't think we are in such a bad position.
> >
> > If it comes the day when talkers remove power from doers, we'll need
> > to worry about what you warn, but fortunately I don't see that coming
> > any time soon.
>
> FWIW, I do realize that for better or worse I am the biggest
> bureaucrat in the project.  That is why I am not running for the
> oversight board this year.
>
> The control _should_ be in the hands of the doers; the deployers,
> translators, designers, developers  If we continue to do our jobs
> correctly, this time next year the number of teachers, and content
> authors will start to outweigh the designers and developers.
>
> > I see these discussions about what you call bureaucracy as actually
> > fostering the doers, by giving their area of interest a concrete
> > visibility and telling them to chose their tools, procedures and
> > identity so they can better do their thing.
>
> 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.
>
> Why now?  Usually I harp on focus and deliverable.  But, just this
> once:) I urge you to take a break and unfocus.  The current growth
> trajectory for Sugar Labs is pretty humbling.
>
> david
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 

Samuel Goldwyn
- "I'm willing to admit that I may not always be right, but I am never
wrong."

Re: [IAEP] SoaS as a Sugar Labs project.

[David Farning]

On Mon, Aug 24, 2009 at 3:22 PM, Tomeu Vizoso wrote:
> On Mon, Aug 24, 2009 at 20:58, Martin Langhoff 
> wrote:
>> On Sun, Aug 23, 2009 at 11:22 PM, David Farning 
>> wrote:
>>> Eclipse and Apache both have criteria for becoming a official
>>
>> Note that Apache's reason to run this "Apache Projects" is to _extend
>> the legal protection shield to other projects_. If doesn't care one
>> zot about what the resulting software _does_. And they only looked
>> into that once they had their main mission (the webserver) pretty much
>> cooked.
>>
>> I've advised several projects that wanted to "do like apache", and
>> once they understood what apache does, they did not want to "do like
>> apache" no more :-)
>>
>>
>> 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.
>>
>> Boards, subprojects and such are good things to remember to do when a
>> project gets big and tensions surface (aside from some specific things
>> you want "right" from the start -- license, etc).
>>
>> This comment is not meant as a trolling attempt (though I fear it'll
>> end up in tears). The core of what I am trying to say is: doing these
>> things too early has some risks -- just off the top of my head
>>
>>  - The FOSS version of being top-heavy, the distraction
>>
>>  - Newcomers reading all these big names (board, procedures, the board
>> blessing the SIG) and getting the wrong idea about the project -- this
>> can discourage the go-getters that like get-it-done environments.
>>
>>  - Fostering armchair quarterbackers (like yours truly right now :-/ )
>> and endless bickering (hmm! debian-legal) -- these are attracted to
>> "big name" and "big infra" projects.
>>
>> I really like GregDek's line:
>>> I would avoid elections for as long as possible.  Vote with your work.
>>
>> 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 :-)
>
> I think your concerns are reasonable, but as long as we keep being an
> organization where people who want to do things are enabled to get
> them done, I don't think we are in such a bad position.
>
> If it comes the day when talkers remove power from doers, we'll need
> to worry about what you warn, but fortunately I don't see that coming
> any time soon.

FWIW, I do realize that for better or worse I am the biggest
bureaucrat in the project.  That is why I am not running for the
oversight board this year.

The control _should_ be in the hands of the doers; the deployers,
translators, designers, developers  If we continue to do our jobs
correctly, this time next year the number of teachers, and content
authors will start to outweigh the designers and developers.

> I see these discussions about what you call bureaucracy as actually
> fostering the doers, by giving their area of interest a concrete
> visibility and telling them to chose their tools, procedures and
> identity so they can better do their thing.

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.

Why now?  Usually I harp on focus and deliverable.  But, just this
once:) I urge you to take a break and unfocus.  The current growth
trajectory for Sugar Labs is pretty humbling.

david
___
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 Vizoso]

On Mon, Aug 24, 2009 at 20:58, Martin Langhoff wrote:
> On Sun, Aug 23, 2009 at 11:22 PM, David Farning wrote:
>> Eclipse and Apache both have criteria for becoming a official
>
> Note that Apache's reason to run this "Apache Projects" is to _extend
> the legal protection shield to other projects_. If doesn't care one
> zot about what the resulting software _does_. And they only looked
> into that once they had their main mission (the webserver) pretty much
> cooked.
>
> I've advised several projects that wanted to "do like apache", and
> once they understood what apache does, they did not want to "do like
> apache" no more :-)
>
>
> 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.
>
> Boards, subprojects and such are good things to remember to do when a
> project gets big and tensions surface (aside from some specific things
> you want "right" from the start -- license, etc).
>
> This comment is not meant as a trolling attempt (though I fear it'll
> end up in tears). The core of what I am trying to say is: doing these
> things too early has some risks -- just off the top of my head
>
>  - The FOSS version of being top-heavy, the distraction
>
>  - Newcomers reading all these big names (board, procedures, the board
> blessing the SIG) and getting the wrong idea about the project -- this
> can discourage the go-getters that like get-it-done environments.
>
>  - Fostering armchair quarterbackers (like yours truly right now :-/ )
> and endless bickering (hmm! debian-legal) -- these are attracted to
> "big name" and "big infra" projects.
>
> I really like GregDek's line:
>> I would avoid elections for as long as possible.  Vote with your work.
>
> 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 :-)

I think your concerns are reasonable, but as long as we keep being an
organization where people who want to do things are enabled to get
them done, I don't think we are in such a bad position.

If it comes the day when talkers remove power from doers, we'll need
to worry about what you warn, but fortunately I don't see that coming
any time soon.

I see these discussions about what you call bureaucracy as actually
fostering the doers, by giving their area of interest a concrete
visibility and telling them to chose their tools, procedures and
identity so they can better do their thing.

Regards,

Tomeu

>
>
> 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
>



-- 
«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.

[Caroline Meeks]

I agree that there is a tension between trying to set everything up the way
it should be when its fully grown and setting up the expectation that there
is more reality there then there is.
I worry a lot about over promising and setting too high of expectations for
Sugar on a Stick currently.

I worry about making it too complicated for people who want to get involved.

I wonder what the harm would be in waiting 6 months to do this.

But I also worry about getting distracted from the huge amount of work
I need to do to get ready for school by bureaucracy.  So
basically I'm not going to fight you on this. If those of you who have time
to think about it really want to do this I'm not going to put any energy
into fighting it and I'll deal with whatever happens.

On Mon, Aug 24, 2009 at 2:58 PM, Martin Langhoff
wrote:

> On Sun, Aug 23, 2009 at 11:22 PM, David Farning
> wrote:
> > Eclipse and Apache both have criteria for becoming a official
>
> Note that Apache's reason to run this "Apache Projects" is to _extend
> the legal protection shield to other projects_. If doesn't care one
> zot about what the resulting software _does_. And they only looked
> into that once they had their main mission (the webserver) pretty much
> cooked.
>
> I've advised several projects that wanted to "do like apache", and
> once they understood what apache does, they did not want to "do like
> apache" no more :-)
>
>
> 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.
>
> Boards, subprojects and such are good things to remember to do when a
> project gets big and tensions surface (aside from some specific things
> you want "right" from the start -- license, etc).
>
> This comment is not meant as a trolling attempt (though I fear it'll
> end up in tears). The core of what I am trying to say is: doing these
> things too early has some risks -- just off the top of my head
>
>  - The FOSS version of being top-heavy, the distraction
>
>  - Newcomers reading all these big names (board, procedures, the board
> blessing the SIG) and getting the wrong idea about the project -- this
> can discourage the go-getters that like get-it-done environments.
>
>  - Fostering armchair quarterbackers (like yours truly right now :-/ )
> and endless bickering (hmm! debian-legal) -- these are attracted to
> "big name" and "big infra" projects.
>
> I really like GregDek's line:
> > I would avoid elections for as long as possible.  Vote with your work.
>
> 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 :-)
>
>
>
> 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
>



-- 
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.

[Martin Langhoff]

On Sun, Aug 23, 2009 at 11:22 PM, David Farning wrote:
> Eclipse and Apache both have criteria for becoming a official

Note that Apache's reason to run this "Apache Projects" is to _extend
the legal protection shield to other projects_. If doesn't care one
zot about what the resulting software _does_. And they only looked
into that once they had their main mission (the webserver) pretty much
cooked.

I've advised several projects that wanted to "do like apache", and
once they understood what apache does, they did not want to "do like
apache" no more :-)


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.

Boards, subprojects and such are good things to remember to do when a
project gets big and tensions surface (aside from some specific things
you want "right" from the start -- license, etc).

This comment is not meant as a trolling attempt (though I fear it'll
end up in tears). The core of what I am trying to say is: doing these
things too early has some risks -- just off the top of my head

 - The FOSS version of being top-heavy, the distraction

 - Newcomers reading all these big names (board, procedures, the board
blessing the SIG) and getting the wrong idea about the project -- this
can discourage the go-getters that like get-it-done environments.

 - Fostering armchair quarterbackers (like yours truly right now :-/ )
and endless bickering (hmm! debian-legal) -- these are attracted to
"big name" and "big infra" projects.

I really like GregDek's line:
> I would avoid elections for as long as possible.  Vote with your work.

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 :-)



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.

[Greg DeKoenigsberg]

On Sun, 23 Aug 2009, David Farning wrote:


As such, I would like to propose that Sugar Labs create a separate
category of initiatives, such as SoaS, called projects.  The idea is
based on apachs' and eclipses' effective use of projects.

The premise behind 'projects' is that initiatives such as SoaS are
vital to the overall success of the ecosystem.  Yet, they are in
several ways autonomous to the Learning Platform.


Sounds like a very good idea, +1.

Should we also identify a Project Leader for each project like we heave 
done for teams?  I'm more concerned with the possibility of a project 
stalling without any clear leader than the case where leadership is 
being disputed among multiple individuals.


Eclipse and Apache both have criteria for becoming a official
projects.  In fact, they have a several step incubator processes to
help sub-project grow (or die grace fully.)  This strikes me as a
little heavy for Sugar Lab right now.


Fedora aims for a lightweight compromises:

* 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

To me, frankly, SoaS looks less like a SIG and more like a Project at this 
point in its lifecycle.


Until we observe the latter situation in practice, we could probably 
live without an election process.  Our time would be better spent 
writing a policy that would encourage Project Leaders to report their 
progress regularly (perhaps weekly) and step down responsibly when they 
no longer have the time and motivation to lead properly.


Bernie, would you be interested in creating the project policy for
Sugar Labs?  There is a very good page at
http://wiki.eclipse.org/Development_Resources . The 'Leads: Managing A
Project' and guidelines sections are very valuable.

If I were to work on the policy I would:
1. Take the Eclipse and Apache policies and strip them down to the bare minum.
2. Combine the Eclipse and Apache policies and modify them for Sugar Labs.
3. Identify two initial projects and make sure the policies work for
both of them.
4. Present the project policy for feedback on iaep.
5. Post the draft policy to the wiki

Something as significant as a project-policy will likely take several
iterations through 1-5.


I would avoid elections for as long as possible.  Vote with your work. 
The one exception should be the Board itself, which should use its power 
to appoint very liberally.  My $0.02.


--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.

[David Farning]

On Sun, Aug 23, 2009 at 3:58 PM, Bernie Innocenti wrote:
> El Sat, 22-08-2009 a las 12:45 -0500, David Farning escribió:
>> There has been some confusion over the past several months about how
>> SoaS fits into Sugar Labs.
>>
>> I have been getting the feeling that we are setting ourself up for
>> confusion by not clearly abstracting SoaS from the Learning Platform.
>> On the other hand, initiatives such as sugar on a stick are incredibly
>> valuable to the over all mission of Sugar Labs.
>>
>> As such, I would like to propose that Sugar Labs create a separate
>> category of initiatives, such as SoaS, called projects.  The idea is
>> based on apachs' and eclipses' effective use of projects.
>>
>> The premise behind 'projects' is that initiatives such as SoaS are
>> vital to the overall success of the ecosystem.  Yet, they are in
>> several ways autonomous to the Learning Platform.
>
> Sounds like a very good idea, +1.
>
> Should we also identify a Project Leader for each project like we heave
> done for teams?  I'm more concerned with the possibility of a project
> stalling without any clear leader than the case where leadership is
> being disputed among multiple individuals.

Eclipse and Apache both have criteria for becoming a official
projects.  In fact, they have a several step incubator processes to
help sub-project grow (or die grace fully.)  This strikes me as a
little heavy for Sugar Lab right now.

> Until we observe the latter situation in practice, we could probably
> live without an election process.  Our time would be better spent
> writing a policy that would encourage Project Leaders to report their
> progress regularly (perhaps weekly) and step down responsibly when they
> no longer have the time and motivation to lead properly.

Bernie, would you be interested in creating the project policy for
Sugar Labs?  There is a very good page at
http://wiki.eclipse.org/Development_Resources . The 'Leads: Managing A
Project' and guidelines sections are very valuable.

If I were to work on the policy I would:
1. Take the Eclipse and Apache policies and strip them down to the bare minum.
2. Combine the Eclipse and Apache policies and modify them for Sugar Labs.
3. Identify two initial projects and make sure the policies work for
both of them.
4. Present the project policy for feedback on iaep.
5. Post the draft policy to the wiki

Something as significant as a project-policy will likely take several
iterations through 1-5.

david

> The Fedora package maintainers are organized similarly; the relevant
> documentation in the Fedora wiki could be one source of inspiration for
> us to imitate, although project management in Apache and Eclipse seems
> like a better fit for what we're trying to achieve here.
>
> --
>   // 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.

[Bernie Innocenti]

El Sat, 22-08-2009 a las 12:45 -0500, David Farning escribió:
> There has been some confusion over the past several months about how
> SoaS fits into Sugar Labs.
> 
> I have been getting the feeling that we are setting ourself up for
> confusion by not clearly abstracting SoaS from the Learning Platform.
> On the other hand, initiatives such as sugar on a stick are incredibly
> valuable to the over all mission of Sugar Labs.
> 
> As such, I would like to propose that Sugar Labs create a separate
> category of initiatives, such as SoaS, called projects.  The idea is
> based on apachs' and eclipses' effective use of projects.
> 
> The premise behind 'projects' is that initiatives such as SoaS are
> vital to the overall success of the ecosystem.  Yet, they are in
> several ways autonomous to the Learning Platform.

Sounds like a very good idea, +1.

Should we also identify a Project Leader for each project like we heave
done for teams?  I'm more concerned with the possibility of a project
stalling without any clear leader than the case where leadership is
being disputed among multiple individuals.

Until we observe the latter situation in practice, we could probably
live without an election process.  Our time would be better spent
writing a policy that would encourage Project Leaders to report their
progress regularly (perhaps weekly) and step down responsibly when they
no longer have the time and motivation to lead properly.

The Fedora package maintainers are organized similarly; the relevant
documentation in the Fedora wiki could be one source of inspiration for
us to imitate, although project management in Apache and Eclipse seems
like a better fit for what we're trying to achieve here.

-- 
   // 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.

[David Farning]

I created a project level on the wiki toolbar listing SoaS.

david

On Sun, Aug 23, 2009 at 2:51 AM, Tomeu Vizoso wrote:
> On Sat, Aug 22, 2009 at 19:45, David Farning wrote:
>> There has been some confusion over the past several months about how
>> SoaS fits into Sugar Labs.
>>
>> I have been getting the feeling that we are setting ourself up for
>> confusion by not clearly abstracting SoaS from the Learning Platform.
>> On the other hand, initiatives such as sugar on a stick are incredibly
>> valuable to the over all mission of Sugar Labs.
>>
>> As such, I would like to propose that Sugar Labs create a separate
>> category of initiatives, such as SoaS, called projects.  The idea is
>> based on apachs' and eclipses' effective use of projects.
>>
>> The premise behind 'projects' is that initiatives such as SoaS are
>> vital to the overall success of the ecosystem.  Yet, they are in
>> several ways autonomous to the Learning Platform.
>
> Makes a lot of sense to me, which other such projects we would have
> for now? Physics, Karma, ...?
>
> Regards,
>
> Tomeu
>
>> david
>> ___
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>
>
>
> --
> «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.

[Tomeu Vizoso]

On Sat, Aug 22, 2009 at 19:45, David Farning wrote:
> There has been some confusion over the past several months about how
> SoaS fits into Sugar Labs.
>
> I have been getting the feeling that we are setting ourself up for
> confusion by not clearly abstracting SoaS from the Learning Platform.
> On the other hand, initiatives such as sugar on a stick are incredibly
> valuable to the over all mission of Sugar Labs.
>
> As such, I would like to propose that Sugar Labs create a separate
> category of initiatives, such as SoaS, called projects.  The idea is
> based on apachs' and eclipses' effective use of projects.
>
> The premise behind 'projects' is that initiatives such as SoaS are
> vital to the overall success of the ecosystem.  Yet, they are in
> several ways autonomous to the Learning Platform.

Makes a lot of sense to me, which other such projects we would have
for now? Physics, Karma, ...?

Regards,

Tomeu

> david
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
«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.

[Frederick Grose]

See the page, http://wiki.sugarlabs.org/go/Wiki_Team/Guide/Wiki_Structure,
for how Projects, Teams, and Local Labs may distinguish themselves on the
Sugar Labs wiki.

 --Fred

On Sat, Aug 22, 2009 at 1:45 PM, David Farning wrote:

> There has been some confusion over the past several months about how
> SoaS fits into Sugar Labs.
>
> I have been getting the feeling that we are setting ourself up for
> confusion by not clearly abstracting SoaS from the Learning Platform.
> On the other hand, initiatives such as sugar on a stick are incredibly
> valuable to the over all mission of Sugar Labs.
>
> As such, I would like to propose that Sugar Labs create a separate
> category of initiatives, such as SoaS, called projects.  The idea is
> based on apachs' and eclipses' effective use of projects.
>
> The premise behind 'projects' is that initiatives such as SoaS are
> vital to the overall success of the ecosystem.  Yet, they are in
> several ways autonomous to the Learning Platform.
>
> david
> ___
> 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

[IAEP] SoaS as a Sugar Labs project.

[David Farning]

There has been some confusion over the past several months about how
SoaS fits into Sugar Labs.

I have been getting the feeling that we are setting ourself up for
confusion by not clearly abstracting SoaS from the Learning Platform.
On the other hand, initiatives such as sugar on a stick are incredibly
valuable to the over all mission of Sugar Labs.

As such, I would like to propose that Sugar Labs create a separate
category of initiatives, such as SoaS, called projects.  The idea is
based on apachs' and eclipses' effective use of projects.

The premise behind 'projects' is that initiatives such as SoaS are
vital to the overall success of the ecosystem.  Yet, they are in
several ways autonomous to the Learning Platform.

david
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep