1. ONAP Open Source Practice Codifying Upstream First with Lessons from OpenDaylight, OPNFV and OpenStack Marcus Williams - Intel
Dec 12 , 2017

2. Err on the side of too much communication
ONAP is a Cross-Geo, Multi-Team, Multi-Company, Multi-Time-zone, diverse set of people with varying skill levels working in concert to develop and release a very complex Open Source platform and set of software built on other Open Source software that is developed by an even larger set of Cross-Geo, Multi-Team, Multi-Company, Multi-Time- zone, diverse sets of people
What could go wrong?
We prevent things going wrong by communicating often and with vigor:
Asynchronous Communication
Lists
Gerrit
Synchronous Communication
IRC

3. https://lists.onap.org (Email Lists)
When in doubt, send it out (cc’ed to the list)
Keeps people in the loop with minimal effort
Creates a record of discussions, decision points and troubleshooting
Encourages others to participate in said issue, bug, feature, discussion
In Open Source, Siloed conversations = BAD
Siloed conversations encourage duplication of effort
Siloed conversations create knowledge desserts and concentrate understanding among a few
Rare instances where list should not be used
Siloed conversations:
Examples of non-list conversations:
Sensitive discussion between committers/PTLs

4. Insert Synchronous Communication Tool Name Here
Use public synchronous communication for immediate communication or communication that doesn’t merit sending to the list
Synchronous communication builds the team
Again, Siloed conversations = BAD
Rare instances where private <Insert Synchronous Communication Tool Name Here> should be used
Pick a tool and standardize
IRC? Slack? HipChat?
Does your company block said tool? Become and evangelist to get them to see the light.

5. Gerrit As Code Merge Record
Constraint – All code review on a specific change is kept in one gerrit review (more on this later)
Gerrit can be used as code merge record
Historical Record
Why did this code get in? (It introduced a bug that brought down the whole process…)
Learning tool for future contributors
Learn process of committing
Learn the type of code wanted by committers
Facilitates blaming the person who broke it (Just kidding, kind of)
Eases rollback when things go wrong

6. Everyone is a Code Reviewer
Everyone can contribute to code reviews
Commit Process (commit message standards, keeping reviews in the same gerrit review, documentation)
General good coding practices
Internal Consistency of a chunk of code
Even +1 with no comments is helpful
Positive comments are also useful – “+1 – I really liked your use of recursion here.”

7. +2, +2, +1 is the new +2?
Higher standards for merging code = Better code?
Higher standards have higher cost
Probably produce better code
Varying standards used to merge code across open source projects:
OpenStack Kolla requires +2, +2, +1
Often resolves as two committers +2 and one contributors +1
OpenDaylight Integration requires only +2 but committers often wait for another +1 or +2 before merge

8. Dummy's Guide to Reviewing with Gerrit
Reviewing has high cost
At each chance encourage contributors to make smaller manageable contributions to facilitate easy, thorough and quick review
If pressured for time reduce time cost by turn reviewing process into iterative process
Review patch to find two or three issues and post constructive comments about issues
Wait for contributor to update patch
Review patch again
Rinse and repeat until patch is ready for merge
Keep each code contribution on a single subject in the same gerrit review
Discourage contributors from abandoning patches, to push new patches when they are just updating to address feedback from a review
Usually a side-effect of lack of knowledge of git or the review process
Higher cost for committer, as they don’t have review history to inform review
-1 or -2 Stops review process until updates from contributor

9. No Self-Commits No Self-Commits (In case of emergency self-commit)
Self-Committing is BAD for Open Source
It single handedly defeats one of Open Sources greatest strengths: Code Review
If you are thinking about self-committing – ask yourself these questions:
1) Have I tried to contact all of the committers who could merge this?
2) Is it absolutely urgent that I get this code in right now?

10. Upstream First. What's that?
Code should be submitted upstream as early as possible in the development cycle so that feedback can be given and direction adjusted to adhere to project standards and code feedback
The original author(s) of the code should be involved in the process and modify code to fit upstream standards, practice and feedback
The author of the code should contribute and interact with the project/community where his code is pushed – ensuring a healthy community and give/take balance

11. ONAP is littered with committers
Seriously.
Approved Project pages are filled with committers from project creation but only a few on each project are active
We should remove excess committers to make room for merit based promotions
In the future we should be very careful about committers in project proposals

12. Hey, I have Committer Issues (duties)
Participate in meetings
Show up
Take meeting minutes
Have an opinion
Review code
Make sure project process is followed (commit messages, keep commits in single gerrit, engender knowledge of the process)
Become an expert in an area of the code and be a rockstar reviewer for that area
Make constructive comments and explain how contributors can fix issues
Help document the process
Document how the project team works in gerrit, wiki, lists, in person
Submit Code
Help Develop across the project (no just your assigned silo)
Role model code submission practices
Fill in the gaps
Help the PTL by volunteering
Make sure nothing is missed by the project

13. What happened in that meeting? I was bungee jumping…
Projects should take weekly meeting minutes and cc the list
An Open Source project’s discussions, decisions and meetings should be documented and openly available
One off meetings should also be summarized and sent to the list by a participant
Lowers bar to entry for new contributors
Allows others outside the project to stay abreast of projects status, discussion and decisions and to contribute when warranted
Documents project decisions and facilitates future review for project participants
Serves as a resource for those who miss project meetings

14. Learn from Projects that Came before
None of the issues ONAP faces are new
Let’s look to other Open Source Projects as a guide to extending and improving ONAP open source practices

15. Thank You Marcus Williams – Network Software Engineer – Intel
IRC: mgkwill
Twitter: mgkwill
Web: