Skip to content

Contribution Standards

Jump to bottom
jenny edited this page Jan 25, 2013 · 33 revisions

Propose a Submission

Thank you for your interest in contributing to the YUI project! Before we get started, please be sure to sign a CLA.

Proposals can be submitted via a pull request or as an idea to the Contributor Mailing List. Submissions that follow our contribution standards and are aligned with the direction of the project will be accepted. Submissions that are not accepted can always be published to YUI Gallery.

Please review YUI’s Contributor Model for more information about how proposals get processed once submitted.

Development Workflow

Please review YUI’s Developer Workflow for details on how to set up your Git branches and contribute changes to the YUI project.

Minimum Requirements

The goal of these requirements is to ensure quality, API consistency, code reusability, and maintainability of the contribution. All contributions must satisfy:

  • Complete API Docs and inline code comments
  • Unit tests with 80% line coverage
  • User Guide (Components only)
  • Functional examples, written up in Selleck format and with test automation (https://github.com/yui/yui3/wiki/Selleck-Example-Tests)
  • Proper commit logs
  • Proper updates to HISTORY.md

The YUI team has created a number of Node.js-based NPM modules to make meeting the above requirements much easier:

  • shifter: to build the modules properly and consistently.
  • yuidocjs: for live-previewing the API docs.
  • selleck: for live-previewing the user guide and functional examples.
  • yogi: helper tool wrapping up the functionality from the above tools.

Further Recommendations

We recommend the following process for contributing great code to YUI:

Get feedback early and often

  • An API review validates your initial approach
  • A design review validates your high-level architecture
  • A code review validates your implementation details
  • A Preview Release gets you community feedback of working code in real-world situations

Documentation is just as important as code

  • API docs
  • Examples
  • User guides

Automate your tests

  • Unit
  • Functional
  • Performance

A Note About Lint

Please read: https://github.com/yui/yui-lint/blob/master/README.md

We reserve the right to one day fail builds on lint errors.

Important Milestones

Pull Request Milestones

Per our Contributor Model, pull requests require a 72-hour window for feedback. Please submit your pull request with enough time for this window, if you are trying to meet one of the milestones described below.

Feature Complete

All big ticket items should be merged in by Feature Complete. This is in order to ensure enough time for testing and community feedback before release. Big ticket items include new features, new APIs, large code changes, deprecations, and upstream changes that may impact other code.

Code Freeze

No code changes of any kind are permitted after code freeze without explicit discussion and approval. This is to prevent churn that delays releases. Please make sure all bug fixes, test updates, documentation, and HISTORY.md updates happen before code freeze.

The time between the Feature Complete milestone and the Code Freeze milestone is meant for late-breaking bug fixes of a smaller nature that come out of community feedback and testing.

Preview Releases

Coming soon.

Release Process

At the end of Code Freeze Friday (11:59 PM in Sunnyvale), all branches will be frozen so we can make the determination on whether to cut a release off master branch (a 3.CURRENT.NEXT release) or 3.x branch (a 3.NEXT release).

If 3.x branch looks good, the 3.NEXT release will be cut the following Tuesday, and then all branches will be unfrozen.

If 3.x branch is not good, a 3.CURRENT.NEXT release will be cut the following Tuesday, and then only master and dev-master branches will be unfrozen. The 3.x and dev-3.x branch will remain frozen and only accept commits that get it out of "not good" status. Merges from dev-master into dev-3.x are not allowed during this time.

As soon as 3.x branch turns good, a 3.NEXT PR release will be cut and then the 3.x and dev-3.x branches will unfrozen. dev-master will be merged into dev-3.x as soon as it is unfrozen.

Parallel development against dev-master and dev-3.x will continue until the end of the next sprint. At the end of Code Freeze Friday of the next sprint, once again all branches will be frozen and the release cycle starts again.

Coming soon.

License Updates

Any submission that uses open source code from another project must be explicitly called out and is subject to review.

Right to Revert

Once the contribution has been merged into the repo, if any issues arise in the integration environment or upon subsequent feedback, the contribution may be reverted.

2

Clone this wiki locally