User:Alsroot/Sugar Architecture

NOTICE:  This page is a draft in active flux... Please contribute to these contents and discuss issues on the discussion page.

Premises

Please read premises from the first to the last, they are based on each other in that direction.

Common

1. Sugar is a community [and not a product] around ideas
   (but might be a product, see below)
   Community which is united around ideas of cognitive and social constructivism in [self]education. The highest result point of this process is a Воспитание (do not mess this word with English words like "parenting", "education", "training", "breading" etc).
2. Process does matter
   Once Воспитание is a primal target, process[of doing something] is a major instrument to achieve this target. In other words, process of developing Sugar should not look like creating a product (by developers) to let other people (users) use it. Instead, Sugar consists of doers, all doers teach each over (and themselves) all time while creating something sustainable, starting from a hacker who codes sugar core and ending by a kid who creates his first Turtle Art project.
3. Cement the floor, remove the ceiling
   Once Воспитание is a primal target and the process is a major instrument within great variety of doers, organisation is critically important. As education can't happen using only one particular instrument, such, Sugar should not impose using particular vertical structures (i.e., software applications). Instead, Sugar should provide a set of basic, low-level, horizontal instruments and a set of rules how doers should behave to create[and teach themselves] something. As addition, Sugar provides a set of ready-to-use, vertical structures but with detailed instruction how to disassemble them and how to create new creatures using the same components.

Technical

1. Sugar architecture starts from the core
   This means that every feature, being added to one of core component, will affect entirely Sugar ecosystem (when this core release will be accessible for most users). Thus, decision about adoption one conceptions (and not adoption another ones) is critically important.
2. Experiments with the core
   Once core is a central part of Sugar architecture, this fact should not suppress any experiments (including useless) with the core. Here, we are skipping the huge field for possible experiments - activities, but, keeping in mind the first premise, core is the most attractive part of Sugar for doers' experiments.
3. Easy to get, easy to change, easy to share
   Once core is a central part of Sugar architecture and Sugar should stimulate doers to make experiments with the core, it is critically important to make this process as convenient as possible. Saying that current situation does not prevent any experiments with the core is a hypocrisy. It is easy to get core sources, it is less easy to change them (If we are talking about collaboration between participants on, e.g., sugar mailing lists. For other people, there is only one sugar core and any experiments will finally affect it, if "do not stop" these efforts), it is mostly impossible to share results of experiments (asking to fetch new sources and build them is not useful in most cases).

Organizational

1. Sugar needs the be a product as well
   The first method to distribute Sugar are various GNU/Linux based distributions and Sugar deployments. For them, Sugar has to be a product because only in that case they can schedule releases and deployments.
2. Change the minds
   Once Sugar might be a product, it is critically important to understand the unoriginality of this fact. Deploying the Sugar gives only the first push (technical possibility to run Sugar). The major behaviour happens within the community; in class, school, region, around the world. In other words, in situation when the code is mutating and spreading fast on irregular basis.
3. Organized chaos
   Keeping in mind all premises, any trying to create a concrete organizational structure for Sugar itself (but not for its particular components when concrete organization makes sense, e.g., for deployments) is defected by design. On high level, ecosystem might be a set of self-organized components that need only rules to interact with each other. Particular Sugar ecosystem components (software project, teams, deployments, etc.) might use various management systems, starting from anarchy and ending by despotism.

Implementation

Start key points:

• Before arguing with implementation details, check if you are agree with premises.
• For the first time, nothing will be changed for, e.g., Sugar deployments (if it will be changed at all).
• Implementation might take several core releases, it is exactly the path of step-by-step Sugar evolution.
• It is just details of implementation and might lack of important details and be changed in process.
• Please, improve it.

Core Team

Core Team is a team of architects of Sugar ecosystem.

The team should contain at least one person for each followed category. The list is sorted from the most important categories to the least, since it is fine to have unskilled developers, maybe fine to have unskilled designers, but it is critically important to have skilled educators.

• Experienced educators. To throw in ideas and methodology.
• Designers and Human Interface specialists. To think how implementation might look and behave.
• Developers, to limit educators and designers in their dreams.

Core Team generates ideas and is not restricted by any releases and distribution schedules (it is Platform Team task). It identifies the major trends for Sugar. The area of responsibility of the Core Team is not only a limited set of Sugar components but any project of Sugar universe. The team takes part in discussing/improving Features, the consolidated opinion of the team is critically important for tracked projects. Particular project might agree or disagree (and follow another way or try to dissuade Core Team by their particular implementations), but the Core Team is exactly what Sugar face is for non-sugar community.

Platform Team

The mission of the Platform Team is creating infrastructure for Sugar ecosystem:

• Providing as-unified-as-possible runtime and development time environments for all Sugar doers, regardless of what platform they are using. In other words, Platform Team makes everything to let ideas, generated by Core Team (as well as any other ideas), happen within the Sugar community.
• Work closely with GNU/Linux distributions, that provide sugar packages, and Sugar deployments to fulfill their needs and coordinate related efforts within Sugar community.
• Release a product - Sugar Platform distribution.

Tracked projects

