Ubuntu Documentation - Desktop Getting Started
Ubuntu is all about community collaboration and the work we do together in order to produce a reliable world-class operating system. The same standards that apply to contributing to Ubuntu generally apply to contributing to Ubuntu Documentation.
Ubuntu Documentation is maintained by the Ubuntu Documentation Contributors Team with commit rights and administration by the Documentation Committers team and this page describes how you can start the journey of contributing to Ubuntu Documentation.
Tools for Ubuntu Documentation Work Flow
To be able to contribute to Ubuntu Documentation some tools will be required. So we will start by installing the following:
sudo apt install bzr xsltproc libxml2-utils yelp-tools yelp-xsl make
The command will install the following software (and possibly many additional dependent packages):
- bzr – distributed version control. Bazaar, a new way of working with packages for Ubuntu that will make it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each other’s work.
- xsltproc - XSLT command line processor.
- libxml2-utils - XML utilities.
- yelp-tools - Yelp documentation tools.
- yelp-xsl - XSL stylesheets for the yelp help browser.
- make - a utility for Directing compilation.
Since 17.10 the Desktop documentation mostly uses the gnome docs, directly from their related packages. Therefore a full multi-language build of the html is typically done on a desktop computer with all languages installed:
sudo apt install gnome-user-docs* gnome-getting-started-docs*
Xubuntu and the Serverguide use Docbook, and therefore require additional packages:
sudo apt install docbook docbook-xsl
- docbook - standard SGML representation system for technical documents
docbook-xsl - stylesheets for processing DocBook XML to various output formats
Additionally only the serverguide project requires another couple of packages:
sudo apt install fop gnome-doc-utils
- fop - XML formatter driven by XSL Formatting Objects
- gnome-doc-utils - collection of documentation utilities for the GNOME project
Create your SSH key
SSH stands for Secure Shell, and it is a protocol that allows you to exchange data in a secure way over a network. It is common to use SSH to access and open a shell on another computer, and to use it to securely transfer files. For our purposes, we will mainly be using SSH to securely upload source packages to Launchpad.
No previous SSH key
To generate an SSH key, enter:
ssh-keygen -t rsa
Accept the default file name id_rsa. For security purposes, it is highly recommended that you use a pass-phrase.
SSH key generated previously
If you already have an id_rsa SSH key that you use for some other purpose but accessing Launchpad, there are two options:
Don't generate another key, but copy the public key from the already existing id_rsa.pub when asked to upload your key to Launchpad.
Get set up to work with Launchpad
Launchpad is a system used to keep track of many aspects of open-source development. Launchpad's features include code hosting, bug tracking, translation, feature blueprints and a community-based answer tracker. This section will outline how to get setup with Launchpad to allow you to contribute the Ubuntu.
To find out more about Launchpad click here
Get a Launchpad account
The following steps will guide you through creating a Launchpad account:
Visit the Login/Register Page
- Enter your email and select "I am a new Ubuntu One user:"
- Enter your details as requested, agree to the "Terms of Service" and click "Create Account:
- Confirm your account by clicking on the link given in a confirmation email set to the email you provided
It is encouraged for you to use your real name here so that your Ubuntu developer colleagues will be able to get to know you better. You are now ready to contribute to Ubuntu through Launchpad!
Upload your SSH key to Launchpad
Open https://launchpad.net/~/+editsshkeys in a web browser, also open ~/.ssh/id_rsa.pub in a text editor. This is the public part of your SSH key, so it is safe to share it with Launchpad. Copy the contents of the file and paste them into the text box on the web page that says “Add an SSH key”. Now click “Import Public Key”. For more information on this process, visit the creating an SSH keypair page on Launchpad.
Bazaar is the tool we use to store code changes in a logical way, to exchange proposed changes and merge them, even if development is done concurrently. It is used for the new Ubuntu Distributed Development method of working with Ubuntu packages. Use bzr whoami and bzr launchpad-login to tell Bazaar who you are. For example:
bzr whoami "Bob Dobbs <firstname.lastname@example.org>" bzr launchpad-login subgenius
bzr whoami will tell Bazaar which name and email address it should use for your commit messages. With bzr launchpad-login you set your Launchpad ID. This way code that you publish in Launchpad will be associated with you. Note: If you can not remember the ID, go to https://launchpad.net/~ and see where it redirects you. The part after the “~” in the URL is your Launchpad ID.
Even if the rest of this page describes terminal commands for working with Bazaar branches, there are GUI applications available that appeal to some contributors. One such application that you may want to try is Bazaar Explorer.
sudo apt install bzr-explorer
Getting a copy of the documentation development branch
The first step you will want to take to begin working on Ubuntu Documentation is to download a copy of the development branch of Ubuntu Documentation using Bazaar:
bzr branch lp:ubuntu-docs
Now that you have a local copy of Ubuntu Documentation you will want to become familiar with the anatomy of the Ubuntu Documentation branch. Mallard files will always be found in the path
Building html version of the docs
If you wish to just build the documentation as html to review them, follow these steps with your checked out branch:
cd ubuntu-docs/html/ make
The resulting documentation will end up in ~/ubuntu-docs/html/build/en/ which you can view in your web browser. More information on building the docs.
Changing the help
Changing the help is sometimes as simple as opening the Mallard files in a command-line based text editor and reviewing them for minor changes like updating version numbers to the upcoming release number or checking for spelling and grammar. In other cases for topic-oriented pages, it may be necessary to ensure that features have not significantly changed and if they have then to update the documentation accordingly to reflect those changes.
The process of changing the help is typically as follows:
- Check your copy of the development branch is up-to-date using bzr pull.
- Change the help files.
- Check that the help files validate as proper Mallard markup code.
- When you're happy with your changes and you're ready to create a new revision, again check your copy of the development branch is up-to-date using bzr pull.
If you don't want to keep your last revision, you can cancel it using bzr uncommit. In this case if you upload a new revision to an existing personal branch you must use bzr push with the --overwrite option.
- Create a new revision using bzr commit.
- Upload your revision to a personal branch on Launchpad using bzr push.
- Propose a merge of your revision into the development branch.
- Once approved your revision will be merged into the development branch.
The rest of this section gives more details of validation, bzr commit, bzr push and the merge proposal.
To check if the Mallard synax is ok, you should make sure that the current directory is ubuntu-help/C and run this command:
As regards the bzr commands below, the current directory should be the branch root.
The bzr commit command might be as follows:
bzr commit -m 'Brief one sentence summary of change goes here'
or if there is a related launchpad bug:
bzr commit --fixes lp:123456 -m 'Brief one sentence summary of change goes here; LP: #123456'
or if there are multiple related launchpad bugs:
bzr commit --fixes lp:123456 --fixes lp:123457 --fixes lp:123458 -m 'Brief one sentence summary of changes goes here; LP: #123456 LP: #123457 LP: #123458'
The bzr push command is as follows:
bzr push lp:~<username>/ubuntu-docs/<revision-name>
You propose your changes for merging by going to the Code section of your Launchpad account, selecting the appropriate personal branch, and submitting a merge proposal ("Propose for merging"), or by running:
(This command will open your default web browser and, if you have granted Bazaar permission to interact with Launchpad, it will submit a merge proposal.)
Creating Personal Sandbox Branch
If you log in to Launchpad and click the Code link at the top of the page, it will give you a bzr push command you can use to upload your sandbox work. Change BRANCHNAME in that command to whatever you want to call the sandbox you'd like to upload.
Since uploading to your own repo is standard practice for folks who aren't part of the core committers team, under "Submit your changes for review" there can be a note after `bzr push' saying that this can be used for simply "saving" your work in your own branch prior to merging as well.
This documentation is intended to be introductory but you can learn much more about Mallard through their own tutorials. You can always ask for help on Ubuntu Documentation Team’s mailing list or on #ubuntu-doc on Freenode IRC.
We look forward to seeing your contributions to Ubuntu Documentation and answering any questions that you may have.
I think that there is too much information, to the point where it gets confusing for the user reading it. To solve this, you could 1) Split the information into new, separate pages. 2) Remove some information that is not that useful - for example in the 'Get a Launchpad account' there is a lot of info which could be reduced to just the launchpad link together with a brief sentence to go with it, as in my opinion creating a launchpad account is pretty straightforward. By doing this in some sections, you could greatly lower the amount of info, which would allow the user to understand the guide better.