Skip to content

Latest commit

 

History

History
95 lines (61 loc) · 4.74 KB

CONTRIBUTING.md

File metadata and controls

95 lines (61 loc) · 4.74 KB
Raw

Introduction

First off, thank you for considering contributing to Code+Design's website. It's people like you that make Code+Design such a great community.

Following these guidelines helps to communicate that you respect the time of the project leaders managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.

What contribution are we looking for?

This website is an open source project for the youth hackathons organized by Code+Design and we love to receive contributions from our community — you! There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests or writing code which can be incorporated into Elasticsearch itself.

Ground Rules

  • Use English only, but do never translate German text which appears on the website itself
  • Report one bug per Issue
  • Keep feature versions as small as possible, preferably one new feature per version.
  • Be welcoming to newcomers and encourage diverse new contributors from all backgrounds.

Your First Contribution

  • Unsure where to begin contributing to this website? You can start by looking through these beginner and help-wanted issues which should only require a few lines of code or text.
  • Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
  • At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first 😸
  • If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.

Getting started

  1. Create your own fork of the code
  2. Do the changes in your fork
  3. If you like the change and think the project could use it: Send a pull request.
  4. Indicate whether your pull request is a bug fix or a feature request

As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. As long as the change does not affect functionality, some likely examples include the following:

  • Spelling / grammar fixes
  • Typo correction, white space and formatting changes
  • Comment clean up
  • Changes to ‘metadata’ files like gulp, netlify.toml, .gitignore, build scripts, etc.
  • Moving source files from one directory or package to another

How to report a bug

When filing an issue, make sure to answer these three questions:

  1. What did you do?
  2. What did you expect to see?
  3. What did you see instead?

If you find a security vulnerability, do NOT open an issue. Email [email protected] instead.

How to suggest a feature or enhancement

If you find yourself wishing for a feature that doesn't exist on this website yet, open an issue with the subject Feature: Describe Your Feature Here and answer these three questions:

  • What should it do?
  • Why do you need it?
  • How should it work?

Code review process

The project managers look at Pull Requests on a weekly basis and will give written feedback on the pull request itself. After feedback has been given we expect responses within two weeks. After two weeks we may close the pull request if it isn't showing any activity.

Commit Messages

Start your commit message with one of the following active verbs

  • Add = Create a capability e.g. feature, test, dependency.
  • Cut = Remove a capability e.g. feature, test, dependency.
  • Fix = Fix an issue e.g. bug, typo, accident, misstatement.
  • Bump = Increase the version of something e.g. dependency.
  • Make = Change the build process, or tooling, or infra.
  • Start = Begin doing something; e.g. create a feature flag.
  • Stop = End doing something; e.g. remove a feature flag.
  • Refactor = A code change that MUST be just a refactoring.
  • Reformat = Refactor of formatting, e.g. omit whitespace.
  • Optimize = Refactor of performance, e.g. speed up code.
  • Document = Refactor of documentation, e.g. help files

The content of the commit message should always tell, what the commit does. Chris Beams recommmends the following:

A properly formed Git commit subject line should always be able to complete the following sentence:

If applied, this commit will your subject line here For example:

If applied, this commit will refactor subsystem X for readability If applied, this commit will update getting started documentation If applied, this commit will remove deprecated methods If applied, this commit will release version 1.0.0 If applied, this commit will merge pull request #123 from user/branch