From c106c675b1329bffb72039947de52054f86319d5 Mon Sep 17 00:00:00 2001 From: Churikova Tetiana Date: Thu, 15 Feb 2018 10:27:36 +0200 Subject: [PATCH 1/4] Development workflow v1 --- doc/development_workflow.md | 60 +++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 doc/development_workflow.md diff --git a/doc/development_workflow.md b/doc/development_workflow.md new file mode 100644 index 0000000..d0a84e6 --- /dev/null +++ b/doc/development_workflow.md @@ -0,0 +1,60 @@ +# Development process in Status Open Bounty + +We have a continuously deployed version tracking the `develop` branch live at [test environment](https://openbounty.status.im:444). It uses the [Ropsten](https://ropsten.io/) Ethereum testnet. Any one is welcome to use it and contribute to Open Bounty. + +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. + +## Pipeline For Issues + +Issues are added to this project by product owner. + +#### 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. + +#### 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) +#### To design +It uses 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.** +#### 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 +It stores issues with merged to `master` pull requests. +## Pipeline For Pull Requests + +#### Developing +Contains all open pull requests (hereinafter PRs) that already assosiated with issues. +#### 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 +* 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. +#### Testing +All PRs that are currently pass testing process. +After testing two scenarios possible: +* no issues assosiated with PR - `Tested: OK` label and it is moved to `Ready to merge` +* issues found - all of them are created as comments to current PR and PR is moved to `Developing` +#### Ready to merge +Keeps PRs that should be merged to `master` and deployed to [prod environment](https://openbounty.status.im/) +#### Done +Stores all merged and closed PRs. From a7ad1cf8fde6e0529e6e32f771b402adceabbabe Mon Sep 17 00:00:00 2001 From: Churikova Tetiana Date: Mon, 19 Feb 2018 14:28:16 +0200 Subject: [PATCH 2/4] Development workflow v1-updated --- doc/core_testing_workflow.md | 27 ++++++++++++++++++++++ doc/development_workflow.md | 43 ++++++++++++++++++++++-------------- 2 files changed, 54 insertions(+), 16 deletions(-) create mode 100644 doc/core_testing_workflow.md diff --git a/doc/core_testing_workflow.md b/doc/core_testing_workflow.md new file mode 100644 index 0000000..55c54c9 --- /dev/null +++ b/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. + diff --git a/doc/development_workflow.md b/doc/development_workflow.md index d0a84e6..178d4d2 100644 --- a/doc/development_workflow.md +++ b/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. From 66d62bf030ede11d89ee36988f12681283f54c27 Mon Sep 17 00:00:00 2001 From: Martin Klepsch Date: Mon, 19 Feb 2018 15:14:48 +0100 Subject: [PATCH 3/4] whitespace formatting --- doc/development_workflow.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/doc/development_workflow.md b/doc/development_workflow.md index 178d4d2..f9bdb88 100644 --- a/doc/development_workflow.md +++ b/doc/development_workflow.md @@ -17,18 +17,21 @@ Issues can be added to this project by any core team member. 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` 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. + +* **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: 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. + +* `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 is used for issues that are already defined and require designing process. #### Designing From b8393b39a596c779d015d5d4998d9822af0af537 Mon Sep 17 00:00:00 2001 From: Martin Klepsch Date: Mon, 19 Feb 2018 18:21:35 +0100 Subject: [PATCH 4/4] fix relative time display for long-ago dates --- src/cljs/commiteth/activity.cljs | 4 ++-- src/cljs/commiteth/bounties.cljs | 4 ++-- src/cljs/commiteth/common.cljs | 22 +++++++++++++++++----- src/cljs/commiteth/manage_payouts.cljs | 4 ++-- 4 files changed, 23 insertions(+), 11 deletions(-) diff --git a/src/cljs/commiteth/activity.cljs b/src/cljs/commiteth/activity.cljs index 4940085..ec991fa 100644 --- a/src/cljs/commiteth/activity.cljs +++ b/src/cljs/commiteth/activity.cljs @@ -1,7 +1,7 @@ (ns commiteth.activity (:require [re-frame.core :as rf] [reagent.core :as r] - [commiteth.common :refer [relative-time + [commiteth.common :refer [human-time items-per-page display-data-page issue-url]])) @@ -54,7 +54,7 @@ ^{:key (random-uuid)} [:div.balance-badge.token (str (subs (str tla) 1) " " balance)])]) - [:div.time (relative-time updated)]]]]) + [:div.time (human-time updated)]]]]) (defn activity-list [{:keys [items item-count page-number total-count] :as activity-page-data} diff --git a/src/cljs/commiteth/bounties.cljs b/src/cljs/commiteth/bounties.cljs index 880ad04..d4eaa8f 100644 --- a/src/cljs/commiteth/bounties.cljs +++ b/src/cljs/commiteth/bounties.cljs @@ -1,7 +1,7 @@ (ns commiteth.bounties (:require [reagent.core :as r] [re-frame.core :as rf] - [commiteth.common :refer [relative-time + [commiteth.common :refer [human-time display-data-page items-per-page issue-url]] @@ -33,7 +33,7 @@ [:div.open-bounty-item-content [:div.header issue-link] [:div.bounty-item-row - [:div.time (relative-time updated)] + [:div.time (human-time updated)] [:span.bounty-repo-label repo-link]] [:div.footer-row diff --git a/src/cljs/commiteth/common.cljs b/src/cljs/commiteth/common.cljs index 0ecaf13..94fca42 100644 --- a/src/cljs/commiteth/common.cljs +++ b/src/cljs/commiteth/common.cljs @@ -2,7 +2,9 @@ (:require [reagent.core :as r] [re-frame.core :as rf] [clojure.string :as str] - [goog.date.relative])) + [goog.date.relative] + [goog.i18n.DateTimePatterns :as DateTimePatterns]) + (:import (goog.i18n DateTimeFormat))) (defn input [val-ratom props] (fn [] @@ -24,10 +26,20 @@ :disabled (= item title)} item])])) -(defn relative-time [time] - "converts time in milliseconds to a relative form of '1 hour ago'" - (let [js-time (clj->js time)] - (goog.date.relative/format js-time))) +(def ^:private long-ago-fmt + (DateTimeFormat. DateTimePatterns/MONTH_DAY_FULL)) + +(defn human-time [date] + "Shows a given date in a human-friendly way. For dates less than + two weeks ago this means a relative '3 hours ago' kind of thing. + For dates longer ago we return 'January 01'." + (let [ms (.getTime date) + relative (goog.date.relative/format ms)] + ;; Dates older than 2 weeks will not be shown as relative + ;; https://github.com/google/closure-library/blob/99d7fa323f4c9e35ce7a97ea3cb08fc1d97d9e92/closure/goog/date/relative.js#L206 + (if-not (empty? relative) + relative + (goog.date.relative/formatDay ms #(.format long-ago-fmt %))))) (defn issue-url [owner repo number] (str "https://github.com/" owner "/" repo "/issues/" number)) diff --git a/src/cljs/commiteth/manage_payouts.cljs b/src/cljs/commiteth/manage_payouts.cljs index eedd7f0..4c4368a 100644 --- a/src/cljs/commiteth/manage_payouts.cljs +++ b/src/cljs/commiteth/manage_payouts.cljs @@ -1,6 +1,6 @@ (ns commiteth.manage-payouts (:require [re-frame.core :as rf] - [commiteth.common :refer [relative-time]])) + [commiteth.common :refer [human-time]])) @@ -33,7 +33,7 @@ [:div.description (if paid? (str "(paid to " winner-login ")") (str "(" (if merged? "merged" "open") ")"))] - [:div.time (relative-time updated)] + [:div.time (human-time updated)] [:button.ui.button (merge (if (and merged? (not paid?)) {}