Tracked projects are analogs of Sucrose components. The key difference is that Sucrose project itself is not a core project any more, it is an independent project (like other ones) and Platform Team is just tracking its life cycle to consider possibility of including its particular release to the distribution. It looks how GNU/Linux distributions package upstream projects.

Platform Team may consider possibility to support particular branches of tracked projects to fulfil deployments' needs.

Sugar distribution

The major purpose of Sugar distribution is providing a set of releases of tracked projects that are being well tested in particular environment (a set of versioned dependencies). That should help Sugar distributors to deploy Sugar. In ideal situation, they need test Sugar distribution only on their hardware.

There are two types of Sugar distributions:

• Regular, per 6 months, releases that are synced with regular releases of major GNU/Linux distributions.
• Long Term Support (LTS) releases that are synced with LTS releases of major GNU/Linux distributions (if possible).

Having LTS releases should simplify sugar deployments since, in most cases, 6 months is too short major releases cycle.

Doer's environment

Sugar distribution is a startup kit for Sugar doers. The real doing starts where new code is involved, e.g., by getting new versions of activities or preparing and sharing new code. Thus, where read-only nature of Sugar distribution is insufficient.

The key features that any Sugar doer needs, are:

• possibility to run any (including not yet released) versions of Sugar components,
• useful instruments to edit the code,
• share the code in peer-to-peer manner to fast and easy sharing of experiment results with the friends (F1/F2 views),
• share the code on more regular basis, i.e., uploading changed code to the server.

These features are critically important and should as simple as possible. It is exactly the purpose behind Zero Sugar initiative (except coding tools, i.e., code editors and IDEs):

• Overview
• Bazaar

No Development Team

The word development is quite confusing. Is it about any development within sugar community, how about Activity Team, etc. Sucrose projects will flow to the rest of Sugar universe and will be, by default, tracked projects of Platform Team.

Sugar universe

Thats the matter of Sugar, i.e., what makes Sugar useful. The variety of Sugar software projects, Glucose projects, libraries and activities.

Most of them are being developed and supported by individuals (mostly activities), the rest are using management model which is most useful for them. All of them are self organized structures and have their own release schedules and roadmaps, though tracked project work in close interaction with the Platform Team.

Questions

To designers

• Should Core Team be a home team for designers instead of Design Team?

To distributors

• Should Platform Team be a home team for distributors instead of Deployment Team?
• Should incremental Sugar distribution releases of the same LTS release contain new users visible features?

The whole picture

As the last premise says, the major idea is not creating concrete vertical organizational structures for Sugar ecosystem but giving fruitful ideas and useful instruments to Sugar doers to let them gain an experience and knowledge during the process of implementation, and spreading the results within Sugar community.

Best Collaboration Practices

Initially, this text was based on MeeGo community's practice. Please, share your experience.

In the following, Sugar Labs Teams, groups of people who are working together on a Sugar project or particular Features, are shorted to team.

While most of this is obvious to people who have been working 'in the open' before, this is a list of Do and Don'ts to help teams to work in the open and for a standard for teams to be held against. Some teams may be exempted from these best practices, an example could be security teams, etc.

The primary idea is that everything (common sense limiting) should be publically available so that everyone can be an equal participant in the process, limited only by their personal skills, time and resources.

Communication

Do's:

Have your team communication be:

• on a dedicated meego.com mailing list (archived, listed), and/or on forums.meego.com
• or on a IRC channel or Jabber MUC chat room (logged, listed, publically accessible and except for good reason, non-moderated)
• This encourages participation by outsiders and transparency in the team work.
• In English except if your team purpose is specific to a certain language/location.

Have your team meetings be at, in order of preference, best to worst:

• Nowhere! Don't have one! It is very difficult to get people across many timezones together, so take this into consideration when making a meeting agenda
• IRC meetings in #sugar-meeting on irc.freenode.net, logged and managed by the IRC meeting bot, and announced with agenda publicly at least 48 hours in advance.
• A physical location with public minutes, ideally recorded and publically downloadable, preferably during a conference with a large number of Sugar community members in attendance, or in a co-ordinated hackfest or summit.

Don'ts:

Have your team communication be:

• on private mailing lists - this discourages participation by non-team members
• without minutes or public record - it makes decisions of the past difficult to locate and understand for others

Membership

Do's:

• Have your team pick up new members based on merit - it encourages good work and motivates non-team members to contribute and prove their skill.
• Ensure that your team is structured in a way to allow evaluation of merit - make public patch review standard practice, have your team do review publicly on a mailing list, and encourage discussion and feedback.

Don'ts:

• Have your new members be chosen alone on affiliation with a company - it ties your team to a certain company and discourages participation by non-team members.
• Allow newcomers to be given commit access to the core repository the day they join
• - instead, have newcomers walk the same gauntlet of creating bugs in Trac, submitting patches and undergoing code review which everyone else goes through. Consider it an effective trial period with public review, and an opportunity to grow a mentoring program.

Contributions

Do's:

• Treat non-team member contributions with same processes, reviews and respect as team member contributions.

Don'ts:

• Ignore non-team member contributions - this discourages participations by non-members and effectively reduces their ability to prove their skill.