A code review is the primary forum for getting and giving feedback. Patches almost always require iterative feedback/fix cycles. Large patches in particular often require input from many people over a long period before they are ready to be merged.

There are two common mistakes that organizations new to open source make. Here’s why they cause problems, and what to do instead:

Steps to Upstreaming - “I have a great idea for a feature... now what?”

The engagement model for contributing new code may vary slightly from Project to Project. (For clarity, typically, Project refers to the collective platform, such as ODL or ONAP, whereas project refers to the individual development efforts or repositories approved as part of the Project.)

Review the various LFN Project sites to identify where your contribution fits best. Within that Project, Review the list of existing projects/repositories to see where you believe your contributions can be best aligned with what you want to do. You have the best chance at a successful community engagement if you take the following steps:

Contact the lead Committer or Project Technical Lead (PTL) for the project you’re interested in joining

The PTL will have the best knowledge of what that group of developers care about. Introduce yourself and provide an overview of your idea. Your conversation with the PTL will be the beginning of an ongoing dialogue, not a one- shot conversation.

If you are uncomfortable with contacting an unfamiliar PTL directly, contact the LFN Program Manager for the Project and ask her/him to make an introduction. They will be happy to do so.

Ask Questions

Pitch your idea to the community

Listen to the Feedback. All of it.

The real power of open source development is that many differing perspectives will generate the best outcomes. This may involve highlighting new functionality that never occurred to you, or uncover a different use case that your proposal cannot address. Take the community’s input to heart because when comes time to seek approval, if there is some key element that you failed to address, someone will bring that up.

Make iterative adjustments

Seek Approval

This is often the easiest part of the process if you have been diligent and engaged with the community up till this point. In theory, the community should be well aware of the proposal, you should have contributors lined up, and advocates on your side.

After your proposal has been published for the community to review and comment on, you will typically present it to the Technical Steering Committee for your Project. Don’t be surprised if you receive feedback from a different set of people during this period. If your proposal has been effectively vetted with the community, you can usually refer to answers previously provided in a public forum, and be reasonably confident of getting final approval.

Have Questions? Please contact your Project's Technical Program Manager.