Welcome to the Cloud Native Telecom Initiative (CNTi) Best Practices Focus Area. This is an open, public group welcoming anyone who would like to help identify cloud native best practices for networking applications. We're glad you're here!
To learn about this focus area and our different collaboration tools, read the wiki.
We welcome many different types of contributions including:
- General improvements to documentation
- Use cases and user stories (these are used to provide context for and select best practices)
- Definitions
- CNTi Best Practices
- Gap Analysis
The CNTi Best Practices Focus Area doesn't develop any code, but its work feeds into many groups that do develop code both upstream and downstream. If you want to take the work of the CNTi Best Practices and put it into code, check out:
- CNTi Test Catalog is the place for test cases used in best practices
- Kubernetes Network Plumbing implements a common standard addressing how one may attach multiple networks to pods in Kubernetes
- Kubernetes SIG Network is responsible for the components, interfaces, and APIs which expose networking capabilities to Kubernetes users and workloads
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 want to 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.
- Go to the GitHub Discussion board
- Participate in existing discussions
- Add new discussion topics
- Reference Issues, PRs, and existing content from the Best Practices repository
Review, contribute to, create new GitHub issues.
We have good first issues for new contributors and help wanted issues suitable for any contributor. good first issue has extra information to help you make your first contribution. help wanted are issues suitable for someone 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 the TSC members.
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.
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.
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. This repository also contains a Makefile for running linting tasks locally. Executing
make lintis another way to check your work before GitHub actions.
Reviews and comments on open Pull Requests are always appreciated. A minimum of 3 community approvals, from at least 2 different companies, are needed to merge PRs so your review is greatly appreciated.
One of our values is "Commit first, improve later". Once a commit has been made you can make suggestions for changes directly in the PR to help us move forward faster together.
Where the 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.
- Once you have made your change or added new content
- Ensure you are up to date with the
mainbranch of the cnf-wg repository - Open a new Pull Request
- Choose at least 3 reviewers OR choose a TSC member who will find reviewers for you
- Reviewers will review the PR and give their feedback: approve, request change, comment w/o approval
- After 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.
Reviewers - Any community member
- 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 for your participation. We appreciate your help and look forward to collaborating with you!