Skip to content

Latest commit

 

History

History
286 lines (209 loc) · 15.6 KB

CONTRIBUTING.md

File metadata and controls

286 lines (209 loc) · 15.6 KB
Raw

Contributing to DerekKent.com

🇺🇸🎉 Thank you for your support! 🎉🇺🇸

The following is a set of guidelines for contributing code to the campaign. You can find all public projects related to the campaign hosted in the DerekKent group on GitLab and the DerekKent organization on GitHub.

These are just guidelines, not rules. Use your best judgment and feel free to propose changes to this document in a merge request.

Table Of Contents

What should I know before I get started?

How Can I Contribute?

Styleguides

Additional Notes

What should I know before I get started?

Code of Conduct

This campaign is welcoming of everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, personal appearance, race, religion, or sexual identity and orientation. Volunteers and contributors to this campaign are expected to foster and uphold that welcoming environment.

Remember there's another person on the other side of the screen.

License

This project is licensed under the CC0 1.0 Universal License, which effectively means that it waives all Copyright claims and is part of the public domain. By contributing to this project, you agree to release all such contributions under the CC0 1.0 license.

That means others may freely reuse and redistribute your contributions for any purposes without being required to provide you attribution or compensation (although nor are they precluded from doing so).

Contributors

A humans.txt file is generated with every release from the project's git log as a small token of thanks to everyone who has generously donated their time, sweat, and code to our success.

How Can I Contribute?

Reporting Bugs

You don't have to know how to code to contribute. We make every effort to review and test code, but with the huge variety of different devices and browsers, bugs are an inevitability. If you find an issue, chances are other people are going to be affected by it as well. By reporting issues, you help us improve the user experience and better reach more people to spread our message.

Following the below guidelines helps us more quickly understand and address the issue you're reporting.

Before Submitting A Bug Report

How Do I Submit A (Good) Bug Report?

Bugs are tracked as GitLab issues. After you've determined you're reporting a new issue, create an issue and provide the following:

  • A clear and descriptive title
  • The URL(s) (web address) where the issue can be replicated, if applicable
  • The exact steps to follow to reproduce the problem
  • A description of the current behavior you observed and the expected behavior
  • Screenshots of the steps and/or issue, as applicable
  • The name and version of the browser(s) you used
  • The name and version of the Operating System you used
  • A printout of anything logged to the console (if you know how)

Template For Submitting Bug Reports

[Short description of problem here]

URL: [URL where the problem can be seen here]

**Reproduction Steps:**

1. [First Step]
2. [Second Step]
3. [Other Steps...]

**Expected behavior:**

[Describe expected behavior here]

**Observed behavior:**

[Describe observed behavior here]

**Screenshots**

![Screenshots which demonstrate the problem](url)

**Browser and version:** [Enter the browser and version used here]
**OS and version:** [Enter OS name and version used here]

**Additional information:**

* Problem can be reliably reproduced, doesn't happen randomly: [Yes/No]

Suggesting Enhancements

Enhancements can be big or small. Is there a language you think the project should be translated into? Let us know! Do you think the font size on a page is too small to read easily? That's useful feedback too! If you have an idea to improve the project, or just want to knock around a few ideas, don't hesitate to submit your thoughts.

Following the below guidelines helps us best understand and implement your idea.

Before Submitting An Enhancement Suggestion

How Do I Submit A (Good) Enhancement Suggestion?

Enhancement suggestions are tracked as GitLab issues. After you've determined you're suggesting a new enhancement, create an issue and provide the following:

  • A clear and descriptive title
  • Steps explaining the enhancement, if applicable
  • A detailed explanation of the suggested enhancement and current behavior
  • Mockups of the suggested enhancement, if applicable and you're able
  • An explanation why this enhancement would be useful

If you'd like to suggest a change to a policy position or suggest a position be taken on a policy that isn't covered, you're welcome to open an issue here for public discussion.

