Skip to content

Latest commit

 

History

History
175 lines (126 loc) · 9.11 KB

CONTRIBUTING.md

File metadata and controls

175 lines (126 loc) · 9.11 KB
Raw

Contributing Overview

Please do! Thanks for your help improving the project! 🎈

All contributors are welcome. Please see the newcomers welcome guide for how, where and why to contribute. This project is community-built and welcomes collaboration. Contributors are expected to adhere to our Code of Conduct.

Not sure where to start? First, see the newcomers welcome guide. Grab an open issue with the help-wanted label and jump in. Join the Slack account and engage in conversation. Create a new issue if needed. All pull requests should reference an open issue. Include keywords in your pull request descriptions, as well as commit messages, to automatically close issues in GitHub.

Sections

Relevant coding style guidelines are the Go Code Review Comments and the Formatting and style section of Peter Bourgon's Go: Best Practices for Production Environments.

General Contribution Flow

In order to contribute to Meshery, please follow the fork-and-pull request workflow described here.

Issues & Pull Requests

Creating an Issue

Before creating an Issue i.e for features/bugs/improvements please follow these steps:

  1. Search existing Issues before creating a new Issue (look to see if the Issue has already been created).
  2. If it doesn't exist create a new Issue giving as much context as possible (please take note and select the correct Issue type, for example bug, documentation or feature.
  3. If you wish to work on the Issue once it has been triaged, please include this in your Issue description.

Working on an Issue

Before working on an existing Issue please follow these steps:

  1. Comment asking for the Issue to be assigned to you.
  2. To best position yourself for Issues assignment, we recommend that you:
    1. Confirm that you have read the CONTRIBUTING.md.
    2. Have a functional development environment (have built and are able to run the project).
    3. Convey your intended approach to solving the issue.
    4. Put each of these items in writing in one or more comments.
  3. After the Issue is assigned to you, you can start working on it.
  4. In general, only start working on this Issue (and open a Pull Request) when it has been assigned to you. Doing so will prevent confusion, duplicate work (some of which may go unaccepted given its duplicity), incidental stepping on toes, and the headache involved for maintainers and contributors alike as Issue assignments collide and heads bump together.
  5. Reference the Issue in your Pull Request (for example This PR fixes #123). so that the corresponding Issue is automatically closed upon merge of your Pull Request.

Notes:

  • Check the Assignees box at the top of the page to see if the Issue has been assigned to someone else before requesting this be assigned to you. If the issue has a current Assignee, but appears to be inactive, politely inquire with the current Assignee as to whether they are still working on a solution and/or if you might collaborate with them.
  • Only request to be assigned an Issue if you know how to work on it.
  • If an Issue is unclear, ask questions to get more clarity before asking to have the Issue assigned to you; avoid asking "what do I do next? how do I fix this?" (see the item above this line)
  • An Issue can be assigned to multiple people, if you all agree to collaborate on the Issue (the Pull Request can contain commits from different collaborators)
  • Any Issues that has no activity after 2 weeks will be unassigned and re-assigned to someone else.

Reviewing Pull Requests

We welcome everyone to review Pull Requests. It is a great way to learn, network, and support each other.

DOs

  • Use inline comments to explain your suggestions
  • Use inline suggestions to propose changes
  • Exercise patience and empathy while offering critiques of the works of others.

DON'Ts

  • Do not repeat feedback, this creates more noise than value (check the existing conversation), use GitHub reactions if you agree/disagree with a comment
  • Do not blindly approve Pull Requests to improve your GitHub contributors graph

Signing-off on Commits (Developer Certificate of Origin)

To contribute to this project, you must agree to the Developer Certificate of Origin (DCO) for each commit you make. The DCO is a simple statement that you, as a contributor, have the legal right to make the contribution.

See the DCO file for the full text of what you must agree to and how it works here. To signify that you agree to the DCO for contributions, you simply add a line to each of your git commit messages:

Signed-off-by: Jane Smith <[email protected]>

In most cases, you can add this signoff to your commit automatically with the -s or --signoff flag to git commit. You must use your real name and a reachable email address (sorry, no pseudonyms or anonymous contributions). An example of signing off on a commit:

$ commit -s -m “my commit message w/signoff”

To ensure all your commits are signed, you may choose to add this alias to your global .gitconfig:

~/.gitconfig

[alias]
  amend = commit -s --amend
  cm = commit -s -m
  commit = commit -s

Or you may configure your IDE, for example, Visual Studio Code to automatically sign-off commits for you:

Documentation Contribution Flow

Please contribute! Layer5 documentation uses Jekyll and GitHub Pages to host docs sites. Learn more about Layer5's documentation framework. The process of contributing follows this flow:

  1. Create a fork, if you have not already, by following the steps described here
  2. In the local copy of your fork, navigate to the docs folder. cd docs
  3. Create and checkout a new branch to make changes within git checkout -b <my-changes>
  4. Edit/add documentation. vi <specific page>.md
  5. Run site locally to preview changes. make site
  6. Commit, sign-off, and push changes to your remote branch. git push origin <my-changes>
  7. Open a pull request (in your web browser) against the repo.

Tests

Users can now test their code on their local machine against the CI checks implemented using make run-tests.

To test code changes on your local machine, run the following command:

make run-tests

Building Docker image

To build a Docker image of the project, please ensure you have Docker installed to be able to build the image. Now, run the following command to build the Docker image:

make docker

Running locally

Running meshsync locally requires an instance of NATS server running locally. First installation of NATS via NATS installation for the desired operating system or docker then running NATS server

For Linux of MacOS based systems, once you have installed nats ctl run

nats-server -m 8222

Or for Docker:

docker run --name nats --rm -p 4222:4222 -p 8222:8222 nats --http_port 8222

Alternatively, the above command has been simplified on the makefile as:

make nats

Now you can run meshsync using make file

make run

UI Lint Rules

Layer5 uses ES-Lint to maintain code quality & consistency in our UI Code.

Reviews

All contributors are invited to review pull requests. See this short video on how to review a pull request.

New to Git?

Resources: https://lab.github.com and https://try.github.com/

License

This repository and site are available as open source under the terms of the Apache 2.0 License.

About Layer5

Community First

The Layer5 community represents the largest collection of service mesh projects and their maintainers in the world.

Open Source First

Our projects establish industry standards and enable service developers, owners, and operators with repeatable patterns and best practices for managing all aspects of distributed services. Our shared commitment to the open source spirit push the Layer5 community and its projects forward.