Web: better guide rails around what tasks are a good fit for gitcoin, how to price them

[owocki]

https://github.com/SoftwareEngineeringDaily/sedaily-front-end/issues/244

just got off a podcast interview with teh host of SEDaily. he tried a gitcoin bounty (above) but said he only paid $50 and that the code wasnt really usable… so he ended up having the bounty person refactor some code (a task that was better defined than the original) task and that was worth it..

i wonder if theres some learning / minimal guardrails we can put in the gitcoin.co/new flow to let users think through the success components for their task.

• pricing
• how well defined is the scope?
• etc

[mkosowsk]

This is from the perspective of a Funder?

This gets into ticket grooming and when a ticket is ready to be worked on (so-called "Definition of Ready"). A few sections that could be interesting as part of guardrails:

1. User Story template of "As a/I want/So That". Would recommend including this as part of the minimal guardrails, helps inform the rest of the issue.
2. Background: 1-3 sentences on what the project is about and why this feature is necessary. Would recommend.
3. Acceptance Criteria: in bullet points, everything that is needed for this ticket to be finished ("Definition of Done"). Absolutely necessary, this is what the developer is ultimately building toward accomplishing. Referring to Acceptance Criteria can help resolve disputes between Funders and Developers to see what was asked for and what was ultimately built.
4. Technical Details: informing the process of how the developer should work. This isn't at the level of specifying individual lines of code, but things like which libraries/packages to use, where models should live, etc. Possibly not in the minimal guardrails but something to keep in mind.
5. In Scope/Out of Scope: what should be affected and what shouldn't be. Possibly not in the minimal guardrails but something to keep in mind.
6. Test Cases: end-to-end tests that will pass after desired functionality is built out. Possibly not in the minimal guardrails but something to keep in mind.

So of these I think User Story, Background, and Acceptance Criteria would be a nice minimum to provide to Funders to think through the scoping of their ticket 👍

[owocki]

from @mkosowsk on slack:

i've seen bounties that have the quickest turnaround time usually follow best practices as far as tickets go (so-called "Definition of Ready") so having fully fleshed out

0. User Story (as a/ I want/so that)
1. Background
2. Acceptance Criteria
3. Technical Details (for more complex tickets)
4. In-Scope/Out-of-Scope (for more complex tickets)
5. Test Cases (for more complex tickets)

There is current work being done on standardizing helping Funders develop their tickets to make sure everyone both Funder and Contributor are on the same page :thumbsup:

also, some good info here: gitcoin.co/casestudies gitcoin.co/help/repo

[mkosowsk]

Perhaps a bit off topic but I think this model lends itself very well to a RedHat type of model for Gitcoin... As they say, Linux is only free if you value your time at $0/hour 😂

Charging a fee for:

1. Onboarding projects/clients to the Gitcoin platform
2. Helping to groom existing tickets for the project/client and providing advice on appropriate pricing and scope
3. Reaching out to members of the Gitcoin community that could be a good fit for the tickets
4. Walking through the project itself and creating issues for the client to either build features or squash bugs

Think this is a nice approach as it could help inform the Product Management for a company (helping talk about Vision and Priority) as well as Project Management (properly scoping tickets, ensuring good communication across parties).

These 4 (and others? 🤔) wouldn't be necessary for using the Gitcoin platform but think performing them properly could provide a nice boost to time-to-value for Funders using Gitcoin 👍

[owocki]

i spent 15 minutes today typing up a module that we could put before the 'new bounty' flow, which provides some expectation setting for the ender user:

i kind of made up the copy. its probably too wordy to ever get into production

i kind of like the way mycrypto handles their new user onboarding with a modal. this is a possible direction we could go:

i think that burning man does a good job of user onboarding too:

@PixelantDesign curious what you think of the above.

[owocki]

another TODO on this page: on gitcoin.co/new, make it clear that this information is public

[PixelantDesign]

closing this since we created the quickstart guide