Versions Compared

Old Version 3

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 4

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Use JIRA to track your changes
    • Ensure there is an issue describing the fix/improvement/feature in JIRA (If this is a minor typo fix, or an obvious bug, you need not add a JIRA issue – use your judgment on whether this fix is worth tracking in JIRA or not)
  2. Share your code before committing
    • If this is a more significant fix/redesign, you may want to use the SVN sandbox to manage your code (rather than dealing with large patches, etc). You also may want to document your work on the Wiki, and link both of these back to the JIRA issue.
    • If this is a smaller bug fix/change, you could just work on your code locally and generate a patch to attach to the JIRA issue
  3. Code "approval" processes
    • General Rule of Thumb: Committers are trusted developers. Use your best judgment on whether or not you feel a particular piece of code should be approved before committing. The below guidelines are just suggestions and they may not apply to all scenarios:
    • If this is a small, obvious fix (typo/improved comments/obvious bug), just commit it immediately. This is the exception to all other rules – there's no reason to add a JIRA issue for every typo or obvious fix, and no reason to wait around for approval to commit it. (smile)
    • If this is a bug/issue fix, we generally try to run it by one other committer. If there is any doubt, feel free to run it by others or ask to have it added to the agenda of the next developers meeting.
    • If this is a new feature, we generally try to run it by a few committers (or bring it up in a developer meeting, if it's a larger change). The only reason we suggest to run it by more than one committer is that oftentimes others may be able to provide additional suggestions or configurations that may be worth investigating.
  4. Document your code early & often
    • New features/improvements need to come with documentation, otherwise we won't be able to accept them. Keep this in mind while you are developing, and use the Wiki or JIRA to start your documentation early on (it'll make it easier on you in the long run)

...