Web: [DESIGN] Gitcoin Requests

[vs77bb]

What

As a developer, I want the best the open source work in web3 on Gitcoin so that I can contribute to great projects.

Gitcoin Requests Page

• Incentivize Gitcoin developers to look around open source repo's themselves for potential Gitcoin issues and report these back to Gitcoin (by either dropping the link at gitcoin.co/requests or tagging @gitcoinbot on the issue directly along with how much they think a fair bounty would be worth)
• Holds a section which highlights community sourced issues, whether funded/partially funded/unfunded
• Has functionality for developers / maintainers / funders to click on an unfunded issue and fund

Gitcoin Bot / Other Updates Needed (Not In Scope For Design)

• Tags @gitcoinbot with a $ amount they'd be willing to do the work
• @gitcoinbot comments back (tagging the repo maintainers, maybe?) and saved that request down in an internal log for us to review (similar to how you review gitcoin.co/faucet requests)
• If the repo maintainer comments back saying they're down, give them a quick path to fund the issue and give the developer a 15% finders fee
• Submissions to the Gitcoin Requests page would be pulled down to a DB similar to the Faucet page (#258) for @owocki to review and decide whether to fund.
• If it isn't funded, but it's a worthwhile / reasonable issue, we may bounty on behalf of our developer
• If it is externally funded, we offer a 10% bonus to the community member who posted the bounty

Attributes of a request

• github url
• amount (0.01)
• denomination (ETH, DAI, etc)
• requested_by_github_username
• comments
• status (one of either open or closed - funded or closed - not funded)

Design bounty

This is a bounty to submit a design for the following page:

• requests index -- radio button in the Issue Explorer labeled 'Bounty Requests'
• request submission -- form to submit requests

Example Design

This example of the grants page (from @KennethAshley at #380 ) might be useful as a template as you think through how the page might look. There would still need to be a place for new submissions to be added (via hyperlink) and a button to fund the issue.

[gitcoinbot]

__This issue now has a funding of 0.3 ETH (173.94 USD @ $579.79/ETH) attached to it.__

• If you would like to work on this issue you can claim it here.
• If you've completed this issue and want to claim the bounty you can do so here
• Questions? Get help on the Gitcoin Slack
• $3696.44 more Funded OSS Work Available at: https://gitcoin.co/explorer

[joshmobley]

Taking a first pass at the index -- is this along the lines of what you're imagining?

[joshmobley]

Just looked closer at @KennethAshley work on the grant page. I do think that we can and likely should reuse his work on that for this feature as well. We can componentize those cards and their various meta to be used across the site.

I can work on the fieldset for the new bounty request, but otherwise I think we can reuse a lot of the same code we'll develop for that feature here. Thoughts @owocki ?

[owocki]

i agree. lets reuse as much as possibel

[vs77bb]

@joshmobley @owocki Second the thoughts on reusing from #380...

Would also be curious on the form styles for "Create A Request", once you get there. On that page, I'd imagine the form styles from our 'Fund Issue' form could come in handy.

@PixelantDesign any thoughts?

[PixelantDesign]

@joshmobley I am curious what the thinking is behind using tiles for a bounty index page.

@vs77bb I agree on reusing the forms.

[joshmobley]

@PixelantDesign from the requirements, it felt similar to a kickstarter type of proposition, where the community could fund a bounty to get it ready to work. That, in addition with the amount of data displayed led me to think that tiles might be good in terms of keeping information density in balance.

In conjunction with the filters, it felt like users would still be able to adequately navigate the issues without too much scrolling or pagination.

After the fact, I saw that @KennethAshley had used a similar approach for #380 -- which led me to believe that we could just reuse his designs for this section as well.

[vs77bb]

@owocki @PixelantDesign I'm starting to think that a better approach is mimicking the Issue Explorer as opposed to the Grants Page.

Kevin referred to this as 'reverse bounties' and I agree with this (as the intention is to make requests by the issue). @joshmobley What do you think? Apologies if the initial requirements were unclear.

Given these bounties are likely to be smaller (say, $50 - $500), I think it's possible that 'Funded' / 'Unfunded' as filters are correct to start, as the intention is they could be funded in one sweep (as opposed to a grant / kickstarter, which might take multiple parties contributing to reach the goal.

Looping in @thelostone-mc as I know he had a part to play in building out the Issue Explorer.

[thelostone-mc]

@vs77bb Ah we did use the grants page as an example , that's probably why @joshmobley went along those lines. ( I would end up doing the same )

Lemme know if I've got this right :

• I see an issue on the Angular repo
• Rather than filing it on their repo directly
• They'd report it on gitcoin/request and the the repo owners on accepting, a finders fee get's allocated and we create an issue on their repo (This happens post acceptance of the issue by the owner ? ) # Need clarity on this step

If it's the owner who has the yay/nay power, the kickstarter approach would be a overkill.
The explorer again has a ton of extra info -> which would need to be stripped away but is probably neater this way!
Your thoughts @joshmobley ?

[vs77bb]

@thelostone-mc Kinda... the focus wouldn't necessarily be on new issues, but any issues that a hunter might be willing to do / a hunter thinks should be bountied.

For example, on geth right now here is an open issue marked 'Help Wanted'. If I'm a dev who would be willing to work on this issue for .2ETH, I should be able to link to this in Gitcoin Requests and say so, which adds the request to our Gitcoin Requests (the spiritual equivalent of the Issue Explorer, but for bounties which people would like to see funded that aren't quite yet).

From there, Gitcoin Bot could comment on the repo saying that this bounty has been added to Gitcoin Requests, and would be worked for .2 ETH. The EF Repo Maintainer can bounty it if they think it'd be worth it by clicking 'Fund Issue'. If they don't, it remains in an unfunded status until Gitcoin Core / someone else decides to bounty it anyways. Does that make sense?

While your example also could work, I'm clarifying it could either be a new issue or an existing issue on an open source repo. As for the 15% finders fee, we can probably tip that outside of the MVP flow for simplicity.

Also, starting to think, couldn't this also turn into a radio button on the Issue Explorer? 'Requested Bounties' or something of that nature?

Appreciate your thoughts @thelostone-mc, hope this explanation helps :)