Template For Submitting Enhancement Suggestions

[Short description of suggestion]

**Steps which explain the enhancement**

1. [First Step]
2. [Second Step]
3. [Other Steps...]

**Current and suggested behavior**

[Describe current and suggested behavior here]

**Why would the enhancement be useful to most users**

[Explain why the enhancement would be useful]

Merge Requests

  • Include screenshots in your merge request whenever possible.
  • Follow the JavaScript and SCSS styleguides.
  • End files with a newline.
  • Create well-crafted git commits that provide a useful and accurate history.
  • Pass all linters and Ava unit tests (npm test).

Styleguides

Git Commit Messages

  • Limit the subject (first) line to 50 characters or less.
  • Capitalize the subject line.
  • Use the imperative mood in the subject line.
  • Do not end the subject line with a period.
  • Separate subject from body with a blank line.
  • Wrap the body at 72 characters.
  • Use the body to explain what and why vs. how (if useful).
  • Reference related issues and merge requests.

Read more about how to write a good git commit message.

JavaScript Styleguide

  • Prefer ES2015 classes over prototypes.
  • Use strict equality checks (=== and !==).
  • Prefer arrow functions =>, over the function keyword.
  • Prefer function definitions over function expressions.
  • Use semicolons at the end of each statement.
  • Prefer single quotes.
  • Use PascalCase for classes, lowerCamelCase for variables and functions, SCREAMING_SNAKE_CASE for constants, and symbols for private variables and functions.
  • Prefer template strings over string concatenation.
  • Prefer promises over callbacks.
  • Prefer array functions like map and forEach over for loops.
  • Use const for declaring variables that will never be re-assigned, and let otherwise.
  • Avoid var to declare variables.
  • Use a trailing comma after each item in a multi-line array or object literal, except the last item.
  • Use the one true brace style.
  • Indent using 4 spaces.

SCSS Styleguide

  • List properties in alphabetical order.
  • Avoid deeply nesting rules and selectors.
  • Prefer flexible, scalable units (rem, em, vw...) over px.
  • Prefer rem over em unless you really mean em.
  • Include a leading zero for magnitudes between -1 and 1.
  • Utilize globally defined variables wherever possible.
  • Ensure rules are properly namespaced to a page when appropriate.
  • Indent using 4 spaces.

Additional Notes

Issue and Merge Request Labels

Type of Issue and Issue State

Label Name Search Link Description
bug search Confirmed or likely bugs.
accessibility search Issues impacting accessibility.
enhancement search Suggested enhancements.
policy search Suggested policy change or new policy position.
question search Questions more than bug reports or feature requests.
feedback search General feedback more than bug reports or feature requests.
help-wanted search Issues where community help would be appreciated.
more-information-needed search More information needs to be collected about these problems or feature requests (e.g. steps to reproduce).
needs-reproduction search Likely bugs that have yet to be reliably reproduced.
blocked search Issues blocked by other issues.
duplicate search Issues which are duplicates of other issues.
wontfix search Issues where no changes will be made for reasons addressed in comments on the issue.
invalid search Issues which aren't valid (e.g. user errors).

Topic Categories

Label Name Search Link Description
documentation search Related to any type of documentation.
performance search Related to performance.
security search Related to security.
ui search Related to visual design.
chrome search Related to viewing the site on Chrome.
safari search Related to viewing the site on Safari.
firefox search Related to viewing the site on Firefox.
edge search Related to viewing the site on Edge.
ie search Related to viewing the site on IE.
git search Related to Git functionality (e.g. problems with gitignore).
gulp search Related to Gulp functionality.

Merge Request Labels

Label Name Search Link Description
work-in-progress search Merge requests which are still being worked on.
needs-review search Merge requests which need code review.
under-review search Merge requests actively under review.
requires-changes search Merge requests which need changes based on review comments.
needs-testing search Merge requests which need manual testing.