[Sugar-devel] Appearance Customization

[Aleksey Lim]

On Tue, Nov 02, 2010 at 04:33:35PM +0000, Martin Dengler wrote:
> On Tue, Nov 02, 2010 at 12:40:13PM +0000, Aleksey Lim wrote:
> > On Tue, Nov 02, 2010 at 04:17:12PM +0800, C. Scott Ananian wrote:
> > >  I wonder how it will turn out this time, maybe we've finally moved
> > > past some of the old bugbears.
> > 
> > This is exactly the core[one of not many, at least] problem of current
> > situation around sugar core development. After forming SL, nothing
> > principally was changed, the same vertical organizational system
> > was just moved (dunno how it was in OLPC, created otherwise) to another
> > conditions.
> 
> I'm not sure I understand the problem you see: is it that when you say
> "vertical organization" you are saying that SL can't change because
> the people with access to the code won't commit the necessary changes?
> Or that they don't (for whatever reason) make the changes people want?
> Or something else...?

Maybe self-invented "vertical structure" is not right term, I just mean
that OLPC (in my mind) creates a product, "Sugar" (which is right because
otherwise OLPC will fail from beginning w/ having sugar w/o any schedules
and releases). And moving that paradigm as-is to SL, is wrong idea
(see below).

> > In my mind core issue is that no one are willing to take
> > responsibility because people who might take this responsibility are
> > the same developers and that there is always a chance to get "Are
> > you have the full picture of needs to make such invasive decision?".
> 
> Can you clarify this problem?  I don't think I understand what you see
> as the problem (I'm not saying they're aren't any).  Are you saying
> that there are too few developers and none (of those developers) want
> to propose changes because they get shot down by non-developers?

My idea is that mixing [core] developers (that is Development Team),
sugar nature of (as I understand it) teaching in [development] process
and releasing a product (sucrose) within the same organizational unit
as Development Team is wrong thing because it prevents any experiments.

Any experimenter(more precisely, reviewer) needs to take responsibility
of all levels, committing to particular project and take care about
consequence from deployments<->users-in-the field. It is not about that
developers should not care about users but about personal responsibility
when we talking about community that statements [self]teaching in process.

In my mind it is exactly how development/releasing related job happened
within Development Team.

What is wrong w/ that model, I hope to explain more in what I think
is right:

* clear separation of purposes on Teams level (but not of particular person
  level, i.e., the same person might contribute to several Teams)
  1) Core Team of thinkers, Sugar trends
  2) Standard Team (or so), declaring rules, API, DBus interface
  3) Platform Team, providing infrastructure to let doers work
  all this is not about coding itself but about coordination/supporting it.
  ie it is not about development itself but just do everything to support doers

* doers,
  the variety of Sugar projects (from sugar-base to flash activities)
  that collaborate using Standard Team's rules.
  there is obvious separation between "core" projects and activities but
  I don't see why we don't need to have several, e.g., Journal
  implementations (if we have well declared/designed dbus API).
  doers are not restricted by any schedules, except that they think is
  important for them. Also except projects that are tracked by Platform
  Team but this is a talking between the same level structures.
  ie this a zone of experiments (in wide sense)

* Platform Team creates the product, including some of projects from
  above category. This is the place where experiments are [have to]
  boiled to something sustainable that might be used for sugar
  deployments.
  ie it is not about development itself but about distribution

-- 
Aleksey