[thelostone-mc]

Yup that clears up stuff a bit !

I always associated the issue explorer as a place where only bounites issues are listed !

Usually it's the hunters looking for bounties who check out the explorer right ? Would it make sense to throw these into the mix ?
( Eventually once they get funded , it would land up here nevertheless :P )

That said , we've already got external bounties and explorer ! Don't want the users running around all over the place

If added into the explorer , issues could appear in the default only if they are funded , we would have a filter if they want to view issues which are pending funding

makes sense ! I vote issue explorer ^_^

[joshmobley]

@thelostone-mc @vs77bb I do like the idea of consolidating these different data types into one view (the explorer). That said, it may be a non-trivial design and UI effort to rework it to make sense with the various types of issues (funded vs. proposed). I could put together a couple of concepts along a spectrum of effort?

[vs77bb]

@joshmobley I like that approach, sounds good. It'd be nice to have one approach if it was integrated with the Issue Explorer + another which is more standalone (I'll yield creative control on what that looks like to you along the 'spectrum' you mentioned).

I updated the issue requirements slightly to reflect our convo. Happy to put in a bit more ETH as this has escalated in scope a bit since it was first posted!

[willsputra]

Some thoughts...

1. Would it be possible to have multiple requests for the same issue? Say, if Dev A is willing to work on the issue for 0.5 ETH, Dev B is willing to work on the same issue for 0.2 ETH.
2. What happens if the Repo Maintainer decides not to fund the issue? If Gitcoin Core/external funders then fund the issue, do we still need an approval from Repo Maintainer before Dev can start working on it?

[mkosowsk]

@willsputra

1. This is a very interesting point 👍🏻From the Repo Maintainer's perspective, you want as many Devs looking at your stuff as possible and also competing on price. From the Dev's perspective, you don't want to go out and do work to find issues that would be relevant and then be undercut by other Developers who leap frog what you're doing... For a first pass, I think it would be reasonable to limit the request to one per issue. Open to discussion!
2. If a Repo Maintainer does not fund the issue, looks like these bullet points are the original thoughts of @vs77bb:

• If it isn't funded, but it's a worthwhile / reasonable issue, we may bounty on behalf of our developer
• If it is externally funded, we offer a 10% bonus to the community member who posted the bounty

Going back to point 1, if there are multiple requests where does the 10% bonus bounty go to? I think probably to the personal who originally requested the issue and not the person who ended up working on it 🤔

[gitcoinbot]

⚡️ A tip worth 0.0001 ETH (0.04 USD @ $413.59/ETH) has been granted to @vs77bb for this issue from Mitchell Adam Kosowski V. ⚡️

The sender had the following public comments:

Really interesting discussion! I wanted to incentivize your great work so figured I'd send over a tip :) keep it up!

Nice work @vs77bb! To redeem your tip, login to Gitcoin at https://gitcoin.co/explorer and select 'Claim Tip' from dropdown menu in the top right, or check your email for a link to the tip redemption page.

