Purgeable / issue-broker

Close github issues with payments to freelancers
0 stars 0 forks source link

need comments on usercase #3

Open epogrebnyak opened 7 years ago

epogrebnyak commented 7 years ago

Screnario from here needs comments:

  1. Project owner: links project reposotory to issue brocker (with webhook)
  2. Project owner: sets hourly rate for repository (eg USD 10/h)
  3. Project owner: creates issue with a tag time [1:30] in title
  4. Issue broker: shows issue listing
    • repo name - issue title - hours - rate - status: open
    • freelancers read this listing
  5. Freelancer (at github): writes comments he wants to do this
  6. Project owner (at github): assigns freelancer to issue
  7. Issue broker: updates issue listing
  8. Freelancer (at gihub) : makes commits and issue comments at github
  9. Project owner (at github): closes issue
  10. Issue broker: makes payments from project owner to freelancer and updates issue listing

UPDATED

relique commented 7 years ago

Seems good enough for a prototype, just a few questions here we all could think about.

  1. Where do we get a design? Or shall we start off of a simple templating engine, e.g. Bootstrap?
  2. What does taken mean? Is it the same as in progress?
  3. Will it have a bidding system per issue? For example, if a few freelancers apply for the same task how does a PO pick and assign one?
  4. How do we link a Github issue with related commits? Does a freelancer need to add a specific tag in a commit title? If not, how else can we implement that? Same goes to pull requests.
epogrebnyak commented 7 years ago
  1. any simple design can do, like Bootstrap, minimum workflow is critical
  2. i'll elaborate on taken/in progress
  3. I strive to concentrate on MWE, the bare minimum that allows to get workflow going, from this angle, there is no price bidding in version 0 of the workflow, but shoudl appear as extension
  4. righ now for the payment we have just one event that releases the payment and that is issue closed by project owner, again from the perspective of version 0 we are not tracking any other events in the issue. hope that makes sense for the prototype
relique commented 7 years ago

Thank you for explanation @epogrebnyak

epogrebnyak commented 7 years ago

@relique, you are welcome - working on more detailed workflow based on information gained in discussions with you and @PayProtect, will post here soon

relique commented 7 years ago

Noted on this @epogrebnyak , I'll follow up with this thread.

epogrebnyak commented 7 years ago
  1. Project owner (at issue broker): registers project reposotory with issue broker

    • after this the issue broker listens to repository events via webhook
  2. Project owner (at issue broker): sets hourly rate for repository (eg USD 10/h)

    • form: set hourly rate in repos table
    • simplification: just one rate and no price bidding for now
  3. Project owner (at github): creates new issue with a tag in issue title, example [1.5h]

  4. Issue broker:

    • gets information about new issue from webhook
    • database: writes repo id, issue number, title and time in minutes to issues table
    • view: displays issue in tasks view as: repo name - issue title - hours - rate - status: open
  5. Freelancer (at github): writes comments at github for issue (eg how better do this, why he is best fit for it)

    • simplification: we are not tracking this activity in issue broker for now
    • simplification: no bidding on price
  6. Project owner (at github):

    • reads comments
    • sends invite to freelancer to become a repo contributor
    • assigns issue to freelancer
  7. Issue broker:

    • gets information about issue assigned from repo webhook
    • database: creates new row in contracts table: issue id + freelancer id + when started
    • view: in tasks view issue status is changed to status: taken
  8. Project owner and freelancer (at github): makes issue comments at github, freelancer makes commits

    • simplification: we are not tracking this activity in issue broker for now
  9. Project owner (at github): closes issue

  10. Issue broker:

    • monitors webhook to see issue closed
    • database: writes timestamp when closed to contracts table
    • action: makes payments from project owner to freelancer
    • view: in tasks view the issue status is shown as status: closed
epogrebnyak commented 7 years ago

1-4 is issue staging, 5-7 is negotiation/assignment, 8-10 is completion

epogrebnyak commented 7 years ago

@relique, @PayProtect - can you comment on 10 steps in workflow? 💯

epogrebnyak commented 7 years ago

We delegate negotiation and selecting a freelancer to github, issue broker just listens to what is happening at the issue, I think this is cleaner than bidding at broker and makes the broker thin.

epogrebnyak commented 7 years ago

Note a workflow at the top is updated too, it is a shorter reading with no reference to implementation

epogrebnyak commented 7 years ago

Last thing, short desription in stages:

A. Staging (create new issue)

  1. Project owner: links project reposotory to issue brocker (with webhook)
  2. Project owner: sets hourly rate for repository (eg USD 10/h)
  3. Project owner: creates issue with a tag time [1:30] in title
  4. Issue broker: shows issue listing as repo name - issue title - hours - rate - status: open
  5. Freelancers read this listing

B. Negotiation (assign freelancer)

  1. Freelancer (at github): writes comments he wants to do this
  2. Project owner (at github): assigns freelancer to issue
  3. Issue broker: updates issue listing repo name - issue title - hours - rate - status: taken

C. Completion (work, finish and pay)

  1. Freelancer (at gihub) : makes commits and issue comments at github
  2. Project owner (at github): closes issue when done
  3. Issue broker: makes payments from project owner to freelancer and updates issue listing repo name - issue title - hours - rate - status: closed