Ubuntu Wiki

Introduction

About this document

This document will describe the strategy, vision and direction of the Xubuntu project as well as act as a guide and a reference for the Xubuntu Team.

This revised version has been written by Pasi Lallinaho with the help of Elizabeth Krumbach and Simon Steinbeiß along with numerous people in the community. This version is based on the existing Xubuntu Strategy Document by Cody Somerville et al.

We wish thank to Cody Somerville, Jono Bacon, Eero Tamminen, Nico Veenkamp and Lionel Le Folgoc for their contributions to this document. Some content, ideas, and inspiration were derived from existing Ubuntu documentation.

Mission Statement

Xubuntu is a community-developed, Ubuntu-based operating system that combines elegance and ease of use. Xubuntu provides a light, stable and configurable desktop environment with conservative workflows. Xubuntu delivers a polished and unified product ready for end-users.

In addition to the technical aspects, the Xubuntu team focuses on contributor and user communities.

The Target

The target audience for Xubuntu consists of users who are interested in having an elegant, easy to use, polished and unified operating system. Xubuntu is a good option for those who want a stable, configurable and/or relatively light desktop environment too. Finally, Xubuntu is an appealing choice for users who prefer conservative workflows over the newest innovations.

Xubuntu does not target users with specific skill sets or aptitudes. 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. Xubuntu does not specifically focus on new users or users migrating from Windows, but according to this ease of use, it is a good alternative for those users as well.

Xubuntu does not explicitly target users with low, modest, or high powered machines but instead targets the entire spectrum. Xubuntu's extra responsiveness and speed, among other positive traits, can be appreciated by all users, regardless of their hardware.

While Xubuntu uses Xfce, it is not specifically targeted to Xfce enthusiasts or projects and software being hosted by the Xfce project or associating (officially or unofficially) with Xfce are not guaranteed for inclusion in Xubuntu.

The areas of focus

This part of the strategy document provides a transparent framework and a set of priorities for the whole Xubuntu development and its tasks, including but not limited to decision making processes, package selection and technical dispute resolution.

The areas of focus are presented in an abstract and simple form but are also concrete enough to be actionable. As the foundation of the Xubuntu vision, the specifications in the strategy document 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: Usability

Usability is one of the most important parts of an operating system which is used on a daily basis. This is why Xubuntu should be easy to use and have an appearance that doesn't get in the way. The appearance should be an all-round experience, covering all user interfaces from booting to shutting down.

Xubuntu should be localized to allow users to work in their preferred language. Another important aspect of usability is configurability. We believe Xfce gives users the possibility to configure their system in a meaningful way; other applications should live up to this expectation at least moderately well.

While accessibility is not one of the main priorities of Xubuntu, it should be taken into serious consideration as long as it doesn't require unreasonable efforts to integrate, implement or maintain. At least common accessibility tools should be installed in the default Xubuntu installation.

Focus 2: Performance

The Xubuntu team should strive to make Xubuntu lightweight. This means every Xubuntu release should work moderately well on machines that date to a few years before the release date. This ultimately means that newer Xubuntu releases may not able to support older computers. However, it assures that the Xubuntu team is able to work on other improvements and provide a release that is able to fulfill the expectations for a modern operating system.

Users wanting the most lightweight system possible should be pointed at the minimal CD, more lightweight derivatives (such as Lubuntu) or other options.

At the start of the release cycle, the minimum system requirements should be re-evaluated to determine if they continue to be realistic.

Focus 3: Ready to use product

It is important for us to provide a polished and unified product that is ready for end-users. It is also a prerequisite to enabling Xubuntu as a useful, usable and effective desktop. Without the mentioned integration, the Xubuntu desktop will appear rough and unpolished which is unappealing to end-users.

The integration is accomplished also by selecting applications and libraries that work well with each other as well as by applying patches to assure a more bug-free system.

See the "Package Selection" section for guidelines on how to determine if an application fits in the Xubuntu stack.

