In the Ubuntu world we have some common values that are not just focused on freedom, but also in how we build Ubuntu. Values such as *cadence*, *design*, *quality* and *precision* help guide us in building the best Ubuntu that we can.
These values continued to be common themes at the recent Ubuntu Developer Summit in California. Today our culture continues to involve important integration work that is a rich and interesting challenge, but this work has also been augmented by us building *assurances* around Ubuntu too; assurances such as regular releases (*cadence*), the reliability and quality of the experience (*quality*), and attention to detail in both design and engineering (*precision*) are all examples of the strong balance of predictability and innovation that we want to bring.
These values are not limited to Ubuntu though: we want Ubuntu to be a platform where you can get the very best software experience, whether you are using Open Source or commercial applications. In a nutshell, we want to take the lessons we have been learning regarding *cadence, design, quality* and *precision* and share them with our upstreams. This is going to be a big chunk of what Michael Hall will be focusing on in the coming months.
One upstream project though that I am actively involved in in my spare time is [Ubuntu Accomplishments](https://wiki.ubuntu.com/Accomplishments) and I wanted to share some of our plans surrounding our next 0.2 release and how these values are forming an important core of this work. Before I continue though, I just want to say a huge *thank-you* to everyone who has been participating in Ubuntu Accomplishments. Ever since our 0.1 release a few weeks ago we have had over 180 people start using this very early PPA and a number of people have started contributing accomplishments. Thanks to all of you!
## Quality
With the expanded number of accomplishments being contributed, I started thinking last week about how we could perform better testing around these contributions as well as daily testing reports; I wanted to ensure that our project, even though we are very young and small, demonstrates a level of *quality* that we can be proud of. To kick this off, this weekend I wrote a small tool called *battery* that helps us assure quality. I created a validation test for every accomplishment and *battery* runs all the accomplishments and feeds them this data that will cause an accomplishment to succeed as well as fail. This serves a few valuable purposes:
* We now have better testing for new contributions and we can test both success and failure more effectively.
* We can build testing into the accomplishment submission process so that when someone contributes an accomplishment we will ask them to also submit a test file (the test file is extremely simple and just specifies data used for success and data used for failure). This should take a contributor ten seconds to put together.
* Finally, we can now run *battery* in an automated environment every day and have it alert us when one of the tests fails. This gives us better visibility on our accomplishments collections to ensure that we can *assure quality* and resolve issues quickly.
As an important part of building good design into the system, *battery* was designed to not require any changes to the existing accomplishments sets and require a *bare minimum* from our contributors who should be spending more time having fun writing accomplishments than caring about tests. I am delighted with the results.
## The Road To 0.2
In addition to helping to ensure the accomplishment contribution process is simple (see our [list of ideas for accomplishments](https://wiki.ubuntu.com/Accomplishments/Trophies) and [how to create them](https://wiki.ubuntu.com/Accomplishments/Creating)), we have been planning the 0.2 release. This will continue to focus on refinements and building a strong, reliable platform for both community and local accomplishments.
We will be focusing on the following in the 0.2 cycle:
* **Local Accomplishment Support** – in 0.1 we focused our efforts primarily on community accomplishments (that is, accomplishments that need to be verified). Although we have always supported local accomplishments (these are accomplishments on your computer such as installing a package for the first time or sending your first email), this local support was a little broken in 0.1. I have already landed a branch from Rafal that fixes these bugs, using GNOME Mines as the test application. We will continue to refine this support.
* **Daemon and API Refinements** – this won’t be visible to the user but we are planning a [raft of API improvements](https://wiki.ubuntu.com/Accomplishments/NewAPI) to ensure that the back-end daemon is *precise* and high quality. This requires some functional changes, API naming conventions, standardizing on accomplishment IDs and other improvements.
* **Growing Ubuntu Community Accomplishments** – we plan on continuing to grow and expand the Ubuntu Community Accomplishments collection. We need help though, and that help could come from you! If you know a little Python and want to help our community, be sure to let me know! You can also join our IRC channel at `#ubuntu-accomplishments`.
* **Introducing Ubuntu Desktop Accomplishments** – we plan on introducing our first set of desktop accomplishments that can be used with the local accomplishments feature in the system. This will help us to start mapping out an awesome journey for how ours users use the desktop, discover things to do, and more!
It was wonderful to see the excitement and interest around Ubuntu Accomplishments at UDS, and I am excited to see where the project can take us. If you want to join us, be sure to [join the mailing list](https://launchpad.net/~ubuntu-accomplishments-contributors) and/or join us on IRC on freenode in `#ubuntu-accomplishments`.
