Added PG guides

packages/docs/src/pg/index.rst

@@ -23,3 +23,10 @@ A lot of our documentation is about Plasma Group projects, but there's also a lo
    src/pigi/contributing
    src/pigi/reference
 
+.. toctree::
+   :maxdepth: 2
+   :caption: PG Guides 💖
+
+   src/pg/contributors
+   src/pg/community
+   src/pg/github

packages/docs/src/pg/src/pg/community.rst

@@ -0,0 +1,49 @@
+=====================
+Community Interaction
+=====================
+
+Community members are the single most important resource available to Plasma Group.
+With such a small set of core contributors, we can only hope to create the best possible plasma implementation by tapping into our community.
+Remember, we **cannot succeed without the support of our community**.
+
+In the words of Eric Raymond:
+
+    If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
+
+It's **extremely** important that we keep this fact in mind during **each and every** interaction with a community member, on- or offline.
+
+General Guidelines
+==================
+1. **Treat all contributors with respect.**
+
+Our contributors are taking time out of their busy days to help us make plasma a reality.
+That alone deserves a lot of respect!
+Our contributors are also real people with real lives who are trying to make a difference and who are all deserving of respect.
+Plasma Group core contributors should treat all outside contributors with the same respect they show each other.
+
+2. **Always thank contributors.**
+
+Whether it's help with a bug report, feature request, or pull request, our contributors make a huge dent in the amount of work placed on the core team.
+Thank contributors for their help!
+It's nice and it's the right thing to do, but it's also important to make contributors feel appreciated.
+Most of the people helping us aren't doing it for the money, and they definitely don't want to receive a harsh response for trying to help.
+
+Even if a user has submitted something like a duplicate issue, thank them for their assistance!
+They'll feel like they can help out without judgement.
+
+3. **Show contributors that their contributions are making a difference.**
+
+Contributors want to make a difference, and it's important that their impact is acknowledged.
+Again, always thank contributors for their help.
+Feel free to reach out to contributors privately and thank them for their contributions, especially after big releases.
+
+Another great way to thank contributors for their work is to send `GitCoin Kudos`_.
+Kudos are special ERC-721s that you can send to users via their GitHub usernames!
+
+4. **Help contributors get involved.**
+
+This might be the most important rule of them all.
+Always be focused on helping contributors get involved.
+Whether that's by Tweeting out GitHub issues, linking users to documentation, or writing better issues, your **number one focus** should be to build out the community of contributors.
+
+.. _`GitCoin Kudos`: https://gitcoin.co/kudos/send/

packages/docs/src/pg/src/pg/contributors.rst

@@ -0,0 +1,57 @@
+=======================
+Our Lovely Contributors
+=======================
+This is just a quick high-level overview of the different types of contributors we can expect to work on Plasma Group projects!
+All of our contributors should be treated with respect, and they're all equally important.
+It's important to understand the different types of people who might be helping out with Plasma Group projects so we can streamline the contributing experience (and make sure everyone feels the love they deserve!).
+
+New Contributors
+================
+New Contributors are people who want to get involved with PG but might not know how yet.
+This is the "bucket" category for the remaining personas and New Contributors are eventually funnelled into one of the other categories.
+These users can be pretty much anyone - software engineers, crypto enthusiasts, family members, whoever. 
+
+Generally, we want to help new contributors become active contributors.
+For example, we might want to direct someone to resources that help them become a Beta Testing Contributor.
+This means that we should develop a set of strong resources where a new contributor can land and figure out where they want to help out.
+
+Co-Developing Contributors
+==========================
+Co-Developing Contributors are people working on the PG code in any one of our repositories.
+These people are doing all sorts of work, like tackling issues, adding new features, or writing new documentation.
+This work is usually happening in the Plasma Group repositories.
+
+These contributors want things to work on, and want a good experience while doing so.
+You wouldn't be working on a project if you couldn't figure out what to do or if you got a terrible response every time you tried to contribute!
+
+Co-Developers are extremely important and we need to make sure that they're always treated with respect.
+We should be responding as quickly as possible, reviewing their PRs, and rewarding them for their hard work.
+
+Beta Testing Contributors
+=========================
+Beta Testing Contributors are users helping us test our code, but not necessarily writing code.
+Often these contributors don't have the time to contribute lots of code because they're busy with other projects.
+However, these users still want to give back to the community by seeing how things work and playing with new features.
+These users want to make sure that their feedback is heard and that their time spent beta testing isn't for nothing.
+Adding features or fixing bugs quickly will make beta testers feel like there's constantly something new to explore.
+
+Beta Testing Contributors should be treated as a great resource, because they are.
+Without them, we wouldn't find all of the various bugs we're inevitably going to have.
+There's no such thing as production-quality software without beta testing :-).
+
+Passive Contributors
+====================
+Passive Contributors are users who are interacting with PG but aren't actively working on issues in one of our GitHub repositories.
+These users are typically people building applications on top of our projects but not working on the underlying code.
+For example, this might be someone building a wallet using ``@pigi/plasma-js``.
+
+Most of the time, these users don't come in intending to make significant changes to the code that they're making use of - they usually just expect it to work.
+When they do interact with the codebase, it tends to be to report a bug or ask for a new feature.
+These users are important because they find bugs in production and request features that help us build things out for real use-cases.
+
+External Contributors
+=====================
+There are lots of people who support us but aren't specifically helping out by making issues, tackling issues, or requesting features.
+This could be people on twitter discussing our work, sitting near us when we're working, or just providing moral support.
+We have to care for these people because they're what keep us motivated and pushing to build the best projects we can!
+Let them know they're appreciated because we wouldn't be here without them.

