Skip to content

Latest commit

 

History

History
72 lines (43 loc) · 6.26 KB

CONTRIBUTING.md

File metadata and controls

72 lines (43 loc) · 6.26 KB
Raw

Contributors Guide

Welcome to the Virtual Coffee contributors guide! We take our Code of Conduct very seriously, and all contributors must abide by it. Let’s treat each other with respect and remember we are all people who care and are trying.

As an open source community, Virtual Coffee recognizes the importance of supporting our members and creating clear paths of communication. We know that sometimes things get lost in translation and we want to assume positive intent.

With that said, if you believe someone has violated the Code of Conduct, please fill out our CoC Violation Form, which you can do anonymously.

Getting Started

Before you begin:

Types of Contributions 📝

You can contribute to the VC-Community-Docs content and documentation in several ways. This repo (short for repository) is a place to discuss and collaborate on event planning and coordination at Virtual Coffee.

📣 Discussions

For questions, comments, or other discussion topics that don’t have a clear action, please use the discussion board.

For example, if you want to ask “Should we do…” or “How do I do…”, you’ll start in the discussion board. This allows a whole-group conversation, and we can integrate the answer into docs or issues as necessary.

If you're starting a discussion for a specific team, it's useful to notify the team by using @Virtual-Coffee/{team name}

🪲 Issues

We use GitHub Issues to track our projects and the tasks we’re working on. Often, some tasks are connected or may rely on another issue being completed first. We also label issues that are just for VC Maintainers, which are for the Virtual Coffee Maintainers. We use labels and project boards to help organize issues. Some important labels to be aware of:

  • Up for Grabs: This issue is available for anyone to make a contribution
  • VC Maintainers: Internal tasks reserved for the maintainers team
  • Blocked/On Hold: Internal or external issues preventing this issue from moving forward

There are also team-specific labels that can help break down individual tasks within a team. Read more about those labels on the specific team's docs page.

If you're ready to file an issue, there are various issue templates available to you.

🛠️ Pull Requests

A pull request is a way to suggest changes in our repository.

⚠️ Heads up! If you'd like to make a change to this repo's docs, please make sure you've created an issue (or a discussion board post) first, and that you've been assigned to the issue. This allows the maintainer team to provide guidance and prioritize tasks — otherwise you may run the risk of spending time on something that doesn't end up getting accepted for various reasons.

We appreciate everyone’s efforts, and want to ensure that our communication is clear and open as much as possible. We strongly encourage communication and clarity before doing work.

Creating a Pull Request

  • You can propose changes using GitHub's web interface, or by forking this repository and cloning it locally.
    • Follow these steps to create a fork (a copy for your own GitHub account) of this repository and clone it to your local machine.
    • After cloning, install the dependencies by navigating to the working directory and running the command yarn.
  • Try to keep the pull requests small. A pull request should try its very best to address only a single concern.
    • Do the same for your commit messages. It is good practice to commit your work often. If your commit message contains the word "and", the changes should be broken into two commits.
  • For work in progress pull requests, please use the Draft PR feature. You may even want to add "WIP" to the beginning of your pull request title, just don't forget to remove it before you submit your PR!
  • When applicable, document your reasoning behind the changes. Explain why you wrote the code in the way you did. The code should explain what it does.
  • If there's an existing issue, reference to it by adding something like References/Closes/Fixes/Resolves #123, where 123 is the issue number. More info here.
  • We encourage you to pair program with others in the VC community when working on pull requests. GitHub has enabled contributors to add multiple authors to their PRs so everyone involved can be properly attributed. Learn more here.

Reviewing

Someone on the maintainers team will review every single PR. The purpose of reviews is to create the best experience we can for our contributors.

  • Reviews are always respectful, acknowledging that everyone did the best possible job with the knowledge they had at the time.
  • Reviews discuss content, not the person who created it.
  • Reviews are constructive and start conversation around feedback.

Suggested Changes

We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.

As you update your PR and apply changes, mark each conversation as resolved.