Finished

JBP-58: Add ooyoo to trial payout period

Author

Anon

Cycle

12

loading

Author:

@ooyoo

Proposal date:

2021-12-16

Summary:

Compensate @ooyoo $2000 in exchange for work in Frontend.

Risks:

The largest risk for the DAO is the possibility that @ooyoo leaves architectural improvements in an incomplete state.

Mitigation: Ensure work is as atomic and as discrete as possible during the trial period. Each update should not leave the code in an interim state that extends past my trial period.

  • For complex projects/improvements, @ooyoo will continue to document thinking before code gets written to ensure other Frontend team-members have a chance to review/critique. Context and knowledge will live in notion and across multiple teammates
  • @peri will continue to code review and ensure work/PRs are well-scoped

Payout recipient:

ooyoo.eth

Payout amount:

$2000 USD (in eth)

How have you already contributed to the DAO?

Link Unfurling In Progress - 90% done

Setup meta tags so that link-sharing unfurls with project specific information. Currently, sharing project pages leads to really confusing Juicebox-related titles and descriptions. This work required a fairly comprehensive understanding of dapp architecture and exploration of potential solutions by way of PoCs. Read more here.

**Immediate Impact**


Project page links will unfurl with project-specific information. Will lead to less confusion and higher click-through rates (strong guess). Urls will also have cleaner urls. (juicebox.money/#/p/constitutiondao —> juicebox.money/constitutiondao)


**Longterm Impact**


Establishes cloudflare worker architecture which will allow us to get most of the benefits of web2-style traditional server side features while keeping to web3 style SPA architecture. This work establishes a pattern to do work like:

	- Dynamic sitemaps for SEO
	- Dynamically generating images for link unfurling
	- Edge side caching of assets/js for decreasing load times (decreasing load times has shown to lead to higher conversion rates)

Linting/formatting of FE codebase Done

I set up automated linting and formatting¹ for the frontend codebase. This was my “intro” project. This work involved setting up configuration for our linters/formatters but also modifying the many places in the existing codebase that threw lint errors. After 25 comments and +904, -425 lines modified across 58 files, this time-consuming and manual work is no longer necessary because it’s now all automated! Even though this change touched a broad range of code, we did not experience any regressions/bugs in app behavior.

**Immediate impact**


All frontend contributors now get the safety and consistency provided by linting and formatting. All existing code has been updated to a no lint-errors baseline.


**Long term impact**


Our frontend codebase can now better support more contributors - new, core and those who contribute occasionally and infrequently. 

New frontend team patterns for increased visibility and deeper thought Done

I’ve suggested and put into practice a number of different ways to improve how the frontend-team brings visibility to its work.

**Improved project “face”**


Building on the work that @peri did, I updated the [Untitled](https://www.notion.so/26b80fcb50b34f3b9356fc7fc5286e05) page to give more visibility to new contributors and other DAO members how the Frontend team works. This is especially important for teammates that are getting onboarded. I was most excited to see @aeolian build on top of this work to bring more detail to the actual repos we work in.


**Funding Cycle Recap Memo**


Wrote frontend’s first [Untitled](https://www.notion.so/1554575bd0184aa4add6221db2427c48) that was shared in #dev to give other community members a summary of the work that the frontend workspace has completed and will work on. I intend to continue to find ways to give more visibility in summarized ways to keep other areas of the DAO in the loop.


**RFC Memos**


Established a space in the Frontend Workspace to collect RFC memos for projects/multi-step tasks that require a high level of context and deep thought. See[Untitled](https://www.notion.so/a1ef79379bdb421abd20250667b0d8e9), [Untitled](https://www.notion.so/085d128028b541cf9773a8bf1b67de9b), and our other [memos](/10a67ffc26b141d394af5d24998e9245?v=b24e555ff9234a39a4115565c5f3e1b1). 

How do you want to contribute to the DAO going forward**?**

In the next cycle, I would like to:

  • Shepard link-unfurling across the finish line
  • Add dynamically generated images for link shares
  • Write a Roadmap RFC for juicebox-sdk². I would like this roadmap be the basis for my continued work in the DAO.

Sponsors:

Peri

filipv

Nicholas


¹ A linter is a tool that catches programming errors, bugs, stylistic errors and suspicious constructs automatically - it is an important guard-rail to put in place as code-commit velocity increases. A formatter is a tool that standardizes code style and makes code easier to read.

² A common pattern in the web3 world is to provide a SDK library that provides dapp developers an easy way to interact with the protocol. For example, check out uniswap’s https://github.com/Uniswap/v3-sdk (used by 463 repos), aave’s https://github.com/aave/aave-js (used by 105 repos), or zora’s https://github.com/ourzora/zdk (used by 77 repos). Juicebox should provide its own sdk by extracting core logic out of the juicebox.money client.