5,705
edits
Changes
Jump to navigation
Jump to search
Line 46:
Line 46: − + + − + − + − 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 [[#Sugar_Universe|ones]]) and Platform Team is just tracking its life cycle to consider possibility of including its particular release to the [[#Sugar_distribution|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 ==== − − Line 79:
Line 64: − 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):+ − − * [[Activity_Team/Zero_Sugar|Overview]] − * [[Platform_Team/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 [[#Sugar_universe|universe]] and will be, by default, [[#Tracked_projects|tracked projects]] of [[#Platform_Team|Platform Team]]. − − − 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_projects|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 incremental Sugar distribution releases of the same LTS release contain new users visible features? − + − − == Best Collaboration Practices == − − Initially, this text was based on [http://wiki.meego.com/Proposal_for_Best_Practices_for_working_in_a_MeeGo_team MeeGo community's practice]. Please, share your experience. − − In the following, Sugar Labs Teams, groups of people who are working together on a Sugar [[#Sugar_universe|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:''+ − + + +
User:Alsroot/Sugar Architecture (view source)
Revision as of 15:05, 11 August 2011
, 15:05, 11 August 2011→Platform Team: more focusing on suporting community
=== Platform Team ===
=== Platform Team ===
The mission of the Platform Team is creating infrastructure for Sugar ecosystem:
The mission of the Platform Team is functionally support Sugar ecosystem from technical side:
* Develop new or tune existed services that might be useful for Sugar ecosystem. It is not about taking job from Infrastructure Team that does technical support for Sugar Labs servers but about taking care what functionality needs to be run on these servers.
* 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 [[#Sugar_Universe|community]].
* 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 [[#Sugar_Universe|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.
* 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.
* Take care of technical standards (API, DBus interface, etc) to let all Sugar components/activities interact smooth.
==== Tracked projects ====
==== Doers environment ====
Stable 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 Stable Sugar Distribution is insufficient.
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:
The key features that any Sugar doer needs, are:
* share the code on more regular basis, i.e., uploading changed code to the server.
* share the code on more regular basis, i.e., uploading changed code to the server.
=== Sugar Universe ===
=== Sugar universe ===
Thats the matter of Sugar, i.e., what makes Sugar useful. The variety of Sugar software projects, Glucose projects, libraries and activities.
Thats the matter of Sugar, i.e., what makes Sugar useful. The variety of Sugar software projects, Glucose projects, libraries and activities.
Sugar projects work closely with the Core Team (that generates ideas) and with the Platform Team (that provides the technical floor).
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 [[#Sugar Distribution|Sugar Distribution]] projects release new versions in close interaction with the Platform Team.
=== Progress ===
* Should Platform Team be a home team for distributors instead of Deployment Team?
* [[Platform_Team/Roadmap|Initial release of Doers Environment]]
== The whole picture ==
== The whole picture ==
As the last [[#Organizational|premise]] says, the major idea is not creating concrete vertical organizational structures for Sugar ecosystem but giving [[#Core_Team|fruitful ideas]] and [[#Doer's_environment|useful instruments]] to Sugar [[#Sugar_universe|doers]] to let them gain an [[#Common|experience and knowledge]] during the process of implementation, and [[#Sugar_distribution|spreading]] the results within Sugar community.
As the last [[#Organizational|premise]] says, the major idea is not creating concrete vertical organizational structures for Sugar ecosystem but giving [[#Core_Team|fruitful ideas]], [[#Doers_environment|useful instruments and rules-how-communicate]] to Sugar [[#Sugar_Universe|doers]] to let them gain an [[#Common|experience and knowledge]] during the process of implementation, and [[#Doers_Environment|spreading]] the results within Sugar community.
When community of Sugar doers is:
* Ignore non-team member contributions - this discourages participations by non-members and effectively reduces their ability to prove their skill.
* Open minded educators, designers and just thinkers who don't asked themselves, ''Am I doing right, designing/thinking-about this, so invasive for Sugar, feature?'' and free in choosing the way they think is important.
* Open minded developers of Sugar [[#Sugar_Universe|projects]], who don't asked themselves, ''Am I doing right, implementing this, so invasive for Sugar, feature?'' and free in choosing the way they think is important.
* Purpose minded [[#Platform_Team|Platform Team]] that releases the [[#Sugar_Distribution|product]].