[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 <dfarning at sugarlabs.org>wrote:

> On Mon, Aug 24, 2009 at 3:22 PM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
> > On Mon, Aug 24, 2009 at 20:58, Martin Langhoff<martin.langhoff at gmail.com>
> wrote:
> >> On Sun, Aug 23, 2009 at 11:22 PM, David Farning<dfarning at sugarlabs.org>
> 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 at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 

Samuel Goldwyn<http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html>
- "I'm willing to admit that I may not always be right, but I am never
wrong."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20090825/ccb8404c/attachment.htm