Focus 4: Community

The Xubuntu community is an important force in creating Xubuntu and making it as perfect as it can be. It's essential that regular coordination between contributors work well. The infrastructure to allow good communication between the contributors as well as users is described more closely in "Xubuntu Community" and "Xubuntu Development".

Where possible and appropriate, the Xubuntu team should work together with other communities, including other Ubuntu teams and upstream. If cooperation at a given time is not possible but would be beneficial for both parties, the Xubuntu team should try to allocate some resources to the cooperation at a later time.

Xubuntu Community

The Xubuntu community is comprised of two main groups, Xubuntu users and Xubuntu team. The Xubuntu team has four subteams; Xubuntu Artwork team, Xubuntu Developers, Xubuntu Documenters and Xubuntu Website team. This section covers the governance and team structure of the aforementioned teams, along with the definition of Xubuntu Project Lead.

Xubuntu Users

Xubuntu users is a collection of users who use or are interested in Xubuntu. The purpose of this group is to identify and organize Xubuntu users.

The users in this group will be able to vote in the Xubuntu community meetings. The members in the Xubuntu users group are encouraged to give user support on IRC and the xubuntu-users mailing list as well as spread the word about Xubuntu anywhere they see fit, including but not limited to blogs, social media and conferences.

The group is registered in Launchpad as xubuntu-users. It is open for anybody to join. The Xubuntu team is a member of this group.

Xubuntu Team

The Xubuntu team is a group of individuals who are primarily responsible for the Xubuntu development.

This team is responsible directly or via its subteams for:

• Coordinating contribution efforts
• Managing the community
• User support
• Marketing
• Coordinating bug triaging
• Managing Xubuntu products
• Working with upstream on bugs

Members of this group can be appointed as team leads by the Xubuntu project lead. Any member appointed as a team lead by the project lead should have a second casting vote in addition to the Xubuntu project lead, if the said issue clearly concerns the team lead's team/area of expertise. For example, the artwork team lead will have a casting vote in artwork-related issues.

The group is registered in Launchpad as xubuntu-team. The team is moderated. The individuals wanting to join this team are required to meet the criteria described below prior to applying or they will be automatically declined. The Xubuntu project lead is responsible for moderating this team.

Becoming and staying a member

To be accepted to this team, applicants participants must demonstrate their motivation and ability to contribute to Xubuntu. This is to ensure that any Xubuntu team member has a sufficient understanding of the Xubuntu community and its operation. The different steps one must go through will also indicate that the candidate member is able to work within the guidelines, and more important, with other people and communities.

The process to become a Xubuntu team member is explained below. Please note that approving to subteams and the Xubuntu team has no specific schedule and happens only when the concerning people think it is appropriate to approve. For example, to join the Xubuntu Developers team usually takes more contributions to join than the rest of the subteams.

• Commit meaningful contributions to one of the subteams; you will be approved to the subteam for "probation" by a subteam administrator
• Demonstrate motivation to contribute perpetually; you will be approved to the Xubuntu team by the Xubuntu project lead

Since the Xubuntu contributor community fluctuates in its size, the subteams are established or discontinued based on the current situation by the Xubuntu project lead whenever it makes sense. If newly established subteams need access or have other technical needs, the Xubuntu project leader will set those up with the help of other concerning parties, including team leads and other Ubuntu members.

To stay a member of this team, the members will have to have desire to continue contributing in the future. Any member with no contributions for more than a complete cycle (6 months) will be deactivated from the team and will have to reapply. A team member can get an exception to this by simply leaving a note that they will be taking a break from contributing. However, if the break is to last longer than a cycle, or the contributor is unsure if they will contribute at all in the future, it would be preferable for the contributor to leave the team and reapply at a later time. Membership in the subteams is not as strict, but people with no contributions for a significantly long time will be deactivated from the subteams too.

Xubuntu Developers

