Skip to content

Latest commit

 

History

History
111 lines (69 loc) · 7.2 KB

CONTRIBUTING.md

File metadata and controls

111 lines (69 loc) · 7.2 KB
Raw

Contributing to the CNTi

Welcome to the Cloud Native Telecom Initiative (CNTi). This is an open, public project welcoming anyone who would like to help in one or more of our focus areas. Our goal is to advance cloud native networking including developing best practices, maintaining a testing catalog, and providing vendor neutral certification. We're glad you're here!

To learn more about our focus areas and our different collaboration tools, please visit our focus area wiki pages:

What to Contribute?

We welcome many different types of contributions including:

Best Practices:

Test Catalog:

  • General improvements to our documentation
  • Code new tests, test enhancements, and bug fixes
  • Example CNFs
  • Bug reports

Certification:

  • General improvements to our documentation
  • Become a reviewer and help with certification of vendors who successfully demonstrate adherence to cloud native best practices

Not sure if you can contribute with anything above? Feel free to join our meetings and discussions anyway. There are always new ways to contribute to our growing community.

How to Contribute

Join our Meetings

Absolutely everyone is welcome to come to any of our meetings. You never need an invite to join us. In fact, we want you to join us, even if you don’t have anything you feel like you can contribute. Just being there is a good start!

Over time, we hope that you feel comfortable voicing your opinions, ideas and providing feedback with the community. Sharing your own ideas, and experiences can help in ways you might not initially realize.

Check the respective focus area wikis for more details on when we meet for Best Practices, Test Catalog, and Certification.

Join a GitHub Discussion

Join an existing discussion or create a new one:

Best Practices:

Test Catalog:

Certification:

Find an Issue

Review, contribute to, and create new issues for Best practices, Test catalog, or Certification

We have tagged "good first issues" for new contributors and "help wanted" issues suitable for any contributor. "Good first issues" have extra information to help you make your first contribution. "Help wanted" issues are suitable for anyone who isn't a core maintainer and is good to move onto after your first pull request.

Sometimes there won’t be any issues with these labels. That’s ok! There is likely still something for you to work on. If you want to contribute but you don’t know where to start or can't find a suitable issue, you can reach out to one of our TSC members who will be happy to help identify a suitable issue to work on.

Once you see an issue that you'd like to work on, please post a comment saying that you want to work on it. Something like "I want to work on this" is fine.

Submit Pull Requests

Pull Requests are always welcome, even for small fixes like typos. Check What to Contribute above for more information about what kind of PRs we are looking for.

Pull Request Checklist

When you submit your pull request, or you push new commits to it, our automated systems will run some checks on your new contribution. We require that your pull request passes these checks, but we also have more criteria than just that before we can accept and merge it. We recommend that you check the following things locally before you submit your change:

  • We use GitHub Actions to test all pull requests. We prefer that all tests succeed on a pull request before it is merged. Our repositories also contain a Makefile for running linting tasks locally. Executing make lint is another way to check your work before GitHub actions.

Review/Comment on Pull Requests

Reviews and comments on open Pull Requests are always appreciated. A minimum of 3 community approvals, from at least 2 different companies, are required to merge PRs in any of our repositories - so your review is greatly appreciated.

Where a comment is better expressed as a proposed change, the change can be made directly either by editing the file (right hand "..." -> "edit file" for larger changes, or the "document-with-+-" icon above the comment window for smaller ones). The author can accept these changes directly, which is much easier for them than writing a change themselves.

Steps for Creating a New PR

  • Once you have made your change or added new content
  • Ensure you are up to date with the main branch of the repository
  • Open a new Pull Request in the repository of the correct Focus Area: i.e. Best Practices, Test Catalog, or Certification
  • Choose at least 3 reviewers OR choose a TSC member who will help to find reviewers for you

Steps to Accept a PR

  1. Reviewers will review the PR and give their feedback: approve, request changes, or comment w/o approval
  2. After the required number of approvals from reviewers is reached the PR may be merged

Anyone with merge access can merge the PR after the item has been approved.

Acceptance Criteria for Contributions

Reviewers - Any contributor of respective repository

  • Everyone in the community is able to and encouraged to do PR reviews.
  • A minimum of 3 community approvals, from at least 2 different companies, are required before a PR can be merged.

Thank you

Thank you for your participation. We appreciate your help and look forward to collaborating with you!