Project Guidelines (original) (raw)

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 next section) or developer assigns the bug to him/herself and marks it as active.
• 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
• 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

Triage Process

We'll be using the following process to triage items in the issue tracker:

1. New issues are opened in the Unassigned milestone.
2. Members of the EF Team meet regularly to triage new issues. During this meeting we will assign the appropriate metadata for each issue. One of the following actions will be taken for each issue:

• The issue is allocated to a specific milestone to be fixed/implemented. The issue may also be assigned to a specific developer at this stage, or left unassigned until it is decided who will implement the change.
  In most cases this is not a firm commitment that the issue will be fixed in that release. It is rather an indication that we intend to work on it for that release, but factors such as schedule and unanticipated complications could still cause the issue to be later moved into a future release.
• The issue is allocated to the Backlog milestone. This release is used to track issues that we agree should be implemented but do not fit into a specific release at this stage. They will be reconsidered for future releases.
  This does not exclude someone from outside the EF team contributing a change to address the issue in the current release.
• If we are unable to make an informed decision based on the information in the issue, it is tagged with the type-investigation tag and assigned to a developer for further investigation. Once the developer has completed the investigation they will include notes of their findings and move the issue back to the Unassigned release to be re-triaged.
• If the issue is a duplicate of an existing issue, an incorrectly filed bug, or something else that we don’t think should be implemented we will mark the issue as Closed.

1. When a developer starts working on a issue, they should:

• If they are a member of the EF Team - Assign it to themselves (if it isn't already assigned to them) and change the status to Active.
• If they are NOT a member of the EF Team - Follow the steps on the contributing page.

1. When the changeset that resolves the issue is checked in and we are happy with the test coverage, the issue will be closed.