Changes between Version 2 and Version 3 of Development_Workflow


Ignore:
Timestamp:
Sep 1, 2017, 2:40:27 PM (7 years ago)
Author:
Kevin Reed
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Development_Workflow

    v2 v3  
     1= Development Workflow  =
    12The purpose of a development workflow is to make sure that the BOINC platform produces high quality code that solves the problems of its users. As such, the development workflow needs to have checkpoints to allow for the review and discussion of the following questions:
    23
    … …  
    1213Code changes should be created because somebody has a problem that cannot be solved with the current version of this software. This could be because the software is doing something wrong (a bug report) or this could be because the software does not yet do something that somebody needs it to do (feature request).
    1314
    14 These changes are documented using [https://github.com/BOINC/boinc/issues issues] on github. A good issue will clearly define the problem that needs to be solved and how the software is not currently solving that problem. In the case of a bug report, this will include instructions on how to reproduce the issue. In the case of a feature request, it will detail the capabilities that are required in order to solve the stated problem.
     15These changes are documented using [https://github.com/BOINC/boinc/issues issues] on github. A good issue will clearly define the problem that needs to be solved and how the software is not currently solving that problem. In the case of a bug report, this will include instructions on how to reproduce the issue. In the case of a feature request, it will detail the capabilities that are required in order to solve the stated problem.
    1516
    1617A design may or may not be needed for the proposed change. If you are not sure of your approach, or if the change is medium to large sized--especially if it changes the behavior of the application--then you should do a design so that it can be reviewed when it is still easy to make changes. If you proceed without doing a design, you run the risk of having to re-do significant portions of your change should your approach or design be rejected during code review.
    … …  
    3940
    4041= 2. Implementation = #DevelopmentWorkflowv2-2.Implementation
    41 All development is done using feature branches. Review [https://guides.github.com/introduction/flow/ GitHub Flow]. BOINC uses the [https://gist.github.com/Chaser324/ce0505fbed06b947d962 Fork and Pull Model] for development (background on this approach can be [https://help.github.com/categories/collaborating-with-issues-and-pull-requests/ read here]). Once you have created your fork, set it up locally, and created a feature branch, you can begin coding. When you are finished with development you can create a pull request for review.
     42All development is done using feature branches. Review [https://guides.github.com/introduction/flow/ GitHub Flow]. BOINC uses the [https://gist.github.com/Chaser324/ce0505fbed06b947d962 Fork and Pull Model] for development (background on this approach can be [https://help.github.com/categories/collaborating-with-issues-and-pull-requests/ read here]). Once you have created your fork, set it up locally, and created a feature branch, you can begin coding. When you are finished with development you can create a pull request for review.
    4243
    43 Make sure to review the [wiki:Definition_of_Done_for_Feature_Branches] before starting work so that you are familiar with the expectations of your work.
     44Make sure to review the [wiki:Definition_of_Done_for_Feature_Branches] before starting work so that you are familiar with the expectations of your work.
    4445
    4546If you wish to get some early feedback on your changes, then you can create a pull request with the text [WIP] at the start of the title. This indicates to reviewers that you are inviting others to look at your code, but that it should not be merged. Once you are ready for final review and merge into master, then you can remove the [WIP] prefix.
    … …  
    4849
    4950== 2.1 Code Review == #DevelopmentWorkflowv2-2.1CodeReview
    50 Once a pull request has been created for the implementation of an issue, anyone can review and comment on the changes. Committers need to follow consensus voting and determine if the code change is accepted. Committers should use the [wiki:Expectations_of_Code_Review]''' '''as a guide to conducting the review.
     51Once a pull request has been created for the implementation of an issue, anyone can review and comment on the changes. Committers need to follow consensus voting and determine if the code change is accepted. Committers should use the [wiki:Expectations_of_Code_Review]''' '''as a guide to conducting the review.