Development workflow v1-updated

doc/core_testing_workflow.md

@@ -0,0 +1,27 @@
+# Testing pull requests in Open Bounty
+
+All new functionality and features both are being delivered by pull requests (hereinafter PRs).
+How to test PR? Steps below could help a bit!
+
+### Prerequisites
+Requirements for PRs to be tested:
+* should be in `To test` column in `Pipeline For Pull Requests` project
+* shouldn't have conflicts with `develop` branch
+* should have a successful build in Jenkins [status-openbounty-app](https://jenkins.status.im/job/status-openbounty/job/status-openbounty-app/view/change-requests/)
+
+
+### Deployment
+In order to deploy feature to [testing env](https://testing.openbounty.status.im/) you should **rebuild** PR you are about to test.  
+
+Only one PR can be deployed on [testing env](https://testing.openbounty.status.im/)
+
+Fresh develop branch with last changes is deployed automatically on [staging env](https://openbounty.status.im:444) 
+
+### Testing
+1)  Move appropriate PR card to IN TESTING on the [Board](https://github.com/status-im/open-bounty/projects/3) and let people know you are on it - assign it to yourself! :)
+2)  Сheck the functionality current PR fixes / delivers (positive/negative tests related to the feature). In curtain cases it's worth to look in 'Files changed' tab in GitHub to check the list of what was changed to get understanding of the test coverage or "weak" places that have to be covered. Ask PR-author in #openbounty channel in slack what was changed if it's not clear from the notes in PR.
+3)  Check reasonable regression using [SOB-general test suite](https://ethstatus.testrail.net/index.php?/suites/view/27&group_by=cases:section_id&group_order=asc)
+4)  No issues? Perfect! Put appropriate label to the PR (`Tested - OK`), merge it to develop and move the PR instance to `Merged to develop`. 
+5)  Found issues? Check for duplicates before adding one. Hint: make sure the issue is really introduced by current PR - check latest `develop` branch on [staging env](https://openbounty.status.im:444) . Issue exists in develop? Check existing issues list and make sure you are not adding duplicates before creating your own bug :)  **All PR-specific issues should be added as comments to tested PR.** 
+Once all issues are logged put label `Tested-issues` to the PR and notify developer that there are several problems that are preventing the PR to merge. Move the PR to `Reviewing, waiting for contributor` on the board if PR is developed by external contributor, and to `Developing` - if it is presented by core contributor.
+

doc/development_workflow.md

@@ -4,31 +4,40 @@ We have a continuously deployed version tracking the `develop` branch live at [t
  
 Any help is greatly appreciated!
 Currently we use two projects -  `Pipeline For Issues` and `Pipeline For Pull Requests`, issues and pull requests in our repository are passing through all or several stages described below.
+Whole team is responsible to keep the projects with accurate information.
+
+**If issue or pull request marked with `Blocked` label, it means that it is blocked on some stage, reason of blocking have to be in comment.** 
 
 ## Pipeline For Issues
 
-Issues are added to this project by product owner.
+Team is working only on issues that included in this project.
+Issues can be added to this project by any core team member.
 
 #### To define
 This is backlog for all features/issues/enhancements which we want to include to development process. 
 
 All issues here should be marked with:
-* type - `bug`, `tech-debt`,` enhancement`, `proposal` labels
-* priority - `Prio: high`, `Prio: med`, `Prio: low` labels
-
-#### In Bounty
-The store with issues which are open bounties. When we put funds to issue and it shows up in [status open bounty](https://openbounty.status.im), we move issue here.
+* type - `bug`, `tech-debt`,` enhancement` labels. Issues with `proposal` label should be converted to `bug`, `tech-debt`,` enhancement` before addidng to project.
+* priority - `Prio: high`, `Prio: med`, `Prio: low` labels. On the board inside issues with same priority sorting from higher to lower priority is applied.
 
 #### Defining
 The column is intended for issues not completely clear or for features, that should be splitted to smaller issues in order to go ahead.
-After defining all issues that are intended to develop should have size label(`Size: S` - 2-3 hours, `Size: M` - 6-8 hours, `Size: L` - 8-24 hours)
+After defining all issues that are intended to develop should have size label
+*`Size: XS` - 1-2 hours, 
+*`Size: S` - 2-4 hours,
+*`Size: M` - 4-8 hours, 
+*`Size: L` - 8-20 hours,
+*`Size: XL` - 20-40 hours,
+*`Size: XXL` - 40-60 hours.
 #### To design
-It uses for issues that are already defined and require designing process.
+It is used for issues that are already defined and require designing process.
 #### Designing
 It shows up that issues are currently in designing process.
 #### To develop
 It stores issues which are ready for development.
 They are explained, clear, designed and **small enough to create one pull request per issue.**
+#### In Bounty
+The store with issues which are open bounties. When we put funds to issue and it shows up in [status open bounty](https://openbounty.status.im), we move issue here.
 #### Developing
 This is for issues that are currently developing, so pull requests assosiated with issues have to be placed in `Pipeline for Pull Request` project. 
 #### Done
@@ -37,24 +46,26 @@ It stores issues with merged to `master` pull requests.
 
 #### Developing
 Contains all open pull requests (hereinafter PRs) that already assosiated with issues.
-#### Contributor
+#### Reviewing, waiting for contributor
 It keeps all PRs from external contributors which should pass `Reviewing` stage.
 #### Reviewing
 The storage for all  PRs that pass reviewing process.
 Review  process is discussed [here](https://github.com/status-im/open-bounty/issues/221)
-Main points:
-* PR is quick fix (from core contributor) - 1 approval from core contributor
-* PR is complex (or from external contributor) - 2 or more approvals from core contributors
+The number of reviewers should be proportional to the complexity of the change and may vary from PR to PR.
+Recommended:
+* PR is trivial (from core contributor) - 1 approval from core contributor
+* PR is normal (or from external contributor) - 2 or more approvals from core contributors
 * PR need to be based on and opened against the `develop` branch.
 * If a PR has undergone review and requires changes from author, move it back to `Contributor` column
 #### To test
-All PRs, that are already developed, reviewed, deployed to test environment and ready to be tested.
+All PRs, that are already developed, reviewed, and haven't conflicts with `develop` branch, so ready to be tested.
+In case if PR has conflict - it is moved to `Reviewing, waiting for contributor` for external contributors or to `Developing` for core contributors.
 #### Testing
-All PRs that are currently pass testing process.
+Contains all PRs that are currently should pass through testing process, which is described in `core_testing_workflow.md`.
 After testing two scenarios possible:
-* no issues assosiated with PR - `Tested: OK` label and it is moved to `Ready to merge`
+* no issues assosiated with PR - `Tested: OK` label, merge to develop (using `Merge` button) to `Merged to develop`
 * issues found - all of them are created as comments to current PR and PR is moved to `Developing`
-#### Ready to merge
+#### Merged to develop
 Keeps PRs that should be merged to `master` and deployed to [prod environment](https://openbounty.status.im/)
 #### Done
 Stores all merged and closed PRs.