Development guidelines

From World Wind Wiki

Jump to: navigation, search


[edit] Code policy

  • Every public function/method must be documented using XML Comments. The documentation should contain:
    • Input parameters, including acceptable value ranges if non-obvious
    • Output values, if any
    • Exceptions thrown, if any
    • Description of what the function does, including side effects ("also increments current frame number by one")
    • Name of original author (jira username and/or email address)
  • Please also read the MSDN guidelines

[edit] SVN policy

[edit] Applying for SVN commit access

  • If you only intend to make a few commits you should post your code on the forums and ask for someone to commit it for you.
  • If you intend to be an active contributor contact with reasons why you need access, your coding experience, and preferably the first piece of code you want to commit.

[edit] Notes on committing to SVN

  • Every commit must have one corresponding JIRA issue. This issue code must be the first item in your commit message, followed by a colon. For example, a typical commit message looks like this: WW-778: Improved rendering performance with hardware vertex buffers. See also: New checkins policy: Creating JIRA issues for checkins from [Worldwind-dev] mailing list.
    • Do not bundle up several issue codes in one commit; make a separate commit for each issue. This allows better tracking of what actually changed in response to each issue.
    • Do not bundle up several bugs/features in one JIRA issue to avoid the rule above.
  • Check that your commit does not break SVN, i.e. World Wind still builds. This is especially important if you also have other, uncommitted changes. If you repeatedly break SVN your commit privileges will be revoked.
    • If you add a new file, be sure to also commit the updated .csproj file for the particular sub-project, and any necessary .resx files.

[edit] Jira policy

  • If you see an unassigned issue you wish to take on you can freely assign it to yourself.
  • If you see an assigned issue you wish to take on or help with contact the current assignee or email Never assume an issue has been abandoned.
  • Issues with more votes should be prioritised. If you have several issues assigned to you fix the ones with most votes first, or unassign those issues and let someone else fix them.
  • If you believe you have fixed an issue, mark it as resolved, and ask for someone else to verify your fix, they should then select fixed or comment on your issue if there are still problems.
Personal tools