Forked from Joystream/community-repo https://github.com/Joystream/community-repo

l1.media 7a55321626 Merge pull request #679 from traumschule/test-providers 1 year ago
archives ce94493571 Create archive/history folder (#782) 2 years ago
bounties 77cc1ad047 Mark previous bounties closed 2 years ago
community-roadmap dca8bd1c44 Community Roadmap (#854) 1 year ago
contributions fd2f385831 a research on jsgenesis investors 1 year ago
council 640a1cdceb Rhodes: Update WG Lead Term Limits (#766) 2 years ago
helpdesk fcbd88a006 merge archived helpdesk 2 years ago
scripts 7a55321626 Merge pull request #679 from traumschule/test-providers 1 year ago
working-groups 97d326cd97 Update the storage documentation (#851) 1 year ago
workinggroup-reports dca8bd1c44 Community Roadmap (#854) 1 year ago
.gitignore e03e603b13 Giza Bot Updates (#601) 2 years ago
.gitmodules e03e603b13 Giza Bot Updates (#601) 2 years ago
LICENSE 96dca35cda Initial commit 4 years ago
README.md 7b55a58ee0 change banner 2 years ago

README.md

Joystream Community Repository for reports, researches, tools and other community contributions.

Table of Contents

Overview

The Joystream Community Repo is meant both as a resource for the community members of the Joystream project, and a place to submit their work or contributions.

If a KPI requires submitting a deliverable, eg. reports or some code, it is expected that a PR is made to this repo in order to qualify.

Although the community is meant to control the repo, Jsgenesis will approve and merge any pull requests for now. Note that the repo is licensed under GPLv3.

Workflow

The workflow for changing the repo depends on the reason and purpose behind the change. A consistent part is for the contributor to fork the repo, and create a pull request to the applicable branch. All changes need to be approved with a proposal, except for selected files.

KPI Related Submissions

When a KPI requires a deliverable to be successful, the following steps must be made:

  • A pull request is made to the master branch.
  • A proposal is made to the Joystream testnet.
    • The proposal (Text, or in some cases, Spending) contains a link to the PR and other relevant information
    • When (if) the proposal is voted through, @bwhm and @blrhc is tagged
    • The time of the latest commit will be used as the time of submission
  • The PR is reviewed, and as long as it does not contain anything malicious or does not comply with license, it is merged.
  • The submission is added to the Submission Log

Individual Submissions

If the deliverable is made by an individual, eg. for an existing or upcoming funding proposal, the following steps must be made:

  • A pull request is made to the community branch, in a new folder within the Community Contributions directory.
    • Example: Bot project - Author Name
  • A proposal is made to the Joystream testnet.
    • The proposal (Text, or in some cases, Spending) contains a link to the PR and other relevant information.
    • When (if) the proposal is voted through, @bwhm and @blrhc is tagged
  • The PR is reviewed, and as long as it does not contain anything malicious or does not comply with the license of the repo, it is merged.
  • The submission is added to the Submission Log

Jsgenesis Submissions

If a member of the Jsgenesis team wants to make changes to the repo, the following steps must be taken:

  • A pull request is made to the master branch
  • A Text proposal is made to the Joystream testnet.
    • The proposal contains a link to the PR and other relevant information
    • When (if) the proposal is voted through, the PR is merged.
  • The submission is added to the Submission Log

Revisions & Improvements of Submissions

  • For general updates (updating links, text) these can just be gathered occasionally and submitted as a rolling update like this example: https://testnet.joystream.org/#/proposals/14 This does mean that it will take some time for the PRs to be approved by the council.
  • In the event of some highly important change, a proposal could be made so that the matter is addressed more quickly than waiting for a rolling update
  • If users want to be paid for updates or corrections, then they should open a PR (or multiple PRs) and link to it in a spending proposal, when this is approved it would have the same effect as approving the PR (which still has to be reviewed by Jsgenesis)
  • As an example, if a user wants to add functionality to the telegram bot and be paid for it, they can open a PR and create a spending proposal linking to the PR