Ubuntu Wiki

    \\\ This is a draft and is not yet released. ///
    ***      Please be polite and don't edit     ***
    __ Send feedback to cody-somerville@ubuntu.com __

This is the Xubuntu Strategy Document which was developed primarily by Cody Somerville (project leader at time of writing) in Spring 2008. The rationale and motivation behind the development of this document was to enable Xubuntu to become a sustainable and healthy project. This document will describe the long term strategy, vision, and direction of the Xubuntu project which Xubuntu developers and contributors will utilize as a guide and reference.

This document lays an important piece of foundation in the Xubuntu project. By keeping our strategy and vision documented we help ensure that our objectives are aligned and movement occurs in a forward direction that is healthy for the project.

Special thanks to Jono Bacon, Eero Tamminen, and Nico Veenkamp for their contributions to this document.

Mission Statement

Xubuntu will provide (The goal of Xubuntu is to produce) an easy to use distribution, based on Ubuntu, using Xfce as the graphical desktop, with a focus on integration, usability and performance, with a particular focus on low memory footprint. The integration in Xubuntu is at a configuration level, a toolkit level, and matching the underlying technology beneath the desktop in Ubuntu. Xubuntu will be built and developed as part of the wider Ubuntu community, based around the ideals and values of Ubuntu.

The Target

For a project to have a useful vision and strategy, it must have a target audience or group. The target audience (or group) for Xubuntu are users who are interested in having a modestly light weight, slim, fast desktop experience which retaining usability and functionality that is required to to provide an easy to use desktop environment.

Xubuntu does not target users of specific skill or aptitude. What this means is that we want Xubuntu to be a viable option for users who are new to Linux or the Ubuntu platform but also be appealing to more experienced users. This also means that Xubuntu does not specifically focus on new users or users migrating from Windows; alternative distributions such as Ubuntu may be more appropriate for first time Linux users (especially first time Linux users who may be particularly at risk of experiencing difficulties due to lack of general experience).

Xubuntu does not exclusively target users with slow machines. Xubuntu does not exclusively target users with modest machines. Xubuntu does not exclusively target users with high powered machines. Instead, Xubuntu targets users with lower end machines but also users with faster machines as the extra responsiveness and speed is appealing to users regardless of the performance their machines are capable of.

Xubuntu is not specifically targeted to Xfce4 enthusiasts as projects/software being hosted by the Xfce4 project or associating (officially or unofficially) with Xfce4 are not guaranteed inclusion in Xubuntu over other applications which may be a better fit for Xubuntu. However, Xubuntu is a good choice for users who want an integrated, usable, and fast desktop distribution that uses Xfce4 accompanied with a strong set of GTK applications.

Other groups of users may also be good fits for Xubuntu but they are not targeted specifically at this time.

Xubuntu's Three Tier Focus

We will use a three tier system that defines our foci and provides a transparent, agnostic framework that can be applied to dispute resolution, package selection, policy, and our decision making processes. Our three tier system is the foundation of the Xubuntu vision and provides us with a clear set of priorities that are abstract enough to be simple but also concrete enough to be actionable. As the foundation of the Xubuntu vision, this construct is static in nature and should not be confused with release specific goals and priorities but instead recognized as the principles which the release specific goals are based on.

Focus 1: Integration

It is important for us to provide an integrated desktop as it is a critical component to being a useful desktop, a usable desktop, and an effective desktop. Without integration, the Xubuntu desktop will be rough and unpolished which is unappealing to our end-users. We will provide an integrated desktop by selecting packages that work well with each other and applying patches (aka "glue") to further improve the situation. For example: we will ship GTK applications that conform properly to the system's look and field; we will ship applications that integrate or interact with the Xfce4 desktop environment where the applications are mature, stable, maintainable, and provide a positive net benefit.

See "Package Selection" section for further discussion on how to determine an application's fit in the Xubuntu stack.

Success is measured by considering the progress made during a release cycle towards related specifications and user feedback. In the future, more comprehensive metrics will be developed.

Focus 2: Usability

We want Xubuntu to be usable. By this, not only do we mean we want Xubuntu to be easy to use but also accessible and localized to enable users who face impairments and those wishing to work in their tongue. To accomplish this, we'll strongly consider the usability and accessibility of an application when deciding on package selection, invest in contributing to upstream usability and localization efforts, and pulling on talent from our commnity to provide interface usability analysis.

