Skip to end of metadata
Go to start of metadata
Icon

Note: this information is for people who want to work on AUI itself. If you simply want to use AUI, refer to the Developer Documentation.

The short, short version

  • Don't break the API
  • All commits must include an issue key
  • Write and run tests before submitting a pull request
  • Write docs or nobody will use your feature

The short version

The shortest version is that AUI accepts Pull Requests, with a surrounding process to avoid code explosions and duplication/waste of effort. We gladly accept contributions but for some reason multiple people tend to have the same idea at the same time...

  1. Talk to the AUI team first - this avoids duplication of effort, clashes, etc.
    1. All changes must be backwards-compatible unless agreed with the AUI team and product stakeholders; and all non-backwards-compatible changes must wait for a major version of AUI.
  2. Follow the tracking rules - they are required for cross-product visibility and will avoid your change being rejected:
    • all commits must have an associated AUI issue (include this in the commit comment)
    • all commits must be reviewed, usually in Crucible for big changes (as this is a cross-product review, allow at least a week for anything other than blocker issues)
    • the issue must not be closed until the code review is completed, pull request accepted into master, and changes are documented.
  3. Your changes must work across all supported browsers and where your changes can be unit- or integration-tested you should add or update tests.
  4. Tests:
    1. If you add new cases, add new tests. Depending on the change this can be a visual, unit or integration test. But it has to be testable.
    2. You must have the tests passing locally before you submit the Pull Request. If your changes break the builds later on, people will Look Gruff At You.
  5. All changes are handed via Pull Request - see Committing code to AUI
  6. All changes and new features must be documented. If it's not documented it doesn't exist.
    • For unreleased components write a new component page and restrict access until time of release.
    • For unreleased changes to existing components, add documentation to the relevant release notes and it will be migrated to public pages on release.
    • If all else fails - write up the contents of your documentation and add that to the issue. The main thing is to write the docs.

Note: it is assumed that you have already set up your dev environment.

This really is the short version. Welcome to cross-product development (smile)

The details

  • No labels