community-repo/helpdesk/roles/builders

This guide will explain how you can take part in building Joystream, either by reporting bugs or contributing to our software.

Table of Contents

• Overview
  • Bugs and Improvements
  • Reporting Issues
  • Making Contributions
  • Community Bounties
  • Types of Tasks
  • Workflow

Overview

This page contains information on how you can contribute to building the Joystream platform. We are also happy to see community members contribute unprompted, and will always evaluate whether these warrant a bounty.

In any case, this guide will mainly focus on incentivized contributions through formalized Community Bounties.

Bugs and Improvements

As with all software, and especially the early versions, there will be plenty of bugs, missing features and enhancements required. Both to improve as we go, and to "train" a group of testers and developers for our autonomous platform, we are keen for "outsiders" to start contributing as soon as possible.

Reporting Issues

If you find a bug in any of our software, reporting these as Issues in the main Joystream repo is always helpful. Depending on the severity of the issue, and the quality of information provided in the Issue to allow us to evaluate and reproduce the bug, you may be eligible for a reward. Example of a detailed Issue:

• For nodes and software ran on your computer
  • Logs and crash reports (from one of the nodes)
  • Steps to reproduce
  • Your environment (e.g. operating system and version)
  • etc.
• If related to our Pioneer testnet app:
  • What (if any) error message did you see?
  • What were you trying to do?
  • What is your address?
  • What is your balance?
  • What is the type of key (i.e. Schnorrkel, Edwards or ECDSA)?
  • Are you a Member?
  • Is the key used for another role?
  • etc.

Making Contributions

As an open-source project, we try to follow the standard conventions and workflow.

If you find a bug or want to improve or add something in the code, documentation, or guides, go to our GitHub organization and find the appropriate repo.

Fork it, make the changes you want to address, and create a Pull request. For our mutual convenience, it would be nice if you made an Issue first, so we can address whether your work would qualify for a Bounty.

Community Bounties

The (Community) Bounties are meant to replace the "old" Bounty system previously used by Jsgenesis. In discussions with the community, these have been referred to as "Community KPIs", but we've chosen to use the term Bounties to properly distinguish them from "regular" Council KPIs.

Jsgenesis will publish these first as (GitHub) issues in the Community Repo, before the Council makes a forum post. They can also be found through our website. Unlike Council KPIs,

• They will not be published at the same regular and predictable intervals
• They will not necessarily have deadlines
• Jsgenesis will rarely get involved in managing or assigning them

The last part is key, as the Council will act as Project Managers, and serve as a bridge between Jsgenesis and the individual or group working on them. In many cases, they will further hire a Bounty Manager to represent them.

Because of this, you should regularly monitor the on-chain forum.

Types of Tasks

The tasks associated with these Community Bounties will ideally try to solve some problem either for the community or Jsgenesis, but in some cases, their main purpose will be to create some fun and/or attract new members to the community.

Over time, the tasks should allow people with different skillsets and interests to participate. Most challenges will be easier if you have technical or creative skills, but in other situations it will simply require putting in some time and effort:

• Coding
  • Discord/Telegram bots
  • Scripts
  • Enhance the UI
  • Improve infrastructure
• Writing
  • Documentation
  • Marketing material
  • Explainers
  • Translations
• Creative
  • Videos
  • Artwork
  • Gifs
  • Memes
• Research, testing and sourcing
  • Source/upload freely licensed media
  • Testing and benchmarking tools
  • Research interesting projects
  • Tokenomics research
• Reviewing
  • All of the above

Workflow

As the Council are responsible for establishing the rules, format and workflow, we again advise prospective participants to lookup the specifics for a particular Bounty using the on-chain forum.

Reward Distribution

The Council decides how much of the total Bounty reward will go to the Submitter, if the rewards should or can be split, and so forth.

Format

The format should try to optimize for the time, quality, risk and cost, associated with each Bounty. In most cases, this means either an "Open", "Free For All" and "Closed" formats.

Free For All Format

For smaller, and perhaps more creative and subjective Bounty, it may make more sense to leave it as a "free for all". In this case, the Council sets a deadline, picks the best Deliverable(s), and rewards the Submitter(s) as per the rules, similar to a competition in many ways

Open Format

For smaller Bounties, perhaps running indefinitely, where entrants can make multiple submissions and there are few barriers to entry.

Closed Format

For a Bounty that requires investing lots of time and/or other resources, it may be reasonable to guarantee one or more "Applicants" that gets "Assigned", giving them some agreed time to complete all, or some, of the work, without having someone come in and "snipe" the reward.

Other

In addition to the varieties outlined, other formats can be defined and chosen if they are more appropriate for a specific Bounty.

A "new" Council must honor any agreements and rules set by their predecessors, for as long as the rules say so.