Skip to content
This repository has been archived by the owner on Apr 20, 2022. It is now read-only.

Latest commit

 

History

History
360 lines (233 loc) · 27.4 KB

CONTRIBUTING.md

File metadata and controls

360 lines (233 loc) · 27.4 KB

Banner

 

Contribution Guidelines

Welcome to the Index Coop! We are excited that you are looking to contribute in the DeFi world and help others achieve financial freedom. Here at Index, there are a variety of avenues for you to consider depending on your knowledge and experience in the world. Below you will find a collection of guidelines that the Coop uses to help everyone find their niche within our growing community.

A great start would be to check out the Index Coop Community Handbook and fill out the Welcome Form.

 

Table of Contents

 

Code of Conduct

The Index Coop is a project that exists through individual entities working together as a unified community. The community is governed by our Code of Conduct, and any unnacceptable behavior encountered while working on the Index UI should be reported to the #dev channel in our Discord.

 

General Information

Please do not file an issue to ask a question!

If you are looking for more information or need help getting answers, we have multiple outlets for you to consider:

  • Discord - Join our Discord for community discussions, questions, ideas, or involvement in the Index Coop.

    • The #copper_owl_quest channel exists to get new joiners plugged in and familiarized with how we do things as a community.
    • The #wizardry channel is a great place for experienced newcomers to continue learning while they complete bounties.
    • The #dev channel is home to the Engineering Working Group. The majority of development discussions take place here.
 
  • Index Website - Visit our homepage to browse the products we offer and learn more about who we are. You can also:

    • Read about all things within the Index Coop community.
    • Discover how you can contribute.
    • Become one of our methodologists.
    • Invest in our products.
    • Vote on proposals.
 
  • Forum - Contribute to the ongoing growth of our collective through governance discussions concerning tokenomics, upcoming proposals, and community organization.

  • Newsletter - Subscribe to our newsletter for ongoing education and investment insights.

  • Podcast - Listen to our podcast to stay up to date on all recent happenings in the community.

 

Plus, don't forget to subscribe to us on Reddit and follow us on Twitter!

 

Your Contribution to the Index Coop

The primary purpose of these guidelines is aimed at providing our developers with an overview of how work on the Index UI is processed. If you are a developer, then welcome! We need your experience and expertise to help us refine and enhance our products for all of our users around the world. Go ahead and read up on our New Joiner Quest, then join our Discord and navigate to the #copper_owl_quest channel to introduce yourself.

If you are not a developer, then we still need you! The Index Coop is a massive project containing a multitude of developmetal sectors. Whether you are a coding expert, an analytics guru, a talented artist, a creative visionary, an intelligent designer, an exceptional influencer, or a glorified memelord, we can guarantee that you have a part to play in our communitee. For more information on how to get involved, check out the crash course on our working groups and say hello to everyone in the #introductions channel on our Discord.

 

Getting Started

GitHub is structured in a way that allows us to manage index-ui through the use of forks from the original repository. When you want to begin working on a project for index-ui, the first thing you will need to do is create your own fork from the master that can be found at SetProtocol/index-ui. If you are new to GitHub, then we recommend this Quickstart guide before getting started, or you can sharpen up your vocabulary skills by reviewing some commonly referenced terms in the GitHub glossary.

 

Choosing Your Platform

There are a variety of ways to get work done for Index through GitHub, whether you choose to use the GitHub website or GitHub Desktop. The desktop application functions as an all-in-one resource that is streamlined for GitHub related content, and while the website includes many similar features, complete functionaility is achieved by using the command line. Interacting with GitHub in this way will require you to become familiar with Git, as the command line utilizes Git Commands for common tasks. You can install the appropriate Git package for your machine here. If you find yourself confused amidst the multitude of Git commands, then you can check out this comprehensive guide that features detailed descriptions of each command and the part they play in the GitHub Working Tree.

As for coding software, feel free to use your favorite platform! Many of our developers use Visual Studio Code, so if you are looking to maintain some consistency by installing many of the same extensions used by others in our community, then simply ask for recommendations in the #dev channel of our Discord.

 

Understanding Forks

