DevPool Flow

<aside> ⚠️ Your 7 step guide to successfully contributing in the DevPool.

</aside>

1. Find a Task

• Check out work.ubq.fi for a list of open tasks.
  • You can sort by Price, Time, Priority, and Recent Activity.
  • If you login with GitHub, the text filter works in realtime for any keyword searches.

2. Wallet Registration

<aside> ⚠️ You only need to do this once and it persists across all of our repositories and issues.

</aside>

• If this is your first time participating in the DevPool, you will need to register your wallet address to collect payment upon completion of the task. This must be done before you complete a task, because of the automatic payment system.
• Comment “/wallet 0x0000” but with your address instead, on the issue you are interested to work on to register.

3. Clarifications

• Ask any clarifying questions related to the task on the issue. Be sure that you understand the task before starting it.

4. Fork

• Fork the repository, open a DRAFT pull request linked to the GitHub issue by including “Resolves URL” (replace “URL” with the URL to the issue.) in the pull request message body. Be sure to target the default branch (in most cases this is development)
  • This prompts our bot to assign you to the GitHub issue, which sets it aside only for you to work on. GitHub will also officially link your pull request to the issue in the UI.
  • This is formalized process to associate task context with work deliverables. This is an essential procedure for anybody to audit work deliverables, its context, and to see the associated compensation for it within the DAO.
  • See linking PRs to issues for more information on this feature.
• Frequently commit to your pull request to keep the organization up-to-date on your progress and to ensure that all builds/tests pass. When the deliverable is ready, you can mark the pull request as ready for review.

<aside> ⚠️ Do not force push changes once the pull request review process begins. Deleting commits slows down the review significantly. Reviewers have the ability to view only changed code from their previous review, unless the commits are deleted. Then they must re-review the entire PR each time.

</aside>

• A reviewer should pick up your pull request within 24 hours. If not - feel free to tag the task creator in a comment under your pull request!

5. Review Process

• Keep detailed questions in the discussion under the pull request.