Skip to content

Latest commit

 

History

History
121 lines (82 loc) · 5.81 KB

README.md

File metadata and controls

121 lines (82 loc) · 5.81 KB
Raw

Public Assembly DX Research

How It Works

  • Participants will complete curated tasks from this repository (also view below) designed to invoke problem-solving skills for auctions, proposals, and onchain theming with the DAO Utils package.
  • Each task is designed to take under an hour to complete and participants work on their own machines.
  • Communication between the project team and participants will occur on the forum working group and email.
  • Participants can submit their solutions via pull requests or issues on the official DAO Utils repository or the forum, with a loom or recording to provide additional context.
  • The submission period is 2-3 weeks.

Requirements

  • Programming languages
    • Currently the only languages we support are React, Typescript, (and Solidity?)
  • GitHub
  • Using Loom

Tasks

https://github.com/public-assembly/dx-research-layer

CE = Closed ended One Solution OE = Open ended Creative prompts, No right or wrong answers

Moderated

Pair programming (Interviews?)

Unmoderated

(Under construction, scenarios offered as a draft)

  • Token Explorer and Auctioning:
    • Use the resources available on Flexible Docs to learn how to add a Token Explorer to your site, change the color and size of the Token Explorer.
    • Make a component that let's users view owned tokens.
    • Avatar and Profile Building
      • Create an avatar and build a profile using DAO utils' atomic components, such as Token Title and Token Thumbnail
    • Open-ended hack
  • Proposals and Voting:
    • Develop a component that displays a user's reputation based on past votes, as well as a user's voting history, including the number of votes they have cast and the proposals they have supported or opposed.
    • Notification Component
      • Create a component that displays notifications to users based on proposals, showing updates about new proposals, voting results, etc
    • Social Component
      • Implement a social media component that allows users to comment on single proposals off-chain
    • Sharing single prop on social media?
  • Onchain Theming:
    • Create a light and dark mode theme toggle component and use on-chain theming to colorize proposal page components based on whether the proposal has been defeated or undefeated
    • Open ended hack

Timeframe

Max 1 Hour on individual problems.

Quickstart

This guide will use PA task #1, but participants can choose one from the tasks by clicking here.

Fork the Repository

  1. Fork the repository, and clone it.
  2. Complete the Task
    1. Follow the task instructions. Every task will be unique.
  3. Report Bugs and Friction
    1. This is the whole point of the research. When participants encounter friction, confusion, or bugs, open GitHub issues on the base repository.

Submissions

  • Participants are expected to provide feedback in addition to reporting bugs.
  • Feedback can include anything that causes friction when completing the goal, such as confusing documentation or time-wasting errors.
  • Participants must attach screen recording clips to issues/PRs.
    • Recordings help moderators understand the context of the participant’s feedback and validate submissions.
  • Post Survey which will ask them to include their wallet address and link to their PR with any further questions or feedback they may have on the experience.

Feedback

People can file feedback for anything this "friction" to completing the task

  • Things expected to work that didn't
  • Confusing or outdated instructions
  • Spelling and syntax errors in documentation and code samples
  • Website UI that doesn't work

Honest experiences will help maintainers improve their tools and remove friction for the next developer.

What makes quality feedback?

Note that all feedback should include a loom as well as a short description of the problem and experience.

  • Identify specific areas where there were struggles, such as with understanding documentation or debugging an error
  • Provide concrete suggestions for improving the developer experience, such as adding more examples to the documentation or clarifying ambiguous language
  • Offer suggestions for alternative approaches or tools that may be more effective
  • Be respectful and constructive, rather than critical or dismissive

What are some examples of quality feedback?

/example

“At first, I tried installing through terminal, but it kept throwing errors, despite installing it how the documentation said to. Then I switched to a nextjs project which, admittedly, I am not familiar with. Even then following documentation and examples online, it was not allowing me to download and execute the example getting started code.”

“Using my (example: existing API key) my code didn’t deploy, but does work through my local machine When do this however it does work.”

“Setting up providers are confusing. Also, its not exactly clear how to create a theme on the site.”

“Message is always "This is a test message from your account", regardless of what message I put in when using the Provider. Is this a limitation of the package? Or is it a bug? If the former, I didn't see it documented clearly anywhere.”

How does this work if solutions are public?

This research is about honest individual feedback we give maintainers. Sure, people could copy feedback and solutions, but that's why we use loom to validate submissions.

Compensation

0.25 ETH

Code of Conduct

Sponsors

Public Assembly

Community

https://forum.public---assembly.com/g/Research-WG

Modified from Haxor DX Challenges