• $2795.47 in Funded OSS Work Available at: https://gitcoin.co/explorer
• Incentivize contributions to your repo: Send a Tip or Fund a PR
• No Email? Get help on the Gitcoin Slack

[vs77bb]

Good questions!

Would it be possible to have multiple requests for the same issue? Say, if Dev A is willing to work on the issue for 0.5 ETH, Dev B is willing to work on the same issue for 0.2 ETH.

I think this is reasonable and will eventually happen in a sustainable way. However, it's not our intention to make this a 'race to the bottom'. I'd be fine with starting at a limit of one per issue for the MVP.

What happens if the Repo Maintainer decides not to fund the issue? If Gitcoin Core/external funders then fund the issue, do we still need an approval from Repo Maintainer before Dev can start working on it?

The specific instructions here will be to find issues marked 'Good First Issue' / 'Help Wanted' so that it's clear that the repo maintainer is looking for help. If it remains unfunded and is in review with Core team, these are tags we'll be looking for as indicators that external contributions are welcome.

Going back to point 1, if there are multiple requests where does the 10% bonus bounty go to? I think probably to the personal who originally requested the issue and not the person who ended up working on it 🤔

Moot point if we decide just one request per issue in MVP. However, it should be clear that the 15% bonus could go to someone who does not actually work the task. For example, if @mkosowsk sends a Gitcoin Request to Geth, the Geth team funds it, and then @thelostone-mc does the bounty...@mkosowsk should get the 15% for bringing the work to the platform (as much as that pains me to say). 🙂thoughts?

@joshmobley Let us know if this brings up any other questions... don't think the convo changes much for the spec but hope it continues to clear up the vision!

[mkosowsk]

Moot point if we decide just one request per issue in MVP. However, it should be clear that the 15% bonus could go to someone who does not actually work the task. For example, if @mkosowsk sends a Gitcoin Request to Geth, the Geth team funds it, and then @thelostone-mc does the bounty...@mkosowsk should get the 15% for bringing the work to the platform (as much as that pains me to say). 🙂thoughts?

Agree with this and not just because I'm getting paid in the hypothetical 😂At its heart, #671 is incentivizing users for Discovery (bringing the work) not the actual Contribution (doing the work) so we should be clear to delineate that 👍🏻

Side note, been discussing some interesting things with @KamesCG w.r.t. #671 and #760 (my baby! 😍) Think fleshing out these concepts could provide some big time value add to the Gitcoin platform :)

KamesCG: Uport just needs a better system to identify bounty opportunity
KamesCG: Wr have anywhere from REDACTED to REDACTED eth for bounties

Mitch Kosowski: thats a lot of eth
Mitch Kosowski: hold on

Mitch Kosowski: #671 is that what you're after?
Mitch KosowskiL: having people from gitcoin community going to your repo and saying hey this would be good to bounty, id do this for 0.25 ETH... shit like that?

KamesCG: Yes... And we want people to give us ideas for demo apps too.
KamesCG: So everything from just make our bounties for us... to dream up a good use case and well pay for the development via large bounties

Mitch Kosowski: cool, think between #671 and #760 you'll have some good coverage from that via gitcoin 👍
Mitch Kosowski: for #760 i want to eventually do stuff like building out a use case, but wanted to go after finding bugs to start as it's lower hanging fruit for a proof-of-concept

[mkosowsk]

@vs77bb quick clarifying point on this ticket: this is for finding issues that are already created and reporting back to Gitcoin, not for creating issues and then reporting back to Gitcoin?