Creating your own fork allows you to make a copy of the original repository that will exist as a separate entity from the master. The new clone can fetch upstream for updates that have occurred since the creation of your fork or submit changes for review before merging with the master repository. When you create a fork from SetProtocol/index-ui, your new branch will look like this:

 

yourName/index-ui

forked from SetProtocol/index-ui

 

Depending on your circumstances, you may want to keep your fork in sync with the master at SetProtocol/index-ui. The process requires a brief setup through the command line, but it can prevent future problems associated with unsynced commits between the two repositories when you attempt to merge your commits with the master. Alternatively, you can always perform a manual fetch upstream command from the web application. If you would like a more comprehensive understanding of everything related to forks, you can find that here.

 

Understanding Branches

Within your own forked version of the master repository, you are able to create and label separate branches for distinct purposes. Branches allow you to work on specific projects in isolation from any other work you may be doing in other files or folders. Creating a branch is simple, and it is highly recommended that you create a separate branch for each individual project that you begin. This will keep all of your work consolidated within an isolated environment, which will make troubleshooting much easier by reducing the amount of variables involved across your repository.

 

Technical Resources

Below you will find links for some useful resources to utilize as you develop projects for Index:

 

Installing Dependencies

Since index-ui is the front-end we use to interact with Index, you will also need to install the necessary dependencies for your project to function correctly. In order to run the commands, make sure that you have already installed Node.js on your machine. After installing Node.js, you can simply run npm install -g yarn to install yarn, and follow these steps to set up your own local version of index-ui .

 

Coding Conventions

While we don't necessarily require you to follow a strict set of rules, we highly recommend the use of Prettier in order to keep the formatting of your code clean and uniform. The benefit of this approach is that we can help our developers maintain their sanity as they troubleshoot bugs or review the coding for new features. Additionally, it makes future adjustments to the code much less time consuming when there is some consistency across all of the features added to index-ui.

 

Coding Comments

A good habit to develop early on is to include some simple comments within your code so that anyone who views your code (including your future self) can gather a brief summary of what is being viewed without spending an inordinate amount of time studying the syntax in order to understand it's functionality. As a general rule:

    ➞   comments   ≠   documentation

Commenting is mostly for clarification, while documentation helps to define the underlying purpose for the code. In order to prevent clutter within your code, try to employ the use of clever naming conventions that inherently describe the processes involved within their nomenclature, rather than relying upon blocks of comments for clarity. Ultimately, discernment is the key to effective commenting, so if you'd like to read up more on the use of comments within code, you can do so here.

 

Coding Documentation

Typically, documentation is an external resource that provides an explanation of your code and the purpose it serves to everyone involved with the project. You could consider these Contribution Guidelines to be a form of documentation, as they are a publicly accessible compilation of standards that are pertinent to the development and growth of index-ui.

At Index, we are a community-driven project, and proper documentation is essential for the ongoing growth of our project within the DeFi world. If you are interested in learning more about the various ways in which documentation is useful for us, we can direct you to this Beginner's Guide or these tips to simplify the process of documenting your work.

 

Issues

☞ ☞ REMINDER ☜ ☜

Please do not file an issue to ask a question!

Issues are an organized way of keeping track of work being done on bug reports and feature requests for index-ui. Each issue should have the following aspects in order to maintain consistency and reduce confusion:

 

Type Description
Title Briefly summarize the issue.
Description An adequate explanation of what is needed and/or requested.
Labels Color-coded labels help to categorize issues according to type or difficulty.
Assignee Adding an assignee to a particular task helps to avoid miscommunication and prevent multiple people from working on the same issue simultaneously.
Comments Each issue has a comment thread for claiming an issue and following up for additional information from the original author.

 

Filing an Issue

Before you file an issue, please check to make sure a similar issue has not already been filed. If a previous issue was indeed filed but never resolved, take note of the date the issue was created. It is perfectly acceptable to comment on the issue to track its progress, but remember to use reasonable discretion and allow the assignee time to resolve the issue. If you would like to read further into GitHub Issues and when to use them, you can do so here.

There are two primary templates used when filing an issue, so be sure to distinguish between a bug report and a feature request.

 

Bug Reports

  • Provide evidence of a demonstratable and reproducible bug.
  • Explain the steps that produced the bug with precise detail in order to isolate the issue.
  • Supply a specific block of code that is being problematic and ask for help with troubleshooting.
  • Feel free to include images or GIFs if they help to demonstrate the bug.

 