packages/docs/src/pg/src/pg/github.rst

@@ -0,0 +1,57 @@
+===================
+GitHub Interactions
+===================
+
+Most of our interactions with community members happen through GitHub.
+As a result, it's important that the key GitHub interactions are well planned out.
+This section describes the most important interactions (Bug Reports, Feature Requests, and Pull Requests) and provides basic guidelines for how to best work with community members.
+
+Bug Reports
+===========
+1. **If a potential active contributor submits an issue, give them the resources to become an active contributor.**
+
+A lot of the time, users submitting an issue aren’t familiar with the underlying code.
+They're probably submitting an issue because they can’t find an easy fix!
+If you just tell the user that you’re "on it" or something similar, you’re likely making the situation worse.
+
+First, thank the contributor for reporting the issue in a timely manner.
+They’re taking time out of their day to report a problem and, if they’re like a lot of us, it’s probably something that’s caused them a headache.
+A quick acknowledgment will let them know that you’re available, responsive, and are taking their issue seriously.
+
+If the user hasn’t provided enough information, make sure to politely ask for information that you think might be relevant.
+Always make sure the user provides steps to reproduce the problem so that it can be more easily solved.
+Unless you know otherwise, never assume that the user is particularly technical.
+Help them out by giving them the exact commands and relevant output that’ll help solve the issue.
+
+.. todo::
+
+    Create a basic diagnostics guide that helps users figure out what's going on with their projects.
+
+Next is getting to the source of the issue.
+Now this is where things get fun!
+The first thing you’ll want to do is to assess the general difficulty of the underlying problem.
+Using the steps to reproduce, try to locate the problematic areas of the software.
+Is it an encoding issue?
+Is the wrong thing being passed to another function?
+Is something undefined when it shouldn’t be?
+Is it a problem that’ll require fixes in ten different places?
+
+Depending on the difficulty of the problem, you’ll want to take different next steps.
+If the problem is relatively simple, great!
+This is an awesome opportunity to convert the potential contributor into an active one.
+If a problem is simple, unless the it's absolutely critical and needs an immediate fix, your top priority should be to give someone else the tools to solve the problem.
+Remember, letting potential contributors get their hands into some code is the best way to convert them to active contributors.
+
+Giving someone the tools to solve the issue for themselves is a multi-step process.
+First, you’ll want to provide the user with all the necessary background information.
+Explain the different relevant components and then explain what you think is probably the general cause of the issue.
+Feel free to tag another contributor if you think they'd have a better understanding of the problem.
+Your next steps depend on whether you know exactly what's causing the issue.
+
+If you don't know exactly what's causing the issue, this is a good opportunity to ask a potential contributor if they'd like to step in and solve the issue!
+This might be the person who submitted the issue or it might be another contributor that you tag.
+If it's not the person who submitted the issue, try to think about which contributor would most benefit from working on the issue. 
+
+If you already know what's causing the issue, try to explain the cause in a very detailed manner.
+You can even go as far as pointing out specific lines that are causing problems or sketching out a potential solution.
+You don't necessarily want to entirely solve the problem for someone else, but you do want to give enough leads if possible.