Xubuntu will liaison with the Ubuntu testing team

Success in providing an accessible desktop can be measured through testing (including automated) and user feedback while localization will be measured by looking at the precentage of the desktop that is translated. To measure how easy to use Xubuntu is, we'll employ test cases and draw on the community talent to provide professional grade analysis.

Focus 3: Performance

Being lightweight, slim, and fast are all words that have been used to describe and market Xubuntu. However, over the last few releases we've noticed that not only does Xubuntu pale in comparison to some of the other Xfce4 distribution but we've also been putting on even more weight and bulk. Although it is not Xubuntu's goal nor target to provide a desktop environment which will run on the most minimal of system requirements, it is Xubuntu's goal to provide a desktop that is modest and can run with minimal problems on machines that have aged a few years.

The initial target will be 128mbs-192mbs of RAM (with appropriate swap space available) and 333Mhz-400Mhz CPU. The target for a release will be evaluated at the beginning of each release cycle and updated as required.

Success will be measured via test cases. A minimal level of functionality will be decided upon (for example, installing from live cd, listening to music, browsing the web, and concurrently listening to music and browsing the web) and it must be reasonably obtainable to register success.

(Unofficial) Focus 4: Community

Although not an official member of the Xubuntu Three Tier focus (as we've limited its scope to technical considerations), community *is* most certainly a focus and priority within the Xubuntu project. Xubuntu is community driven meaning that it is developed, maintained, and supported by members of the Xubuntu community. For Xubuntu to be a healthy and successful project, it must have a healthy and successful community. Xubuntu, as a project, will aim to be composed of a vibrant, active and energized community and will attempt to accomplish this by being proactive in its development of said community. Xubuntu will host bug days, packaging jams, and other public events specifically targeted to raising awareness and interest in the Xubuntu project.

Success will be measured via IRC, forum, and list acitivty as well as turn out to Xubuntu events.

Xubuntu Community

Xubuntu Governance & Team Structure

The following sections explore the Xubuntu governance and team structure. The workflow, procedures, policies, and other relevant information for the function that the team provides can be found later in this document under the "Standard Operations" header.

A simple overview of this structure would show you that there are three main groups:

1. Xubuntu Users
2. Xubuntu Contributors
3. Xubuntu Council

Xubuntu users is a collection of users who use Xubuntu or are interested in Xubuntu.

Xubuntu Contributors is the recognized contributing user body. Individuals who have made a significant and sustained contribution

Xubuntu Council is a small team of individuals from different fields in the Xubuntu community who are responsible for making important decisions about Xubuntu, providing leadership and direction, resolution of internal conflicts, and ensuring Xubuntu policies and procedures are executed as desired.

Below, each section describes a team and their sub teams. In each team description, you will find a short description, rationale, membership policy, team ownership, team leadership, team responsibilities, and sub-teams.

Xubuntu Users (xubuntu-users)

The Xubuntu users team is a collection of dedicated Xubuntu users.

Rationale: Provide a group for users to organize and identify themselves with. This team already exists.

This is an open team. To join this team, you agree to assist other users (when you can) on IRC and the xubuntu-users mailing list. Furthermore, members of this team are encouraged to assist in Xubuntu marketing efforts. It is the member's responsibility to adhere to the terms of their membership.

This team is owned by the Xubuntu Council and is lead by Xubuntu Contributors.

This team team is responsible for:

• Community, user support; and
• Marketing.

The following teams are members of this team:

• Xubuntu Contributors; and
• Xubuntu Council.

Xubuntu Contributors (xubuntu-team)

This team exists to recognize and help coordinate Xubuntu contributors. Furthermore, this team will be the bug contact for all Xubuntu packages. The e-mail contact for this team will be set to the xubuntu-bugs mailing list (resulting in all bug mail being sent to the list instead of individual members) allowing optional subscription to Xubuntu bug mail for both team members and non-team members.

Rationale: To provide a team to identify Xubuntu contributors and allow for members to organize themselves. This team already exists but will be re-branded for improved clarity.

This is a moderated team. To join, the following criteria must be met:

• User has demonstrated sustained and significant contribution for a minimum of three months;
• User has clear plan for future contributions;
• User has detailed their contributions on their wiki page; and
• the User has demonstrated a good understanding of the Xubuntu community and its operation.

This team is owned by the Xubuntu Council and is led by its senior members and the Xubuntu Council.

This team is responsible for:

• Coordinating contribution efforts;
• Community, user support;
• Marketing;
• Coordinating bug triage efforts;
• Managing Xubuntu products; and
• Working with upstream to see that bugs are fixed upstream;

The following teams are members of this team:

• Xubuntu Documentors; and
• Xubuntu Developers.

Xubuntu Documentors

The Xubuntu documentors team exists to coordinate development and maintenance of Xubuntu system documentation, Xubuntu wiki, and the Xubuntu website.

Rationale: Allow select individuals (ie. recognized contributors) commit access to bazaar branch containing Xubuntu system documentation and Xubuntu website development copy. (The doc branch would be merged regularly with the official Xubuntu system documentation branch hosted by the Ubuntu documentation project core team.) Furthermore, it would allow users to organize themselves and their activities including writing wiki pages and developing the website.

This team is a moderated team. To join, the following criteria must be met:

• User is interested in writing system documentation and/or work on the Xubuntu website;
• User has demonstrated appropriate skill (ie. written language, docbook, html, php, etc.); and
• User has been a positive contributor via patches/sponsorship already.

This team is owned by the Xubuntu Council and is lead by its senior members.

This team is responsible for:

• Writing and maintaining system documentation;
• Writing and maintaining wiki pages;
• Writing and managing content on Xubuntu website; and
• Developing the Xubuntu website, including theme.

No other teams are a member of this team.

The Xubuntu documentors team has several virtual (ie. the only launchpad team is ubuntu-docs) teams that work on specific components/projects: Xubuntu website editors, Xubuntu wiki team, and Xubuntu doc team.

Xubuntu Developers

The Xubuntu developers are individuals who have a sustained and positive record of contribution via packaging.

Rationale: It is important to have a team to distinguish individuals who are recognized developers as developers are often responsible for making day to day decisions regarding packages and other development related topics. This team would also host the Xubuntu seeds.

This team is a moderated team. To join, the following criteria must be met:

• User has a sustained and positive record of contribution via packaging to Xubuntu;
• User has demonstrated appropriate skill and trustworthiness to be entrusted with upload privileges to Xubuntu and Xubuntu related packages; and
• User is willing to assist in merging, syncing, and packaging of Xubuntu related packages.

This team is owned by the Xubuntu Council and is lead by its senior members.

This team is responsible for:

• Packaging, merging, syncing, and developing Xubuntu;
• Fixing bugs;
• mentoring promising contributors; and
• helping the other teams make Xubuntu rock.

Xubuntu Council (xubuntu-council)

The Xubuntu council is a small group of people who have been designated as "movers and shakers". Initially, the Xubuntu project leader will fill this role until the project's growth requires the formation of an official council.

Rationale: It is important to be able to identify individuals who have been assigned with task of leading and managing the Xubuntu project. This team does not currently exist. It may be possible that a Xubuntu council is not required nor useful.

This team is a restricted team. To join, the following criteria must be met:

• User has extensive experience with Xubuntu and Xfce4;
• User is well known within the Xubuntu and Ubuntu community;
• User has demonstrated strong leadership, communication, and collaboration skills;
• User has been selected to help lead Xubuntu.

This team is owned by the Ubuntu Community Council and is lead by the Xubuntu Team Leaders.

Dispute Resolution

Disputes occur in every project. A project is healthy not when they experience no disputes but when they do experience disputes they're able to work through them through collaboration or come to compromise when necessary. For that to happen, there needs to be a dispute resolution process that is easy to follow and use and able to give clear, concise resolutions in the end. The Xubuntu project is no different.

The Code Of Conduct is one of the most fundamental documents in the Ubuntu community. Within it, expected core standards of behavior are laid out, which while innate in most people, the document clearly defines standards of "being excellent to each other" in the Ubuntu community.

Although the CoC defines these core standards of behavior, it is not intended to be a document that is used against people accused of not adhering to the concepts in it. The CoC is really intended as a document to outline clearly what the community expects. If someone is quite clearly behaving against the standards of the CoC, the CoC should not be used as evidence against them, the person is quite clearly not acting within the spirit of the community, and their actions are what they should be judged on.

If you feel that someone is not acting within the spirit of the community and their behavior is not within the CoC, you should be careful not to shout, "You are breaking the CoC!" at them. Any accusations of unsuitable behavior should focus on their actions and why their actions are causing problems in your community. If this is not effective and the issue persists, the next step would be to ask for intervention/assistance from a trusted third-party in the community.

Although a majority of disputes will be resolved though effective communicate, in situations that require further assistance the appropriate escalation would be to the Xubuntu council by adding the issue to the Xubuntu council's agenda for the next meeting. At the meeting, attending parties will explain their issues and point of view to members of the council and the council will be able to either assist in mediating the issue or provide a resolution for the involved parties. In cases where it would not be appropriate to take the issue to the Xubuntu council, one feels the issue was not dealt with correctly by the Xubuntu council, or when the Xubuntu council is not available then the next appropriate level of escalation would be to the Ubuntu Community Council.

Instigating Growth

If Xubuntu is not growing, it is dying. To ensure constant and sustained growth of the project, it is important the Xubuntu leaders stay involved and keep the community informed of developments, news, and progress. Activity and growth is viral. When activity in a project is present, it tends to generate further activity and interest. If interest and involvement is not maintained then the project's community will regress.

Xubuntu will also host community events such as bug days, packaging jams, and other sessions to promote and encourage Xubuntu awareness and activity.

Xubuntu contributors will be encouraged to blog about Xubuntu on their blogs and have their blogs syndicated to locations such as the Ubuntu Planet.

An active effort will be made to ensure that Xubuntu related stories and articles of interest make their way to the community at large via mediums such as the planet and the Ubuntu weekly newsletter.

Xubuntu contributors will work with Ubuntu counterparts and establish mutually beneficial working relationships and flows of contribution.

Communication

For Xubuntu to be successful, its members and community must have the right tools to enable useful and helpful communication:

• The xubuntu-devel mailing list is where discussions regarding general Xubuntu development takes place.
• The xubuntu-users mailing list is where discussion occurs and support given by fellow Xubuntu users.
• The #xubuntu IRC channel is where real time discussion and support is given by fellow Xubuntu users.
• The #xubuntu-devel IRC Channel is where real time discussion, coordination, and collaboration occurs between Xubuntu contributors.
• The #xubuntu-offtopic IRC Channel is where real time, offtopic chit-chat between members of the Xubuntu community occurs.
• Launchpad is used for the tracking and management of specifications and bugs for/in Xubuntu.
• The Xubuntu pages on the Ubuntu wiki are used to share information about teams, getting involved, procedures, meetings, and other useful information for contributors.
• The Xubuntu pages on the Ubuntu community help wiki are used to share community generated and supported Xubuntu documentation.
• The Xubuntu website will be used to provide general information and serve important news releases about Xubuntu - linking to wiki and other resources as appropriate.

Xubuntu Development

This section describes topics related specifically to Xubuntu development.

Coordination

Day to day coordination of Xubuntu development is done by the senior members of the Xubuntu development team with their direction coming from the Xubuntu council, previous meetings, specifications, and other written documentation.

Every two weeks, an Xubuntu developer meeting will be held where each attending developer will go over what they worked on over the last two weeks and problems they faced. This will be followed by discussion of pending agenda items. The meeting will be concluded with a general priority being set for the next two weeks by the Xubuntu development lead and each attending developer will describe their plans and intentions taking into account the current priorities.

For bigger decisions such as release priorities, the Xubuntu council members will be responsible for making sure that developers and contributors are aware of said decisions and current project priorities. The Xubuntu council will meet monthly to discuss and review process and review pending agenda items. However, this monthly meeting should not be considered blocking - appropriate discussion via the mailing list can be just as effective and allow for quicker response times.

Release Cycle

Designing a release

At the start of each release, it is important for Xubuntu to have a proper release plan and release goals. The design phase starts at the very beginning of the release cycle and ends shortly after the Ubuntu Developer Summit.

Each release, the Xubuntu council and Xubuntu developers will decide on a number of specifications that are of interest and which are obtainable within Xubuntu's available resources and manpower. Specifications are documents that describe a priority, process, or feature including details such as rationale, design, implementation, dependencies, use cases, and more. A specification is not required to be created for regular release processes such as merges and syncs of Xubuntu packages. However,the topics of the specifications will be influenced by the general priorities and interests for the release set by Xubuntu council which will be inspired by Mark Shuttleworth's direction for Ubuntu.

By the end of the design phase, all specifications should be close to being ready for approval. Once a specification has been approved (which will generally be done by a member of the Xubuntu council or appropriate designated delegate) then the developer responsible for developing it will begin implementation which leads us into the next phase.

Developing a release

Each release cycle, there are number of tasks that will occur every time:

• Each release, Xubuntu packages will be synced or merged with Debian as appropriate.
• Each release, bugs reported by users will be reviewed, fixed, and/or passed up stream.
• Each release, we will attempt to reduce our delta by pushing appropriate patches upstream.
• Each release, we will profile Xubuntu to ensure we are meeting our hardware targets.
• Each release, we will evaluate the seeds to ensure we are shipping the optimal software.
• Each release, we will work on improving and updating the Xubuntu documentation.
• Each release, we will test Xubuntu to ensure stability and uncover bugs.

Otherwise, we'll be working on developing the specifications we have targeted.

Testing a release

Throughout the release cycle and even more so nearing the end, we will test Xubuntu to ensure that Xubuntu is a quality product that we are proud of and that the changes we have been making work correctly, work as expected, and do not cause regressions. The Xubuntu testing team will help ensure that when milestone ISOs are released that all tests are completed and results reported to the tracker. Xubuntu testers will also test the daily builds, upgrading through supported and unsupported release paths, and running Xubuntu to help detect problems. Xubuntu testers play an instrumental role in producing a quality product for end-users and their time is greatly valued.

The daily images between milestone releases (usually called "nightly releases" or "nightly images") will typically only be tested by developers, testers and enthusiasts. The milestones ("Herds" in the case of the Fawn) are more widely announced and will be tested by a larger audience. As such, the two types of releases serve different purposes, and need to be tested differently. The most important goal with testing the nightly images is simply to find as many bugs as possible and report them with enough detail that they can be fixed. Finding the bugs ahead of the milestone crunch (in random dailies) is helpful as it gives developers more time to fix them. Timely feedback regarding nightly-image test results is important. Furthermore, in doing specific testing of the CD/DVD images it is important to focus on those aspects that are typically not used by those who simply run the latest unstable version on their system through daily updates (Such testing is of course also extremely valuable). Key points in image testing include image integrity (md5sums), Live CD and installer functionality.

Deploying a release

When it comes time to deploying a release (both milestones and final), first several conditions must be met:

• Appropriate testing has been done on the image;
• There are no known bugs which cause data loss or damage to hardware;
• The image must not be oversized; and
• Xubuntu must be of sufficient quality that it would not damage Xubuntu's, Ubuntu's, or any of the other derivative's reputation/image.

When a release is made, the following steps/actions must be taken:

• Release notes must be prepared and made available;
• Release announcement must be written and published post release;
• website news item added;
• wiki updated; and
• IRC channel topics updated.

When a final release is made then the tour, screenshots, and download page must also be updated on the Xubuntu website.

Although not essential, it would be very beneficial for contributors to blog about the release. This can be especially beneficial for milestone releases in attracting testers and reviewers to help find bugs and build hype respectively.

Maintaining a release

After a release is made, bugs and problems are bound to reported. During the period between the release and the start of the next release cycle is the optimal time to perform Stable Release Updates as long as developers do not forget to fix the issue in the next release as well once the repository opens. Once the next release cycle has started, primary focus will be on the next release and the severity/importance of the SRU candidates will be more important when decided if an SRU will be performed or not.

Although Xubuntu can not provide commercial support or commercial guarantees, Xubuntu will make every effort to match the Canonical support period and provide security updates for Xubuntu packages.

Seeds & Composition

Seeds and package composition of Xubuntu has been a touchy issue in the past. To help avoid issues and disputes, this section will describe core components of Xubuntu which will always be shipped with Xubuntu, packages/types of packages that are not appropriate for Xubuntu, and information on how to decide which packages best fit Xubuntu.

Most importantly, we define the bottom line.

The Bottom Line: Changes will not be rationalized using the below guidelines alone but instead will rely on well thought out arguments, useful measurements, and meaningful test cases in conjunction with evidence of affinity with the Xubuntu mission statement and three tier focus.

Core components of Xubuntu

Core components of Xubuntu are packages that are considered to be so fundamental that if removed/replaced then the product would no longer be Xubuntu unless Xfce4 upstream deprecates and/or replaces them or very compelling reasons required for them to be substituted. For example, there has been upstream discussion about removing the Xfce4 session manager from the stack. If this were to occur, it would be acceptable (and possibly advisable) for Xubuntu to no longer ship that package.

• xfce4-session (Xfce4 Session Manager)
• xfwm4 (Xfce4 Window Manager)
• xfdesktop4 (Xfce4 desktop)
• xfce4-panel (Xfce4 panel)
• thunar (Xfce4 file manager)
• xfce4-utils (Xfce4 utilities)
• xfce4-mcs-manager (Xfce4 settings manager)

Other applications which contribute to the Xubuntu identity as well but are not considered "critical" (and hence may be removed, replaced, etc. with solid/reasonable and concrete discussion and rationale) are:

• orage (Simple Calendar)
• xfce4-terminal (Xfce4 terminal emulator)
• mousepad (Simple text editor)
• xfce4-appfinder (Xfce4 application finder)

Incongruous Packages & Precedents

Packages that work against our goals and our mission statement obviously aren't appropriate when considering them for inclusion in Xubuntu. However, what isn't always obvious or easy is making that determination due to deliberate flexibility in interpretation and variable perceptions. To assist in that process, the following list of guidelines can be used to help identify areas of concern in candidate packages.

• Packages that do not use GTK toolkit (ie. QT/KDE applications) should not be included.
• Packages that use interpreted languages are generally slower and require more memory then ones that are compiled.
• C is preferred over C++ as C++ programs tend to be heavier.
• Packages that will pull heavy/costly libs (ex. certain gnome libs) are discouraged. This is especially true for packages that will run and/or start frequently.
• If possible, we should limit the number of gnome libs we pull in. However, we should not remove/change applications for alternatives to reduce the number of applications that use a gnome lib unless we can remove the lib all together with a net positive benefit. The reasoning being that use of gtk equivalents (where available) is preferred.

• If an application shares its functionality with other applications through libraries whereas the alternative choice does not then the former is preferred as it will generaly correlate to better security (better reviews & more testing), localization, and mean the cost of those libraries is divided among the benefit provided by those applications compared to application suffering from NIH.

Package Selection Matrix

To meet our performance objectives, we must be very careful about the applications we seed/include with Xubuntu; we have to think objectively and may not be biased. Applications that make it into Xubuntu must be clearly rationalized and are in the spirit of Xubuntu. The Xubuntu council and Xubuntu developers will determine if a package is right for Xubuntu by measuring and comparing elements such as usability, usefulness, memory consumption, integration, maintainability, file size, stability, translations, maturity, upstream, performance, and user demand/interest. We will call this measurement "weight" and where a package/software is more heavy, the more undesirable it is in Xubuntu. Furthermore, when measuring if a package is right for Xubuntu, your decision will not be made based on your analysis of package alone but instead the collective target package and its dependencies.

First, to fit well in Xubuntu the software must be usable. It must have a well designed interface that is easy and uncomplicated; ultimately the goal is to enable the users to accomplish their desired task quickly and effectively.

There is no point of including an application in Xubuntu if it is not useful, and useful to the majority of users who will be using Xubuntu. Since users are free to install/remove/etc. software after install, we will want to include the most relevant software that will give the impression that Xubuntu is a useful operating system that allows users to get what they need done done.

When an application is running, it takes up memory. If an application makes use of a library, then the library is also loaded into memory which means the more libraries an application uses then the more memory it is using. Luckily, memory management is smart in that it does not store data twice. If two applications us the same lib, the lib is still only loaded into memory once (although there will still be a small portion that is unique to each application, ex. 4kb). This means that when deciding to include an application, we must not only consider its memory consumption and weight but the weight of all of its dependencies. Software that is slow and CPU intensive is probably not a good fit for Xubuntu either.

Software that is well integrated and provides a polished desktop experience is a huge benefit to Xubuntu and its users. Software that comes well integrated from upstream is desirable as it reduces the burden placed on Xubuntu developers to provide that integration and the associated maintainability costs.

Software that causes developers extra work and is more difficult to maintain (this includes software that is immature, buggy, and/or lacking a solid upstream) is a serious consideration and one that must not be taken lightly. Due to manpower constraints, we should aim to reduce reoccuring workload and elimenate maintenance burdens.

Although not as important as some of the other elements, the amount of file space required to include an application must be considered when deciding if an application should be included. Xubuntu ships on a standard CD-ROM and space is always tight since we try to ship as many language packages as possible so that users with slow or nonexistent internet connections can use Xubuntu in their native tongue.

A requirement for any software to make it into Xubuntu is that the software is tested to ensure that it has an appropriate level of stability and doesn't contain an unusually large number of bugs (which will result in more work for developers who will have to do SRUs). In cases where the software appears stable, you'll want to consider the software's "maturity". How long has it been around? How long has it been being developed? How mature are the upstream processes? How mature does the software appear overall? Xubuntu is not a testing ground for new, immature software and certainly not appropriate for software that is new, immature, *and* buggy. Furthermore, the author (or who the upstream is) of the software will only have minimal impact - an author we've worked with and know to be of high caliber helps lend credibility to software (and the reverse for authors who we maintain poor relationships with) but can only be used as supporting rationale. For example, software that is being hosted on the Xfce4 server or is a member of the xfce4 goodies project is not given unfair appreciation; The merit and measured weight is more important then wheter it's an official Xfce4 (side) project or not (excluding components listed in the prior core component section).

The name of the software/package will have absolutely no bearing on inclusion. Just because the developer brands the software in way to suggest affiliation or integration with Xfce4 does not mean the software is appropriate for Xubuntu or the optimal choice.

In the future, a quantitative system will be developed to assist us in the package selection process.

The above points should not be considered an exhaustive list of elements to weigh; always use common sense.

Upstream Relations

Maintaining healthy relationships with projects that are upstream of Xubuntu is an important task and delicate one at that. By maintaining healthy personal and professional relationships with upstream projects and their developers/maintainers, we allow for more fluid communication and collaboration which results in a better product for everyone.

To build this relationship, developers and bug traigers alike will want to start by subscribing to upstream discussion and bug mailing lists. This will help keep you informed about bugs that get reported and fixed, allowing us to respond quickly and efficiently. Specifically with Debian, working with and keeping the delta minimal will allow us to take full advantage (ie. reducing duplication) of their efforts. In reverse, it would not necessarily be expected that Debian or Xfce4 developers would be subscribed to our discussion and bug mailing lists so we need to actively and consciously push fixes that are applicable and useful to our upstream counterparts. This gives us the added benefit of developing more one on one relations of trust and respect with the upstream developers furthering the objective of making collaboration are smooth and easy as possible.

Once we begin to work more and more with upstream, we'll likely run into situations where our project disagrees with a decision that the upstream project has made. In these cases, we need to make sure that we always remain polite and objective in our evaluations. Although we will always make decisions that are best for Xubuntu, sometimes compromising with upstream is required. These situations will be handled case by case with a strong desire to always maintain the best of relations with upstream.

Dispute Resolution: Development Issues

When disputes occur in the development team (or with upstream), always remember to remain polite and civil to your fellow developers. The Xubuntu developer meetings are a great time to hash out problems with the assistance of the whole team. When developers are unable to reach consensus then normal escalation to the Xubuntu council will occur where the Xubuntu council will decide via vote.

When disputes do occur, developers are strongly recommended that they withhold from making the changes under dispute to avoid sabotaging the dispute resolution process. For example, if there is an issue over package selection then developers will not go ahead and make the related changes to the seeds until the dispute is resolved.

Standard Operations

This section describes the various standard operations of Xubuntu, their workflow, policy, procedures, and other relevant information.

 IDEA: Get the community in the next community meeting to finish the rest of the document.

Packaging

Documentation

Bug Triage

Artwork

Testing

Support

Marketing