A shout-out to @Chris Donley for much of the content found here 

What is a project?

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

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:

1. WHO will be doing the work?

2. WHAT do you propose doing?

3. WHEN do you plan to deliver it?

4. WHERE will you put your deliverables? 

5. WHY should we consider doing this?

6. HOW does this fit into our architecture?

• What is the problem?

• Why can’t it be solved in existing projects?

• How do you propose we solve it?

• 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.

• 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.