Skip to content

Latest commit

 

History

History
111 lines (70 loc) · 7.57 KB

CONTRIBUTING.md

File metadata and controls

111 lines (70 loc) · 7.57 KB
Raw

Contributing to be.camp

🎉 First off, thanks for taking the time to contribute! 👍

The following is a set of guidelines for contributing to be.camp These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Table Of Contents

Code of Conduct

I just have a question!

How Can I Contribute?

Code of Conduct

This project and everyone participating in it is governed by the Charlottesville Meetup/Group Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to the #admin channel on Cville Slack.

I don't want to read this whole thing I just have a question!!!

Note: Please don't file an issue to ask a question. Please direct your questions to the #becamp channel in the Cville Slack.

  • Even though Slack is a chat service, sometimes it takes several hours for community members to respond — please be patient!
  • Use the #becamp channel for general questions or discussion about the beCamp event and the #beCamp website
  • @channel and @team are disabled on the Cville workspace. If you feel the need to @mention someone, you can @mention @andrew in the #becamp channel.
  • There are many other channels available, check the channel list

How Can I Contribute?

Reporting Bugs

This section guides you through submitting a bug report for be.camp. Following these guidelines helps maintainers and the community understand your report 📝, reproduce the behavior 💻 💻, and find related reports 🔎.

Before creating bug reports, please check this list as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible. Fill out the required template, the information it asks for helps maintainers resolve issues faster.

Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.

Before Submitting A Bug Report

  • Most importantly, ensure that you can reproduce the problem.
  • Perform a cursory search to see if the problem has already been reported. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one.

How Do I Submit A (Good) Bug Report?

Bugs are tracked as GitHub issues.

Explain the problem and include additional details to help maintainers reproduce the problem:

  • Use a clear and descriptive title for the issue to identify the problem.
  • Describe the exact steps which reproduce the problem in as many details as possible. For example, start by explaining how you arrived on the page that exhibits the issue (fresh load vs secondary page load). When listing steps, don't just say what you did, but explain how you did it. For example, if you "went to the about page" did you get there from the primary navigation, or a footer link, or some in-page content?
  • Explain which behavior you expected to see instead and why.
  • Include screenshots when possible that clearly demonstrate the problem.
  • Include any console errors that appear in your browser's dev tools.
  • If the problem wasn't triggered by a specific action, describe what you were doing before the problem happened and share more information using the guidelines below.

Provide more context by answering these questions:

  • Can you reproduce the problem with a consistent series of steps? If not, provide details about how often the problem happens and under which conditions it normally happens.
  • Did the problem start happening recently or has this always been a problem?

Include details about your configuration and environment:

  • What browser are you using? Exact version numbers are helpful.
  • What's the name and version of the OS you're using?
  • Which browser plugins do you have installed that could be affecting content on the site?

Suggesting Enhancements

This section guides you through submitting an enhancement suggestion for be.camp, including completely new features and minor improvements to existing functionality. Following these guidelines helps maintainers and the community understand your suggestion 📝 and find related suggestions 🔎.

Before creating enhancement suggestions, please check this list as you might find out that you don't need to create one. When you are creating an enhancement suggestion, please include as many details as possible. Fill in the template, including the steps that you imagine you would take if the feature you're requesting existed.

Before Submitting An Enhancement Suggestion

  • Perform a cursory search to see if the enhancement has already been suggested. If it has, add a comment to the existing issue instead of opening a new one.

How Do I Submit A (Good) Enhancement Suggestion?

Enhancement suggestions are tracked as GitHub issues.

  • Use a clear and descriptive title for the issue to identify the suggestion.
  • Provide a step-by-step description of the suggested enhancement in as many details as possible.
  • Describe the current behavior and explain which behavior you expected to see instead and why.
  • Include screenshots and animated GIFs which help you demonstrate the steps or point out the part of be.camp which the suggestion is related to. You can use this tool to record GIFs on macOS and Windows, and this tool or this tool on Linux.
  • Explain why this enhancement would be useful to most be.camp users.

Your First Code Contribution

Unsure where to begin contributing to be.camp? You can start by looking through these beginner and help-wanted issues:

Pull Requests

  • Fill in the required template
  • Do not include issue numbers in the PR title
  • Include screenshots and animated GIFs in your pull request whenever possible.
  • Follow the styles enforced by the projects linter settings.

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line