Changes between Initial Version and Version 1 of Ticket #1948, comment 4
- Timestamp:
- 2017-12-11T17:00:46+01:00 (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1948, comment 4
initial v1 3 3 Over time, the development workflow would become something close to the following: 4 4 5 1. The developer will push his changes to the repository with the new syntax for the commit message, ` [see #1948]` as example.5 1. The developer will push his changes to the repository with the new syntax for the commit message, `see #1948` as example. 6 6 2. Thanks to this, the commit will create a new comment in the ticket with the commit message and display the status of the review as 'Pending' for default. 7 7 3. The developer contacts the reviewer(s), the assignment of the ticket could be a clever method to do this. 8 8 4. The reviewer(s) put his review directly in the changeset page of the commit (see bottom of page), there is a textarea for comments and dropdown menu for status ('Pending' | 'Failed' | 'Passed') 9 5. The review submitted will become a new comment in the ticket and the ` code_review` custom field will be updated appropriately regarding the review status.9 5. The review submitted will become a new comment in the ticket and the `branch_review` custom field will be updated appropriately regarding the review status. 10 10 11 The review can be modified and the developer can link as much commits as he wants to a development ticket but by design there will be only one status for ` code_review` custom field.11 The review can be modified and the developer can link as much commits as he wants to a development ticket but by design there will be only one status for `branch_review` custom field.