Feature Requests

  • Provide a clear, step-by-step description of the enhancement you envision.
  • Describe the current behavior and detail why a feature request would enhance future behvior.
  • Include any guidelines or parameters necessary for working on the project.
  • Feel free to include images or GIFs if they help to showcase your vision and assist in developing a new feature.

 

Labeling Issues

A great way for the Index Coop to continue growing is by granting newcomers with the ability to perform basic tasks to establish a footprint within our community. Providing these opportunities for newcomers is crucial to the ongoing development of our product and makes our DeFi movement even more sustainable and future-proof. If a project has a need for some simple work to be done that could be performed by a newcomer, then we encourage you to create a separate issue with the bronze-task label attached.

You will also notice a variety of other labels available for tagging Issues, but the ones that tend to be the most common are the bug and enhancement labels.

 

Resolving an Issue

After you have been assigned to a project and completed some or all of the necessary work involved, you will need to begin the process of resolving the issue. Within the isolated branch you have created and named in accordance with the issue you are resolving, check to be sure that your repository is up-to-date with the master at SetProtocol-index-ui. Upload the necessary files, and do your best to give them an appropriate name signifying their purpose, function, or relation to a particular project.

Once you are ready to proceed, you will need to commit the changes to your local repository. Commits save a snapshot of your repository and the changes made at a particular time, so feel free to perform multiple commits if necessary as you work through your project. When you feel that your work is complete and capable of being reviewed, you will need to push your commits upstream to the master. Once your files have been successfully pushed, you will be ready to link a pull request to your branch and submit your project for review.

 

Pull Requests

Pull Requests (often referred to as 'PRs') are the means by which the files that have been edited or updated within your fork are merged into the master repository at SetProtocol/index-ui. We have created a template to make the general formatting easier for our contributors and maintainers, but there are different stages to PRs, so be sure to familiarize yourself with the individual steps of the process.

 

Step 1: Creating a Pull Request

Creating a pull request is extremely simple, but you must first decide whether you need to open a draft or a request that is ready for review. A draft simply initiates the pull request process, but draft requests cannot be reviewed or merged with the master. You might consider opening a draft request first and double-checking that the branch you are attempting to merge contains all of the necessary files for your project. When you are certain that you want your project to be merged with the master, then you can change the stage of your draft and request for it to be reviewed for a potential merger.

You might also consider linking a PR to a particular issue so that it is automatically resolved once the review process is finalized and your work is merged into the master. GitHub recognizes keywords when initiating PRs, so a common phrase used to link to an issue is simply:

"This should resolve issue #0123"

 

Step 2: Reviewing a Pull Request

The actual merge will not be finalized until the request is reviewed by one of our developers with administrative write permissions. In the meantime, be sure to check your PR for comments containing suggestions or questions from our admins concerning your project. If one of our admins requests changes to be made, then you will need to edit your files and upload them within the conversation contained within your submitted PR. Be sure to provide as much specific detail as possible when interacting with admins in order to expedite the process and clarify the reasoning behind the decisions you made.

 

Step 3: Merging a Pull Request

After you have resolved any discussions concerning your project, our admins will verify that your PR is able to be merged with the master. This step requires administrative write capabilites to be performed, so you will not have to do anything other than wait for the merge to occur. Beyond this step, the only thing we encourage our contributors to do is put forth a diligent effort to maintain their projects and provide support as needed in the event that bugs appear or enhancements are recommended.

 

Troubleshooting

If you are experiencing problems or difficulty with the GitHub interface as it pertains to Index related content, then please direct all questions to the #dev channel in our Discord. All other basic, non-technical questions can be asked in the #help channel.

Some general troubleshooting guidelines to consider:

  • Always proofread your content.
  • Maintain a consistent coding standard throughout your projects.
  • Read and re-read your code to check for messy syntax or broken logic.
  • Refactor when necessary to clean up dense code blocks and simplify naming schemes.
  • Utilize an effective linter to assist with proper formatting.
  • Search for potential solutions on other coding forums.
  • Breathe. Work on something else for a while, and revisit the problem with refreshed determination.

↑ Back to top