-
Notifications
You must be signed in to change notification settings - Fork 16
Post beta Commit Guidelines
Now that Blossom is in beta, changes to the master branch will be done through pull requests for all but the most trivial of changes.
To make a change in Blossom, please:
-
Fork the respository.
-
Make the changes on your own fork. Changes should be logically related (don't include whitespace changes in one file and an unrelated code change in another).
-
Submit a pull request that looks like this:
Review: Updated SC.Request to correctly handle proxies on Node.js
-
The request will be reviewed for the following:
- correctness
- whitespace
- naming conventions
- overall fitness with the framework
- if needed, unit tests
- performance
If you've followed how new code is handled in WebKit, you'll have an idea of what a review looks like.
Once a pull request has been reviewed, the reviewer will do an "LGTM" (which stands for "looks good to me"). At this point, the pull request is ready to be merged with Blossom.
Performance is a very important part of Blossom. Blossom already contains some internal benchmarking and I expect that to improve over time. Eventually, all changes will need to have the performance tests run. The goal is to always make Blossom faster. If features are being added, which as a general rule, tend to slow things down, a separate, performance enhancement will need to be done to balance everything out. I strongly believe that performance has to be architected into the framework, and maintained and/or actively improved or it tends to disappear. The goal is to manage Blossom going forward in a predictable, professional manner that favors clean code.