The Xubuntu developers is a team that is responsible for:

• Packaging, merging, syncing and developing Xubuntu
• Fixing bugs
• Mentoring new contributors to development
• Managing the Xubuntu seeds

The criteria to join this team are:

• Sustained and positive contribution via packaging to Xubuntu
• Appropriate skill and trustworthiness to be entrusted with upload privileges to Xubuntu and related packages
• Willingness to assist in merging, syncing and packaging Xubuntu and related packages

The group is registered in Launchpad as xubuntu-developers. The team is moderated. The individuals wanting to join this team are required to meet the criteria described above prior to applying or they will be declined. The Xubuntu Technical lead (or if one doesn't exist, the Xubuntu project lead) is responsible for moderating this team.

Xubuntu Project Lead (XPL)

The Xubuntu project lead is ultimately responsible for Xubuntu and ensuring that a quality product is able to be released on schedule.

The Xubuntu project lead serves a term of four releases. The term should start with a release just after LTS, and end with an LTS release to make long-term planning and major undertakings possible within a term. After the term they must seek reconfirmation from the Xubuntu community via a public vote. If consensus is unable to be found, the matter is referred to the Ubuntu Community Council.

The Xubuntu project lead is chosen by a popular vote. Anyone in the Xubuntu Users group is eligible to vote. Project lead nominations are to be made in the month preceding the election by the members of Xubuntu Users. These nominations may be submitted by individuals nominating themselves or someone else. The project lead is to be the person receiving a simple majority vote. The person receiving the second highest vote will be the interim project lead should the project lead be unable to fulfill the entire term.

The voting should be arranged in a way that allows people in any timezone to vote. Ideally, the voting should be possible for 24 consecutive hours. Any voting method needs to fulfill the requirement to only allow members of the Xubuntu users Launchpad group to vote.

To make sure relevant information is available for anyone wanting to vote, the nominees are required to provide a wiki page with their thoughts on at least (but not limited to):

• A brief history of the nominee in the FOSS world
• Activities in any relevant teams
• Thoughts about the Xubuntu development, including the biggest challenges and possibilities
• Areas of interest as a project lead, including any changes the nominee is wishing to see in the team

In addition to the team leads, the project lead has a casting vote on any issue. If the vote is tied, the casting vote of the project lead will take precedence.

Ultimately, the project lead has a veto ability. The primary purpose of the veto vote is to prevent exhausting and interminable quarrels in the community. This authority is not to be used unless consesus has not been reached even after thorough, but not overly lenghty discussions. It's also encouraged to be in touch with other Ubuntu teams and ask for advice where applicable.

Xubuntu Development

Communication

For Xubuntu to be successful, its members and community must have the right tools to enable useful and helpful communication and ultimately, to help the community grow. These communication tools include the following "core" tools:

• Mailing lists
  • xubuntu-users for community support and user discussions
  • xubuntu-devel for development discussion and coordination
• IRC channels
  • #xubuntu for community support
  • #xubuntu-devel for development discussion and coordination
  • #xubuntu-offtopic for general discussion with a more relaxed mood
• Launchpad, for organizing teams as well as tracking and managing specifications and bugs
• The Xubuntu pages in the Ubuntu wiki for development coordination
• The Xubuntu website for news, development articles and general information about Xubuntu

The Xubuntu team members are highly encouraged to spread the word about Xubuntu anywhere they see fit, including but not limited to their personal blogs, social media and conferences.

In addition to communicating with each other and the Xubuntu community, the Xubuntu team should communicate continuosly with other Ubuntu contributors, upstream and other projects related to Xubuntu. The team members should take part in the development discussion outside Xubuntu as well to create and maintain healthy relationships with other projects and their developers.

Development coordination

The direction of the development of the project is coordinated by:

• The strategy document
• Release-specific blueprints and specifications specified in the Roadmap
• The Xubuntu community meetings

The Xubuntu community meeting will be held as often as the Xubuntu team needs fit, but it's encouraged to have at least one meeting per month. The community meetings are held in #xubuntu-devel and usually chaired by the project lead. When the project lead is not available, any other team lead can chair the meeting as well. If no team leads are available, the rest of the attendees are encouraged to have an informal meeting and inform the Xubuntu team of any discussion had.

The community meeting will more or less conform the following structure:

• Any business that is carried on from the previous meeting
• Team updates, including updating the team reports and release notes
• Announcements by the project lead or other team leads
• Any new business added in the agenda of the meeting

During any of the sections, the chair can assign action items to individuals or teams, with their permission. These action items are usually things that can't or aren't tracked in Launchpad (blueprint work items and bugs) and will be implemented or acted upon before the next meeting.

Dispute Resolution

The Code Of Conduct (CoC) is one of the most fundamental documents in the Ubuntu community, including Xubuntu, and it functions as the base for a working community. Everybody and every communicating medium in the Xubuntu community is CoC-compliant at all times.

Anybody behaving contrary to the standards of the CoC should be notified with consideration and adequate reasoning. If this is not effective and the issue persists, the next step would be to ask for assistance from a third-party member in the community.

When appropriate, the dispute should be escalated to the agenda of the next Xubuntu community meeting. At the meeting, attending parties will be given the opportunity to explain and justify their issue and/or stance, after which the Xubuntu team and project lead will assist in mediating the issue or, if not possible, provide a resolution for the involved parties.

The Ubuntu Community Council can be asked to act as mediators/advisors where their expertise would be useful when the Xubuntu team and project lead requires assistance. In development disagreements, the Ubuntu Technical Board may be called upon to help, particularly if the disagreement relates to broader project policy. The Xubuntu team and project lead are free to hear any other teams in the Ubuntu community if it helps resolving the issue.

When disputes on developement issues occur, developers are strongly encouraged to refraim from making the disputed changes 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.

Release Cycle

Designing a release

At the start of each release, the Xubuntu contributors will create a Roadmap for the release. Building and following the Roadmap has four phases:

• Brainstorming and finding assignees
• Approving blueprints
• Finalizing blueprints and specifications
• (Further discussion and) implementing

In the brainstorming phase, the contributors determine what they would like to work on during the release cycle. Adding items to the list is open for everybody in the Xubuntu community. After the brainstorming, this list will be closed. Settling on the goals in advance will make planning, focusing and estimating the likelihood for the features to be implemented easier.

In the approving phase, the Xubuntu team will approve or reject the proposed blueprints by a simple majority vote. Any items with no assignee will be automatically rejected. Items should also have a rationale. Having an assignee and a rationale will not guarantee that the blueprint is approved. Other criteria include, but are not limited to: likelihood of getting the feature implemented, maintenance weight in the future, possible stability issues, influence on other blueprints, et cetera.

The Xubuntu team can decide to postpone any items instead of approving or rejecting. In this case the items will be eventually moved to the Roadmap for the next release, unless they get an assignee and the Xubuntu team approves them for the release. Any items added to the list after the brainstorming phase and those that were postponed at the approving phase will need to be approved by the Xubuntu project lead along with the concerning team leads.

After blueprints are approved, they should be finalized and detailed specifications should be written. These specifications will inform the team about which changes are planned and will help guide the implementation. Any changes to the specifications after the finalizing phase need to be approved either by the concerning team lead or the project lead. At this phase, the Xubuntu team will set deadlines for the blueprints according to appropriate freezes specified in the Ubuntu release schedule. A deadline should usually be at least two or three weeks before the concerning freeze.

After the finalizing phase, assignees should implement the specified features before the deadlines specified by the Xubuntu team in the finalizing phase.

Developing a release

In addition to implementing the features and/or improvements set in the Roadmap, there are a number of tasks which will occur during each release cycle.

• Xubuntu packages will be synced or merged with Debian as appropriate
• Bugs reported by users will be reviewed, fixed, and/or passed upstream
• Attempt to reduce our delta by pushing appropriate patches upstream
• Review the Xubuntu system requirements
• Evaluate the seeds to ensure we are shipping the optimal software
• Work on improving and updating the Xubuntu documentation
• Test Xubuntu to ensure stability and uncover bugs

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. This includes testing that changes we have been making meet the release goals, work as expected, and do not cause regressions. Any tests run will be reported to the QA tracker.

The Xubuntu testing team will help ensure that when milestone ISOs are released, all tests are completed and results reported to the tracker. Xubuntu testers will also test the daily builds, upgrading through supported release paths and running Xubuntu to help detect problems. The most important goals for testing the daily images are simply to find as many bugs as possible and report them with sufficient detail to the tracker along with the ISO testing result.

When needed, the Xubuntu team will run application tests too. One example of this would be a new default application to be included in the next Xubuntu release.

Deploying a release

When it comes time to deploy a release (both milestones and final) 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 derivatives' reputations/images.

When a release is made, the following steps/actions must be taken (note that many of the items need to be prepared before release):

• Release notes must be prepared and made available;
• Release announcement must be written before and published after release;
• website news item added;
• release-specific pages on the website updated;
• wiki updated;
• IRC channel topics updated; and
• official social media accounts updated.

Maintaining a release

After a release is made, bugs and problems are bound to reported. The period between the release and the start of the next release cycle is the optimal time to perform Stable Release Updates (SRU) 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 it comes to deciding whether an SRU will be performed or not.

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

Seeds & Composition

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.

The bottom line is that 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.

Core components

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. These packages are:

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

Other applications which contribute to the Xubuntu identity as well but are not considered "critical" are:

• xfce4-terminal (Xfce4 terminal emulator)
• leafpad (Simple text editor)
• xfce4-appfinder (Xfce4 application finder)

Unsuitable Packages

Packages that work against our goals and our mission statement aren't appropriate when being considered for inclusion in Xubuntu. The following list of guidelines can be used to help identify areas of concern in candidate packages:

• Packages that do not use GTK toolkit (i.e. QT/KDE applications)
• Packages that use interpreted languages (generally slower and require more memory)
• C++ programs (tend to be heavier than C programs)
• Packages that will pull heavy/costly libs (i.e. "half of GNOME"), especially if they will run and/or start frequently

Package Selection

To meet our performance objectives and other set goals, we must be careful about the applications we seed with Xubuntu; thinking objectively is the foundation to proper application selection. Applications that make it into Xubuntu must be rationalized and be in the spirit of Xubuntu. The Xubuntu Project lead with the help of the Xubuntu technical lead will determine if a package is right for Xubuntu with the help of Xubuntu developers.

The following guidelines will help the developers to determine if a package is a good fit for Xubuntu:

• Usability. Is the application easy to use? Does it have a well designed UI? How easy is it to accomplish the task that the application is seeded for?
• Usefulness. Is the package useful for Xubuntu users?
• Resource consumption. In its entirety, along with all libraries, how much memory does the application use? Does it use libraries that are already in use?
• Integration and workload. How much work does it take to integrate the package to the system? Is the package well maintained upstream? Is the package used by other Ubuntu derivatives?
• File size. Does the package take so much space that the team has to consider dropping something from the ISO?
• Stability and maturity. Is the application tested well? How many bugs are there in the application? How mature the application is? How likely is it to get bugfixes to the application through normal processes and/or personal relations?
• Localization. Does the application have translations in the most commonly used languages?

Furthermore, when measuring if a package is right for Xubuntu, your decision should not be based on your analysis of package alone but should take into account the entire target package along with its dependencies.

The name of the software/package will have absolutely no bearing on its inclusion. Software being or suggested as being affiliated or integrated with Xfce is not the only argument for justifying appropriateness for Xubuntu.

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