Skip to content

Latest commit

 

History

History
63 lines (43 loc) · 3.8 KB

CONTRIBUTING.md

File metadata and controls

63 lines (43 loc) · 3.8 KB
Raw

Curious to start contributing to Brackets?

With this file we want to provide some general guidance how to contribute to Brackets - your feedback is very welcome. Please provide it here.

Issues starting Brackets the first time? Please review the Troubleshooting Page.

Getting Started

Before you start coding, post to the brackets-dev Google group or the #brackets IRC channel on freenode about what you're thinking of working on, so you can get early feedback. This also provides you with an opportunity to find out what others including the core team are working on.

Brackets is developed using Agile development methodologies, features are tracked as user stories on the public Brackets backlog. You may vote on existing stories or find stories to work on with others.

  1. Please sign the Brackets Contributor License Agreement. You must agree to and submit this before you can contribute to Brackets.

  2. To get started, please see the following wiki page on GitHub: https://github.com/adobe/brackets/wiki/How-to-Hack-on-Brackets.

  3. When coding, make sure to follow our coding conventions.

  4. Please collaborate with others in providing and receiving guidance, the Brackets team made it a priority to look at pull requests daily, however depending on the feature priority, the complexity of a contribution and bandwidth we may not be able to work on it right away.

Making Changes

Before submitting any pull request, make sure to:

  1. merge from adobe/brackets master
  2. re-test your code after the merge
  3. run the unit tests with Debug > Run Tests -- everything should pass
  4. if your change is nontrivial or might have affected the UI, run through the Brackets smoke tests and possibly the Brackets server smoke tests.

###Proposed Pull Request checklist

  • Does this change belong in core? Some features would be better as an extension - could it be done as an extension by separating out a more limited set of core changes (e.g. more generic APIs)?
  • Some pull requests require the core team to implement additional supporting code in order to work. These pull requests may be delayed until the core team has time to do that work.
  • Any major architectural or UI changes have been discussed in the forum?
  • All new APIs are documented in the [Release Notes] (https://github.com/adobe/brackets/wiki/Release-Notes)?
  • Code follows our JS coding style guidelines (we probably need to clean those up)
  • Code passes JSLint
  • Code is syntactically valid (Brackets launches & no exceptions in the console)
  • Testing
    • Code has been tested -- describe the cases that were tested
    • All unit tests pass
    • No known bugs
    • Smoke tests have been run (ideally)
    • Unit tests for all new functionality (Is that too extreme? We’ve almost never gotten that so far…)
  • All UI strings externalized (we should have a how-to page for this).
  • If there are string changes, it can't land at the very end of the sprint
  • Native: should compile
  • Native: Mac AND Win implementations
  • UI is reasonably polished ?

###Avoid Common pitfalls (make sure these have been thought about):

  • Text manipulation commands: should consider what happens when in an inline editor at boundaries
  • Inline editors: does this collide with any other providers?
  • Code hinting: does this collide with any other providers?

##Additional Resources