A shout-out to Chris Donley for much of the content found here 
WIP Kenny Paul
What is a project?
| IS / HAS | IS NOT / DOES NOT |
|---|---|
|
|
Pro Tip
The TSC will always look more favorably on project proposals that address gaps in existing ONAP functionality vs. replacing existing functionality with a new proposal.
The basic steps for submitting a proposal
- Talk to community members first about the problem you think needs to be addressed.
- Fill in the template by clicking the create button in the "Draft Project Proposals" section of the wiki
- Meet with the Architecture subcommittee for an initial review
- Address any concerns raised by the Architecture subcommittee scheduling a follow-up review if necessary
- A MINIMUM OF 2 WEEKS PRIOR TO MAKING YOUR PRESENTATION TO THE TSC your submission should be considered to be locked. Nothing else should be added or changed from that point on.
- Add your proposal presentation to an upcoming TSC agenda at least two weeks in the future (you can do that yourself)
- Move your proposal from Draft Project Proposals to New Project Proposals
- Send email to tsc@lists.onap.org notifying the community that it has been posted and include a link to the proposal
The TSC considers many things when they look at approving a new project
Technology for the sake of technology won't cut it, neither will solutions in search of problems.
- Is your project addressing a real problem in the industry?
- How does this affect other projects?
- Does this advance our architecture?
- How does this fit with the next release? How about R+1 or 2?
- Does it increase our risk of delivering on time?
- Does it support multiple use case scenarios?
- Do you have enough resources?
- Are those resources new, or are you drawing resources away from other projects?
- Will this project make ONAP more attractive to service providers?
- Would this simplify or complicate end user adoption?
Best Practices for successful proposal
- Always remember this is an open source community, not contract labor. No one is required to do anything.
- Talk to people from as many different different companies as possible in advance
- Ensure participation of at least 3-4 organizations, including at least one operator (preferably more)
- Circulate draft proposals among the community to obtain feedback before presenting to the Architecture subcommittee
- Respond promptly to any questions from the community, especially after you notify the tsc list.
Things to avoid
- Changing the architecture in the project proposal- Architecture changes should be discussed in the Architecture subcommittee before the new project is ever proposed
- Duplicating, moving, or changing functionality in existing projects, UNLESS
- Unless you have the full support from the existing project team that would be impacted
- Or the other project's component was designed to be modular and you are adding a driver
- Thinking someone has made a resource commitment just because they agree with something you said
Pro Tip
Being open to feedback gives you credibility. There will of course be disagreements on solutions or approaches, but anyone that feels you are ignoring their input is unlikely to consider working with you on anything either now or in the future . If you hear an objection or concern that cannot be addressed by your proposed solution it is in your best long-term interest to respectfully highlight it publically and then provide the technical reasoning or logic that went in to your decisions.
Filling out your proposal
As you go through the template here are the things to keep in mind. Many of these are typical of the questions that you get asked over and over. A project proposal should answer six fundamental questions:
- WHO will be doing the work?
- WHAT do you propose doing?
- WHEN do you plan to deliver it?
- WHERE will you put your deliverables?
- WHY should we consider doing this?
- HOW does this fit into our architecture?
The Overview section
What is the problem?
Why can’t it be solved in existing projects?
How do you propose we solve it?
The Architecture section
- How does your proposal fit with the existing ONAP architecture?
- This is the question that will ultimately receive the most scrutiny. If that cannot be clearly explained your project won't be taken seriously.
- Failing to adequately engage the Architecture subcommittee and failing to heed their input is a losing strategy. Although the subcommittee cannot approve or disapprove a project proposal its recommendation to the TSC is highly weighted.
- If you think that the problem to be solved is fundamentally an architecture problem then bring that issue up for discussion on an Architecture call first before you ever trying to proposing a new project.
- If you think that the ONAP architecture needs to be modified in order to accommodate your project, be prepared for very long and drawn out review process that is unlikely to be approved.
The Resources section
- This page is for listing commitments. DO NOT list people that you hope will get involved, or folks that you think might benefit, or even people that may have said, "I think this is a good idea." Only list those who have signed up to work on your project. Period.
- The PTL should have had some manner of direct 1:1 conversation with everyone listed to before making a proposal.
Pro Tip
Thinking of or speaking of companies or individuals as “proposed contributors” to your project will almost always get you into trouble. It is probably best to consider it to be a binary; either they directly committed resources to work on the project to you first hand, or they did not. Comments such as, "Yes, that sounds like a good idea", "Yes, my company would like something like that", or even "Yes, I'd be very interested in your project!" are not the same as someone saying, "Yes, I can work on your project".