ubclaunchpad · bobheadxi · Oct 12, 2020 · Oct 12, 2020
@@ -1,87 +1,5 @@
-Contributor Covenant Code of Conduct
-====================================
+Code of Conduct
+===============
 
-Our Pledge
-----------
-
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our
-project and our community a harassment-free experience for everyone,
-regardless of age, body size, disability, ethnicity, sex
-characteristics, gender identity and expression, level of experience,
-education, socio-economic status, nationality, personal appearance,
-race, religion, or sexual identity and orientation.
-
-Our Standards
--------------
-
-Examples of behavior that contributes to creating a positive environment
-include:
-
--  Using welcoming and inclusive language
--  Being respectful of differing viewpoints and experiences
--  Gracefully accepting constructive criticism
--  Focusing on what is best for the community
--  Showing empathy towards other community members
-
-Examples of unacceptable behavior by participants include:
-
--  The use of sexualized language or imagery and unwelcome sexual
-   attention or advances
--  Trolling, insulting/derogatory comments, and personal or political
-   attacks
--  Public or private harassment
--  Publishing others’ private information, such as a physical or
-   electronic address, without explicit permission
--  Other conduct which could reasonably be considered inappropriate in a
-   professional setting
-
-Our Responsibilities
---------------------
-
-Project maintainers are responsible for clarifying the standards of
-acceptable behavior and are expected to take appropriate and fair
-corrective action in response to any instances of unacceptable behavior.
-
-Project maintainers have the right and responsibility to remove, edit,
-or reject comments, commits, code, wiki edits, issues, and other
-contributions that are not aligned to this Code of Conduct, or to ban
-temporarily or permanently any contributor for other behaviors that they
-deem inappropriate, threatening, offensive, or harmful.
-
-Scope
------
-
-This Code of Conduct applies both within project spaces and in public
-spaces when an individual is representing the project or its community.
-Examples of representing a project or community include using an
-official project e-mail address, posting via an official social media
-account, or acting as an appointed representative at an online or
-offline event. Representation of a project may be further defined and
-clarified by project maintainers.
-
-Enforcement
------------
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may
-be reported by contacting the project team at [email protected]. All
-complaints will be reviewed and investigated and will result in a
-response that is deemed necessary and appropriate to the circumstances.
-The project team is obligated to maintain confidentiality with regard to
-the reporter of an incident. Further details of specific enforcement
-policies may be posted separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in
-good faith may face temporary or permanent repercussions as determined
-by other members of the project’s leadership.
-
-Attribution
------------
-
-This Code of Conduct is adapted from the `Contributor
-Covenant <https://www.contributor-covenant.org>`__, version 1.4,
-available
-`here <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>`__.
-
-For answers to common questions about this code of conduct, see the
-`faq <https://www.contributor-covenant.org/faq>`__.
+All contributors are required to adhere to the
+`UBC Launch Pad Code of Conduct <https://docs.ubclaunchpad.com/handbook/manifesto#code-of-conduct>`_.
@@ -12,37 +12,40 @@ issue <https://github.com/ubclaunchpad/rocket2/issues>`__! That being
 said, make sure to do a quick search first - there may already be an
 issue that covers it.
 
-When creating a new issue, please add a label describing the issue; the
-most relevant are probably “Bug” and “Feature request”.
+When creating a new issue, please use the existing templates, and make sure
+the appropriate labels are attached to the issue. **If you are going to work
+on an issue, please assign yourself to it, and unassign yourself if you stop
+working on it.**
 
-**If you are going to work on an issue, please assign yourself to it,
-and unassign yourself if you stop working on it.**
+Task Triage and Planning
+------------------------
 
-If you are not planning to work on a new issue, please also add it to
-the Rocket 2.0 project; this will automatically add it to our Kanban
-board’s backlog, where we can review it in a future sprint.
+All newly created issues are automatically added to the
+`Rocket 2 project board <https://github.com/ubclaunchpad/rocket2/projects/1>`_.
+The life of an issue goes roughly as follows:
 
-Setting up branches
--------------------
+Issues start in *Needs triage*. From here, they are moved to either:
 
-Before you make any changes, you should first set up your own branch. It
-is common convention to name your branch:
+- *Icebox*: deprioritized tasks are tracked here
+- *Backlog*: this means that we want to get around to this task at some point
 
-::
+From the *Backlog*, we start moving tasks into *Planned*, which is typically
+around when discussions around design and potential implementation happens.
+When work begins in earnest, the issue should be moved to *In progress*,
+where it will stay until a pull request lands closing the issue, at which
+point it will automatically be moved to *Done*.
 
-   <username>/#<issue-number>-<description-of-fix>
+Development Documentation
+-------------------------
 
-So if your issue is `#153 Read from
-configuration <https://github.com/ubclaunchpad/rocket2/issues/153>`__,
-you would name it ``rwblickhan/#153-read-from-config``. The name needs
-to be concise, descriptive, and, well, have your name and number, so to
-speak.
+Please refer to the `local development guide <https://rocket2.readthedocs.io/en/latest/docs/LocalDevelopmentGuide.html>`_
+to get started! 
 
 Before-Pull-Request checklist
 -----------------------------
 
 -  All tests and style and docs checks pass (``scripts/build_check.sh``)