Creation of issues beyond bugs (a la #760) and reporting back is a fair amount more work but think it could be a huge value add for a lot of projects that want to build out stuff and have the capital to deploy to do so but are time constrained... would be interested in discussing this further but it's out-of-scope for this ticket 👍

[willsputra]

Love the discussion going on here! Starting with one request per issue sounds good to me. 👍

[vs77bb]

@joshmobley Think we might have lost 'Start Work' here as it's been inactive for a week. Mind clicking it to re-claim?

[joshmobley]

from slack:

vivek [11:41 AM]
Hey @joshmobley how are you feeling? Wanted to check in on Gitcoin Requests.. it's one of the features we're prioritizing in Q2 and want to move the ball forward
if you have any WIP stuff you want to review or talk about, let us know and we can push with you :+1:

vivek [12:18 PM]
Also - no worries if other priorities have come up. We can ask someone else to pick this up if that works better

joshmobley [12:19 PM]
hey @vivek — i do have some WIP; but apologies for the delay — things have gotten crazy around here between sick kids and other life stuff — happy to lay it down for someone else if we need to move quick
i’m leaving town tomorrow and will have the rest of the week to focus on it — let me know what you think is best!
(leaving town meaning i’ll have headspace :slightly_smiling_face: )

vivek [12:21 PM]
thanks for the quick reply - no worries! if you feel you'll be able to pick it up manana I think that'll work well :slightly_smiling_face: @Pixelant [Gitcoin Team] and I will be around for quick feedback throughout the week
best of luck with the kids and all else in the meantime !

joshmobley [12:21 PM]
awesome — thanks!

[mkosowsk]

@joshmobley hat tip for that visibility! Nice 👍 👍 👍

[willsputra]

hey @joshmobley I can help out with this too. let's bounce off ideas here! 😊

[willsputra]

@vs77bb here's an idea if we're putting it in the Issue Explorer:

...and here's how I imagine the flow would be:

thoughts? 🙂

[gitcoinbot]

@joshmobley are you still working on this issue?

[vs77bb]

@willsputra This looks fantastic to me! I agree with the flow almost entirely. A couple points of feedback on nuances:

"6. Requested received a notifcation / email. Your request has been funded by XX!"

In my eyes, we want to encourage anyone to submit Gitcoin Requests, even if they themselves don't plan to do the work. It still makes sense to send the e-mail to them (and perhaps give them 'first-dibs' if they want to do the work by sending it to 'Start Work').

In a related point:

"7. Issue is moved to 'Work Started' with a special badge...

• Not sure a special badge is needed, as ~40% of issues right now are community funded (though not through Gitcoin Requests). Maybe a badge could be cool? @PixelantDesign
• If anyone can submit a Gitcoin request, there may be slight nuance to whether it should be 'Work Started' or 'Open'. Maybe Gitcoin Bot can make a comment stating that 'xx submitted this Gitcoin Request and has first dibs on this open issue for 48 hours. If it has been 2 days, consider this issue open for the taking'. Thoughts?

[joshmobley]

@willsputra keep running with this! I'm going to lay it down so you can pick it up!

[willsputra]

@vs77bb Thanks for the feedback! I agree with giving first-dibs to the requester for some time. The flow would then probably be like this:

1. Requester receives a notification / email:
   _'Your request has been funded by XX! Click Start Work below within 48 hours to start working on the issue. If not, the issue will be open for the taking.'_
   --> At this point, what should the issue status be? 'Work Started' makes sense for me if we're 'reserving' the issue to the requester.

7a. If requester clicked Start Work: issue is kept at 'Work Started'.
7b. If requester clicked Cancel or no respond for 48 hours: issue is moved to 'Open'.

[vs77bb]

--> At this point, what should the issue status be? 'Work Started' makes sense for me if we're 'reserving' the issue to the requester.

Agree! And agree with 7a and 7b. I think we're aligned here.

@PixelantDesign Also mentioned some nuance we should consider. Alongside the possibility that:

1. Funder sees the request under Issue Explorer in Bounty Requests.

We should send the funder an e-mail (if we know them) and Gitcoin Bot should add a comment to that thread when a request is made on their OSS repo. This increases the chances they see the request.

[willsputra]

@vs77bb awesome 👍I'll update the flow and work on the Submit Requests form as well.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

__Work has been started__.

1. @willsputra

   has committed to working on this project to be completed 10 months, 1 week from now.

[willsputra]

@vs77bb here are the updated flows:

Requester flow:
• Click "Submit a Request" in Issue Explorer
• Go to Submit Request form (reusing the Fund Issue form), fill in form
• Redirect back to Issue Explorer, with success notification

Funder flow:
• Click on an issue in Bounty Requests section of Issue Explorer
• Go to Issue Detail page, click "Fund Work"
• Redirect to Work Started section of Issue Explorer, with success notification

... and the latest overall flow:

[vs77bb]

I love it! @owocki @PixelantDesign any final questions before we move it to [CODE] phase?

Very much appreciate your attention to detail here, @willsputra.

[PixelantDesign]

@willsputra @vs77bb I think overall it works.

Though, I wonder if there are other ways to simplify the experience if separate bounty requests from the left rail list. My concern is that the explorer is becoming a catch all. Adding bounty request at the end of the list makes it a little confusing since the list order represents progression of work in some ways. Are there other ways to handle this?

For success confirmations, instead of:
Redirect back to Issue Explorer, with success notification.
It might be best to put the confirmation message on the screen where after you fund it, it mentions that the info is getting posted to the blockchain, otherwise, we will have two ux patterns of doing the same thing and can be confusing for users.

[owocki]

lgtm. @vs77bb want to take the first pass at the 'code it' ticket and ill provide a second pass?

[vs77bb]

@owocki See WIP ticket here, pending @PixelantDesign responses!

My concern is that the explorer is becoming a catch all. Adding bounty request at the end of the list makes it a little confusing since the list order represents progression of work in some ways. Are there other ways to handle this?

@PixelantDesign I feel the best way to easily test is to have it as a part of the Issue Explorer. The usefulness of a request will be measured by how quickly it turns into a) an 'Open' issue and b) 'Work Done', so it seems like there's more of a tie here than to the Explorer than say, Dev Grants, Jobs Board, etc.

