Skip to content

Latest commit

 

History

History
89 lines (61 loc) · 5.01 KB

CONTRIBUTING.md

File metadata and controls

89 lines (61 loc) · 5.01 KB
Raw

Table of Contents

  1. Contributing to Tyk
  2. Our SLA for issues and bugs
  3. Filling an issue
  4. Contributor License Agreements
  5. Guidelines for Pull Requests
  6. Project Structure
  7. Building and Running test
  8. Coding Conventions
  9. Resources
  10. Technical guidance to update doc pages yourself

Contributing to Tyk

First: if you're unsure or afraid of anything, just ask or submit the issue or pull request anyway. You won't be yelled at for giving your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions and don't want a wall of rules to get in the way of that.

However, for those individuals who want a bit more guidance on the best way to contribute to the project, read on. This document will cover what we're looking for. By addressing all the points we're looking for, it raises the chances we can quickly merge or address your contributions.

Our SLA for issues and bugs

We do value the time each contributor spends contributing to this repo, and we work hard to make sure we respond to your issues and Pull request as soon as we can.

Below we have outlined.

Filling an issue

Before opening an issue, if you have a question about Tyk or have a problem using it, please start with the GitHub search and our community forum. If that doesn't answer your questions, and you have an idea for a new capability or if you think you found a bug, file an issue.

Contributor License Agreements

Before we can accept any PR the contributor needs to sign the TYK CLA.

Once you are CLA'ed, we'll be able to accept your pull requests. For any issues that you face during this process, please create a GitHub issue explaining the problem, and we will help get it sorted out.

Guidelines for Pull Requests

We have created a few guidelines to help with creating PR. To make sure these requirements are followed we added them to the PR form as well:

  1. When working on an existing issue, simply respond to the issue and express interest in working on it. This helps other people know that the issue is active and hopefully prevents duplicated efforts.
  2. For new ideas it is always better to open an issue and discuss your idea with our team first, before writing changing pages.
  3. Create a small Pull request that addresses a single issue instead of multiple issues at the same time. This will make it possible for the PRs to be reviewed independently.
  4. Make sure to run tests locally before submitting a pull request and verify that all of them are passing.
  5. CLA - Before we can accept any PR the contributor needs to sign the TYK CLA. Once you are CLA'ed, we'll be able to accept your pull requests. For any issues that you face during this process, please create a GitHub issue explaining the problem, and we will help get it sorted out.
  6. Tips for making sure we review your pull request faster :
    1. Keep your pull request up to date with the upstream main branch (currently called master) to avoid merge conflicts.
    2. Check the PR Agent bot for any important suggestions, spelling mistakes or typos
    3. The PR Agent bot creates a description for you. If needed, please add more info to it. Link to a GitHub issue if it exists.

Pull Request Review Schedule

PRs will be reviewed weekly, every Tuesday and Thursday. New reviews will be reviewed on Tuesdays and review responses will be done on Thursdays.

Evidently, there will be some edge cases that require urgent review. Please state the reason in the description of the PR in these circumstances.

Project Structure

Folder tyk-docs/tyk-docs/content/ contains the actual docs pages. You can ignore anything outside this folder unless you want to make Hugo changes.

Building and Running test

If you want to add tests and restrictions to our docs, you can do that by adding more GH actions under .github/workflows folder.

Coding Conventions

  • No typos
  • Use back ticks for field names like field_name
  • Use ```json for multi line code
  • TBD. This section is still a WIP

Resources

Technical guidance to update doc pages yourself

Check this technical guide for detailed explanations on how to create and update doc pages including specific GUI components.