--  The Github build passes (Github will build your commit when you push
+-  The GitHub build passes (GitHub will build your commit when you push
    it)
 -  Your code is presentable and you have **not** committed extra files
    (think your credentials, IDE config files, cached directories, build
@@ -51,9 +54,10 @@ Before-Pull-Request checklist
    cover all the code you wrote (or effectively all, given the
    circumstances)
 
-We use ``codecov`` to check code coverage, but you can easily check the
-code coverage using the ``scripts/build_check.sh`` script. The coverage
-should be displayed after the unit tests are run.
+We use `codecov <https://codecov.io/gh/ubclaunchpad/rocket2>`_ to check
+code coverage, but you can easily check the code coverage using the
+``scripts/build_check.sh`` script. The coverage should be displayed after
+the unit tests are run.
 
 Submitting a Pull Request
 -------------------------
@@ -65,14 +69,18 @@ the pull request template with as much detail as you can. In particular,
 all pull requests should be linked to one or more issues - if a relevant
 issue does not exist, please create one as described above.
 
-All pull requests must be code reviewed. Currently the code is owned by
-the
-`brussel-sprouts <https://github.com/orgs/ubclaunchpad/teams/brussel-sprouts>`__
-team at UBC Launch Pad; at least one member of the team must approve the
-pull request before it can be merged.
+Note that you may open a pull request at any point during your progress -
+if a pull request is being opened as a request for feedback and help rather
+than a request for review and merge, then please open the pull request as
+a `draft pull request <https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests>`.
+
+All pull requests must be code reviewed before being merged. Currently the
+code is primarily owned by the
+`rocket2 <https://github.com/orgs/ubclaunchpad/teams/rocket2>`__
+team at UBC Launch Pad.
 
-All pull requests must pass our Github build before they can be merged.
-The Github build checks for:
+All pull requests must pass our GitHub build before they can be merged.
+The GitHub build checks for:
 
 -  Passing unit tests (via `pytest <https://pytest.org>`__)
 -  Minimum code coverage of unit tests (via
@@ -89,20 +97,10 @@ All of these checks are conveniently done using the
 
 Remember to add the label ``Ready for Review``.
 
-After your pull request has been approved and the Github build passes,
+After your pull request has been approved and the GitHub build passes,
 it can be merged into ``master``. Please do so with an ordinary merge
 commit, not a rebase or squash merge.
 
-Work in progress (WIP) pull requests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Sometimes, it may be more appropriate to submit a pull request that you
-are working on, just to say that you are working on something (or so
-that you can get some initial feedback on your work). In that case, it
-can be a good idea to submit a pull request marked WIP. The convention
-here is to prepend ``[WIP]`` in the title of the request, and to further
-mark it with the label ``WIP``.
-
 Updating an Outdated Pull Request
 ---------------------------------
 

@@ -27,3 +27,54 @@
    </p>
 
 |
+
+Rocket 2 is a from-the-ground-up rewrite of the `original Rocket <https://github.com/ubclaunchpad/rocket>`_,
+and it is a Slack bot that aims to be a ChatOps-style tool for team management
+across platforms like GitHub and Google Drive, with extensive configuration
+options so that it can be used by other organizations as well. Rocket 2 is used,
+built, and maintained with ❤️ by `UBC Launch Pad <https://ubclaunchpad.com>`_,
+UBC's student-run software engineering club.
+
+.. list-table::
+   :widths: 3 50
+   :header-rows: 1
+
+   * - 
+     - Main features
+   * - 💬
+     - **Unix-style command system in Slack** - invoke commands with a simple ``/rocket`` in Slack
+   * - 🔗
+     - **Platform integrations** - easily configure GitHub organization invites and teams, Google Drive permissions, and more
+   * - 🗂
+     - **Team directory** - provide and manage member information such as emails and other accounts
+   * - 🔒
+     - **Permissions system** - control access to Rocket functionality with a tiered set of permissions
+   * - 🔨
+     - **Hackable and extensible** - an open codebase makes it easy to add commands, scheduled modules, and more!
+
+|
+
+📦 Usage
+--------
+
+Check out our `command reference pages <https://rocket2.readthedocs.io/en/latest/docs/UserCommands.html>`_
+to get started interacting with Rocket, or take a look at how Rocket is used at UBC Launch Pad
+in the `Launch Pad handbook <https://docs.ubclaunchpad.com/handbook/tools/slack#rocket>`_.
+
+To set up a Rocket instance for your organization, refer to the
+`deployment <https://rocket2.readthedocs.io/en/latest/docs/Deployment.html>`_
+and `configuration <https://rocket2.readthedocs.io/en/latest/docs/Config.html>`_
+documentation.
+
+|
+
+📚 Contributing
+---------------
+
+Any contribution (pull requests, feedback, bug reports, ideas, etc.) is welcome!
+
+Please refer to our `contribution guide <https://rocket2.readthedocs.io/en/latest/CONTRIBUTING.html>`__
+for contribution guidelines as well as detailed guides to help you get started
+with Rocket 2's codebase.
+
+|
@@ -86,6 +86,12 @@
 # so a file named "default.css" will overwrite the builtin "default.css".
 html_static_path = ['docs/_static']
 
+html_context = {
+    'css_files': [
+        '_static/theme_overrides.css',  # override wide tables in RTD theme
+    ],
+}
+
 # Custom sidebar templates, must be a dictionary that maps document names
 # to template names.
 #

@@ -1,5 +1,7 @@
-Questions and Answers
-=====================
+Architecture
+============
+
+.. image:: rocket2arch.png
 
 **What is the ``db`` module?** The database ``db`` module consists of
 the ``facade`` and the ``dynamodb`` database we are using.

@@ -1,5 +1,5 @@
-The Configuration System
-========================
+Configuration Reference
+=======================
 
 We use environmental variables for all of our configuration-related
 things. A sample ``.env`` file (which is what ``pipenv`` looks for when