We are in Gitter and Slack every day, come join us
Our work affects not only our direct users, but their users as well. To some extent, our code impacts users across multiple functions in their organization. As contributors we need to take responsibility to ensure our impact is positive.
We're willing go to great pains to ensure the accessibility of our code to users and other contributors. A healthy codebase is easy to contribute to, because it's easy to understand. It lends itself to debugging, invites reading, and simplifies auditing.
Anvil Connect is a highly collaborative project. We welcome all questions and input, regardless of your area of interest. Here's our thoughts on contribution:
- Make it readable
- Be explicit before you are clever
- Engineering = quality
- Interoperability is key - play well with others
- Be agile, flexible and consistent
You are welcome to open issues relating directly to the development of Anvil Connect. Discussion of docs and philosophical chat should be posted to [Anvil Research Connect Docs] (https://github.com/anvilresearch/connect-docs).
- Check open issues before you open a new one to avoid duplicate work
- When you're working on something, if it's not a substantial addition, file an issue and let us know
We welcome code contributions and participation in bug fixes and issues.
-
New features
- check first to make sure you aren't duplicating work
- before you submit we'll have a code review hangout
- consider pairing with a core team member
-
All contributions
- Make small commits and pull requests
- Separate features and improvements
- Verify that dependencies are listed in manifest
- Features must include test coverage and code review to be accepted
We follow Javascript Standard Style.
- Indents are 2 spaces; no tab characters (unless required by the language).
Not OK OK <html> <head></head> <body> <div>Hello world</div> </body> </html>
<html> <head></head> <body> <div>Hello world</div> </body> </html>
-
Non-binary files must end with a new-line character.
Not OK OK -
No trailing whitespace (unless required by the language).
Not OK OK -
Avoid excess whitespace around code.
- **No more than one empty line at a time.**Not OK OK identifier( param, param )
identifier(param, param)
prop: value prop1: value prop1a: value
prop: value prop1: value prop1a: value
Not OK OK /* Special Classes */ .fancy { ... } .jumbotron { ... } /* Other Classes */ .floaty-boaty { ... }
/* Special Classes */ .fancy { ... } .jumbotron { ... } /* Other Classes */ .floaty-boaty { ... }
- Fork the project on Github and check out your copy locally.
- For new features and bug fixes, use the master branch.
- Create a branch and hack away!
-
When you commit make sure you include your name and address.
$ git config --global user.name "I. CanCode" $ git config --global user.email "icancode@example.com"
-
Be sure and include a commit log, including a title and relevant changes.
- We use [Javascript Standard Style] (https://github.com/feross/standard) to keep the code standardized
-
Select your feature branch. Click the 'Pull Request' button and fill out the form.
-
Pull requests are usually reviewed right away.
- If there are comments to address, apply your changes in a separate commit and push that to your branch.
- Post a comment in the pull request afterwards; GitHub does not send out notifications when you add commits.
- Fork the project on Github and check out your copy locally.
-