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 improve the Xubuntu project's ability to become a sustainable and healthy project. The goal is to describe the long term strategy, vision, and direction of the Xubuntu project. Xubuntu developers and contributors will utilize this document as a guide and reference to assist them in coming to decisions regarding the Xubuntu project.

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 that we move forward in a direction that is healthy for the project.

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.

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 we also want to see Xubuntu usable in the sense that it is accessible to users who face impairments and disabilities. To accomplish this, we'll strongly consider the usability and accessibility of an application when deciding on package selection. Furthermore, we'll also invest efforts in contributing to upstream usability fixes and improvement of accessibility infrastructure.

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.

(Unofficial) Focus 4: Community

Although not an official member of the Xubuntu Three Tier focus, 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 targetted to raising awareness and interest in the Xubuntu project.

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 a team which has several other teams as a member of it. Teams of Xubuntu contributors are a member of this team and users who are contributors but not a member of one of the sub teams are also a member of this team.

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

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

Rationale: Provide a group for users to organize and identify themselves with. This team is non-essential. 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

This team exists to recognize and help coordinate Xubuntu contributors. Often contributors will join one of the sub teams directly however users who are recognized for their community support, testing, and marketing efforts would join this team directly.

Rationale: To provide a team to identify Xubuntu contributors and allow for members to organize themselves. This team does not exist currently.

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; and
• Marketing.

The following teams are members of this team:

• Xubuntu Bugsquad;
• Xubuntu Documentors; and
• Xubuntu Developers.

Xubuntu Bugsquad

This team exists to organize and direct Xubuntu bug triage***ing*** efforts. Members of this group will receive all of the bug mail for Xubuntu packages and own all the Xubuntu products.

Rationale: Xubuntu bug mail traffic is significant. Having this team will allow users to decide if they want to receive that bug mail and also recognize contributors who have worked on bug triage. This team does not currently exist. An alternative to this team would be to simply make an existing team the bug contact, etc. create a mailing list, and set that mailing list as the contact for the group. This would allow us to reduce the number of groups and allow for individuals to subscribe to bugmail without joining a team.

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

• User is interested in receiving Xubuntu bugmail;
• User has demonstrated that they are capable bug triagers; and
• User is interested in triaging Xubuntu bugs.

This team is owned by the Xubuntu Developers and is lead by its senior members with the assitance and guidance of Xubuntu developers.

This team is responsible for:

• Coordinating bug triage efforts;
• Managing Xubuntu products;
• Working with upstream to see that bugs are fixed upstream; and
• Xubuntu bug triage.

The following teams are members of this team:

• 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. there is no launchpad group) 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;
• and helping the other teams make Xubuntu rock.

Xubuntu Council

The Xubuntu council is a small group of people who have been designated as "movers and shakers".

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 collaberation 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 from another community member, preferably a senior member/team leader. They may be able to act as a catalayst and assist you in resolving the dispute with minimal overhead.

In situations where peer dispute resolution does not have the desired effect, 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.

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 session 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.

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 & Precidents

Packages that work against the our goals and our mission statement obviously aren't appropriate. However, what isn't always obvious is which packages aren't inline with those goals and the missions statement because of the flexibility in interpretation and variable perceptions one can take on certain measurements. Now that we've listed packages that we consider a "core" to Xubuntu, here are some quick rules/specific packages that probably shouldn't be in Xubuntu.

• Packages that do not use GTK toolkit (ie. QT/KDE applications) should not be included at all.
• Packages that use interpreted languages are generally slower and require more memory then ones that are compiled.
• C is preferred over C++.
• Packages that will pull in a gnome lib that is not already pulled in can be not be seeded without the review and approval of the Xubuntu council.
• Applications that use a lot of libs mean more memory usage - even more so for applications that use a lib exclusively.
• 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.

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 good interface which doesn't makes it easy and uncomplicated for users to accomplish the desired task.

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 useful 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). 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 is slow and takes up a lot of CPU? It might not be good 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 (if possible) 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 likely. Due to manpower constraints, we should aim to reduce unrequired workload and 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 new, immature, and buggy software. 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 but does not provide it its self. Furthermore, software that is hosted on the Xfce4 server or a member of the xfce4 goodies project should also have only minimal influence. The merit and measured weight is more important then if it is an (un)official Xfce4 side project or not.

Finally, two other possible bonus points for software is how well it is translated and the actual demand/interest from our target audience/end-users.

In the future, we may develop a quantitative system to assist us in the package selection process. Furthermore, the above list of elements to consider 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