Skip to content

Latest commit

 

History

History
112 lines (80 loc) · 3.88 KB

contributing.md

File metadata and controls

112 lines (80 loc) · 3.88 KB
Raw

Contributing to Serverless Workflow

This page contains information about reporting issues, how to suggest changes as well as the guidelines we follow for how our documents are formatted.

Table of Contents

Reporting an Issue

If you have a question, consider opening a discussion.

To report an issue or to suggest an idea for a change that you haven't had time to write up yet, open an issue. It is best to check our existing issues first to see if a similar one has already been opened and discussed.

Suggesting a Change

Enhancements or bugs in a specification are not always easy to describe at first glance, requiring some discussions with other contributors before reaching a conclusion.

Before opening a pull request, we kindly ask you to consider opening a discussion or an issue. The community will be more than happy to discuss your proposals there.

Having the discussion or issue settled, please submit a pull request (PR) with the complete set of changes discussed with the community. See the Spec Formatting Conventions section for the guidelines we follow for how documents are formatted.

Each PR must be signed per the following section and have a link to the issue or discussion.

Fixing Typos, Spelling, and Formatting issues

Due to the amount of text a specification can have, typos, spelling, and formatting issues are pretty common. In these cases, please submit a pull request directly only with the fixes that you see fit.

Assigning and Owning work

If you want to own and work on an issue, add a comment or “#dibs” it asking about ownership. A maintainer will then add the Assigned label and modify the first comment in the issue to include Assigned to: @person

Spec Formatting Conventions

Documents in this repository will adhere to the following rules:

  • Lines are wrapped at 80 columns (when possible)
  • Specifications will use RFC2119 keywords to indicate normative requirements

Checks

Markdown style

Markdown files should be appropriately formatted before a pull request is sent out. In this repository, we follow the markdownlint rules with some customizations. See markdownlint or settings for details.

We highly encourage using line breaks in markdown files at 80 characters wide. Some tools can do it for you effectively. Please submit the proposal to include your editor settings required to enable this behavior so the out-of-the-box settings for this repository will be consistent.

If you are using Visual Studio Code, you can also use the fixAll command of the vscode markdownlint extension.

To otherwise check for style violations, use:

# Ruby and gem are required for mdl
gem install mdl
mdl -c .mdlrc .

To fix style violations, follow the instruction with the Node version of markdownlint.

Typos

In addition, please make sure to clean up typos before you submit the change.

To check for typos, you may use

# Golang is needed for the misspell tool.
make install-misspell
make misspell

To quickly fix typos, use:

make misspell-correction