Skip to content
Iryna Cherniavska edited this page Nov 11, 2015 · 3 revisions

Conduct

Be courteous - A lot of people write in from countries that don't speak English, so their requests might sound abrupt or borderline offensive. Assume positive intent and ask for clarifications or rephrase their request in your own words to avoid miscommunications.

But if they're being abusive or obnoxious don't be afraid to shut them down politely.

Be realistic - If a feature is too hard or if it is not a good fit for the project, be upfront about it and let them know. There is no point in stringing them along.

Philosophy

Sane defaults - The app should have sane defaults out of the box. Sane defaults is a subjective term, use your best judgement.

Configuration is evil - I hate having too many config options. We should strive to minimize the number of config options and stick to good default behavior.

Proactive UX - The user experience should be pleasant. The program should be proactive in helping the user (eg: auto-completion).

Development Process

  • Work on branches for feature or bug fixes in the main repo.
  • Good practice is to prefix new branch name with your github login (my-username/my-branch-name).
  • Open a PR when the branch is ready. Tag a fellow core dev as a reviewer.

Review Process

  • Review the code changes.
  • Checkout the branch locally and run it using the changes to check the feature/bug fix.
  • Merge the PR if you're satisfied.

Issues

  • Don't close an issue when a fix lands in master. Only close it when the fix is available in a released version.
  • Github will close an issue that was referenced in a merged commit automatically. Don't worry about it. Let Github do it.
Clone this wiki locally