-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Contribution Standards
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.
Please review YUI’s Developer Workflow for details on how to set up your Git branches and contribute changes to the YUI project.
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.
We recommend the following process for contributing great code to YUI:
- 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
- API docs
- Examples
- User guides
- Unit
- Functional
- Performance
Please read: https://github.com/yui/yui-lint/blob/master/README.md
We reserve the right to one day fail builds on lint errors.
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.
All source code changes should be merged to the dev-master and dev-3.x development branches by Code Freeze, including new features, new APIs, deprecations, and bug fixes. This is in order to ensure enough time for thorough testing across all our target environments and community feedback before release.
During the time between Code Freeze and Commit Freeze, only documentation and test updates are acceptable, as well as fixes to any bugs that are explicitly identified as release blockers.
No repo changes of any kind are permitted after Commit Freeze to the dev-master and dev-3.x development branches without explicit discussion and approval. This is to prevent churn in our CI system that delays releases. Please make sure all code changes and test, documentation, and HISTORY.md updates happen before Commit Freeze. Development branches will be unfrozen after the release and deployment is complete. In a normal cycle, we expect Commit Freeze to last from EOD Friday to Tuesday, or about 3.5 days.
Coming soon.
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.
Any submission that uses open source code from another project must be explicitly called out and is subject to review.
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