If it truly picks up steam, we could house as it's own section (or perhaps it's own drop-down).

It might be best to put the confirmation message on the screen where after you fund it, it mentions that the info is getting posted to the blockchain, otherwise, we will have two ux patterns of doing the same thing and can be confusing for users.

Agree, this makes sense to show the confirmation screen after funding issue. From there, it could re-direct to 'Work-Started' as @willsputra mentioned (only after it is posted to the blockchain).

[thelostone-mc]

@willsputra would it make sense to add 0. Bounty Requested cause it could be stated as step 0 in the filter ? (makes it a complete lifecycle )

[willsputra]

It might be best to put the confirmation message on the screen where after you fund it, it mentions that the info is getting posted to the blockchain, otherwise, we will have two ux patterns of doing the same thing and can be confusing for users.

@PixelantDesign I'll change it to the funding confirmation message.

would it make sense to add 0. Bounty Requested cause it could be stated as step 0 in the filter ? (makes it a complete lifecycle )

@thelostone-mc I feel it might be slightly confusing, since:
• not all issues are started from 'Bounty Requested'.
• most of the 'Bounty Requested' issues would jump straight to 'Work Started', skipping 'Open'.
I'd prefer keeping it separate for now. 🙂

[thelostone-mc]

Hmm true ! I just figured cause we'd labeled stuff like canceled/expired which not every issue goes through but alright 🤔

[vs77bb]

@thelostone-mc @willsputra I tend to agree that it should be at the bottom because it's not necessarily something interesting to most bounty hunters (yet). it would be bad if bounty hunters went to 'bounty requests' thinking that these were already funded. keeping it at the bottom reduces that risk.

@willsputra feel free to 'Submit Work' here!

[dolebas]

Love this thread 👍🏻 One related thought: would it make sense to include an optional finders/founders fee as part of a bounty work scheme (gitcoinco/web#973)? Such option combined with crowdsourced bounties (gitcoinco/web#1023) could in itself incentivise developers to identify and kick-start existing issues with high potential for reaching sufficient crowd funding on Gitcoin?

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

__Work for 0.3 ETH (202.73 USD @ $675.77/ETH) has been submitted by__:

1. 
   
   
   
   1. @willsputra
   
   

@vs77bb please take a look at the submitted work:

• PR by @willsputra

• Learn more on the Gitcoin Issue Details page
• 
  
  • Questions? Checkout Gitcoin Help or the Gitcoin Slack
    
    $7,537.30 more funded OSS Work available on the Gitcoin Issue Explorer
  
  

[willsputra]

As suggested by @PixelantDesign, we're moving Bounty Requests to the top + also adding a line to separate bounty requests and regular issues clearer.

[thelostone-mc]

@willsputra this looks better ^_^ 👍

[thelostone-mc]

@willsputra would you hate me if I asked for a minor update ? What are your thoughts on having an subtle way of hinting out that the issue is not funded (so that it makes easy to differentiate when one searches through everything)
Could be an icon, a subtle border, a solid shape , anything

[PixelantDesign]

@thelostone-mc

@vs77bb Let's create a new design issue: Gitcoin Requests v2 to include:

• [ ] Unfunded label

No Data State for Gitcoin Requests

• [ ] what the funder sees
• [ ] what the contributor sees

Email Communication

• [ ] Funder email
• [ ] Requester email confirmation
• [ ] Funder Confirmation (this is exists, maybe just type clean up)

Anything else that you think we need?

@willsputra

[willsputra]

@PixelantDesign just wondering what are the requester email confirmations needed?
• Confirmation that the bounty has been posted successfully
• Confirmation that the bounty has been funded
• Confirmation that the requester has received 10% bounty bonus (if externally funded)

[PixelantDesign]

sounds good @willsputra

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

__The funding of 0.3 ETH (221.31 USD @ $737.71/ETH) attached to this issue has been approved & issued to @willsputra.__

• Learn more at on the Gitcoin Issue Details page
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $8,026.28 more funded OSS Work available on the Gitcoin Issue Explorer

[vs77bb]

@willsputra Thank you for all your work here!