Project Guidelines

Developer Workflow

Developers should follow the following workflow when working on items.

• Bug/work item is assigned to the developer via the Triage Process (see the section below)
• Project developers should do local work in a branch; external contributors should do local work in a fork.
• Please use rebase to keep the tree clean and without extra unnecessary merge operations. Pulling and rebasing frequently will help reduce the changes of merge conflicts.
• Project developers will use the internal code review system; external contributors should push their fork to the server and issue a pull request to begin the code review process.
• When the code review process is complete and change is accepted, someone from the project team will push the changes to master.
• When the code has been checked into master, then the developer should mark the item as Fixed and assign it to Unassigned.
• External contributors are encouraged to either re-use their fork, or delete it when they’re done doing work.

Creating New Issues

Please follow the following guidelines when creating new issues in the Issue Tracker:

• Specify a descriptive title that identifies the issue to be addressed or the feature request .
• Do not set any bug fields other than Impact.
• Specify a detailed description of the issue or feature request.
• For bug reports please also:
  • Describe the expected behavior and the actual behavior.
  • Attach a simple project that can be built and run to reproduce the issue.
  • Specify any relevant exception messages and stack traces.
  • Attach any relevant log or trace files.
• Subscribe to notifications for the created issue in case there are any follow up questions.

Triage Process

We’ll be using the following process to triage bugs in the issue tracker:

1. New bugs are opened with the Proposed state.
2. During triage, we’ll assign triaged bugs to a specific release (or a special vNext release for future work). Bugs that are approved will be assigned to a developer.
3. When developers pick a bug to work on, they should change the status to Active when you start working on it.
4. When the fix for the bug is committed to master, the developer changes the status to Fixed and assigns it to Unassigned.
5. Once the bug is verified by someone else (typically the opener of the bug and/or a member of the QA team), it will get marked as Closed.

We will run regular triage meetings with the project team. If there is a bug you feel strongly about and want to work on it but it hasn’t yet been triaged, please post a message in the forums.