status-im
/
open-bounty
mirror of https://github.com/status-im/open-bounty.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'develop' into bug/migrations-#291

This commit is contained in:
P 2018-02-20 12:13:55 +01:00 committed by GitHub
parent d0b61c7733 abb626142a
commit 7a93d9810e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 124 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
doc/core_testing_workflow.md Normal file
View File

@ -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.

74
doc/development_workflow.md Normal file
View File

@ -0,0 +1,74 @@
# 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.
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
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` 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.
#### To design
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
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.
#### 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)
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, 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
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, 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`
#### 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.

4
src/cljs/commiteth/activity.cljs
View File

@ -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}

4
src/cljs/commiteth/bounties.cljs
View File

@ -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

22
src/cljs/commiteth/common.cljs
View File

@ -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))

4
src/cljs/commiteth/manage_payouts.cljs
View File

@ -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?))
{}