Development

Differences between revisions 4 and 11 (spanning 7 versions)
⇤ ← Revision 4 as of 2011-01-10 17:06:31 →
Size: 1761
Editor: 63
Comment:
← Revision 11 as of 2012-06-14 19:42:47 → ⇥
Size: 1509
Editor: c-67-170-185-42
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
<<TableOfContents>> == Contributing ==
Line 3: Line 3:
The uTouch framework and related projects are open source. If you would like to contribute, you need to do the following:
 * [[http://launchpad.net|get a Launchpad id]]
 * [[http://ubuntuforums.org/showthread.php?t=105280|sign the Ubuntu Code of Conduct]]
 * sign Canonical's [[http://www.canonical.com/contributors|contributor agreement]]
 * read and adhere to our [[../DevelopersGuideToTheGalaxy|Developer's Guide to the Galaxy]]
 * abide by the coding styles and best practices of the related upstream projects
 * [[https://bugs.launchpad.net/canonical-multitouch|pick some tickets]] or [[https://bugs.launchpad.net/canonical-multitouch/+filebug|file your own]]
 * start hacking!		 The gesture framework and related projects are open source. If you would like to contribute, you need to do the following:
 1. [[http://launchpad.net|get a Launchpad id]]
 1. [[http://ubuntuforums.org/showthread.php?t=105280|sign the Ubuntu Code of Conduct]]
 1. sign Canonical's [[http://www.canonical.com/contributors|contributor agreement]]
 1. abide by the coding styles and best practices of the related upstream projects
 1. [[https://bugs.launchpad.net/~utouch-bugs|pick some tickets]]
 1. start hacking!

== Contribution Review Policy ==
All non-trivial branches need a code review.

Examples of trivial branches:

 * Translation updates
 * Release changes (e.g. version bump)

Examples of non-trivial branches:

 * Normal bug fixes
 * Features
 * Refactors

=== Review Flow ===

 1. Develop a contribution as a bzr branch
 1. Push it to the relevant project space on Launchpad.net (e.g. lp:~<your username>/ginn/my-new-feature)
 1. Propose merging the branch into the project trunk
 1. A separate member of the gesture team will review the branch
 1. Once approved by any member of the gesture team, anyone may merge the branch into trunk
Line 14: Line 35:
 * [[Multitouch/Definitions]] - A glossary of terms we use when discussing uTouch technology, both at the user-experience and engineering levels
 * [[/PPAUploads|Preparing for a PPA]] - How to get a project prepared for and uploaded to a PPA		  * [[Multitouch/Definitions]] - A glossary of terms we use when discussing gesture technology, both at the user-experience and engineering levels
Line 17: Line 37:
== Blueprints and Specs == == Specs ==
Line 19: Line 39:
 * [[https://blueprints.launchpad.net/ubuntu?searchtext=hci-|HCI/MT-related plans for Ubuntu]]
 * [[https://blueprints.launchpad.net/canonical-multitouch|Canonical Multi-touch project planning]]
Line 23: Line 41:

== APIs ==

 * [[http://people.canonical.com/~cndougla/geis-1.0/index.html| The GEIS 1.0 API ]]

== Areas of Interest ==

 * [[Multitouch/Dev/HCI]] - Human-Computer Interaction: it's not just touch! What does the future look like? What would we like to see?
 * [[Multitouch/Dev/Gestures]] - Continued work on defining gestures for uTouch
 * [[Multitouch/XDevelopment]] - XInput 2.1 spec implementation work for Natty

Contributing

The gesture framework and related projects are open source. If you would like to contribute, you need to do the following:

  1. get a Launchpad id

  2. sign the Ubuntu Code of Conduct

  3. sign Canonical's contributor agreement

  4. abide by the coding styles and best practices of the related upstream projects

  5. pick some tickets

  6. start hacking!

Contribution Review Policy

All non-trivial branches need a code review.

Examples of trivial branches:

  • Translation updates
  • Release changes (e.g. version bump)

Examples of non-trivial branches:

  • Normal bug fixes
  • Features
  • Refactors

Review Flow

  1. Develop a contribution as a bzr branch

  2. Push it to the relevant project space on Launchpad.net (e.g. lp:~<your username>/ginn/my-new-feature)

  3. Propose merging the branch into the project trunk
  4. A separate member of the gesture team will review the branch
  5. Once approved by any member of the gesture team, anyone may merge the branch into trunk

Reference Materials

  • Multitouch/Definitions - A glossary of terms we use when discussing gesture technology, both at the user-experience and engineering levels

Specs

Multitouch/Development (last edited 2012-06-14 19:42:47 by c-67-170-185-42)