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...
- Talk to the AUI team first - this avoids duplication of effort, clashes, etc.
- 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.
- 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.
- Your changes must work across all supported browsers and where your changes can be unit- or integration-tested you should add or update tests.
- All changes are handed via Pull Request - see Committing code to AUI
- 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