Seed code preparation:

1. Check dependency license
   1. Make sure they are compatible with the contribution license
2. Remove company proprietary and internal information
1. Internal information may include internal email addresses, URLs, etc
3. Include LICENSES.txt file at root of the repo
   1. For Apache 2 and Creative Commons 4 licenses:  LICENSES.txt
   2. For O-RAN Software License and Creative Commons 4 licenses: (to be added)
4. Include license and copyright claim at the beginning of every source code file
   1. For Apache 2 (using language specific code comment format)

################################################################################
#   Copyright (c) [years] [company name]                                       #
#                                                                              #
#   Licensed under the Apache License, Version 2.0 (the "License");            #
#   you may not use this file except in compliance with the License.           #
#   You may obtain a copy of the License at                                    #
#                                                                              #
#       http://www.apache.org/licenses/LICENSE-2.0                             #
#                                                                              #
#   Unless required by applicable law or agreed to in writing, software        #
#   distributed under the License is distributed on an "AS IS" BASIS,          #
#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.   #
#   See the License for the specific language governing permissions and        #
#   limitations under the License.                                             #
################################################################################

1. 1. For O-RAN Software License:  (to be added)

Repo creation:

1. Completing the columns under "Source code repos"
2. Review your proposal with the Requirements and Software Architecture committee
3. ToC approval of the creation and committers
4. Making request to Linux Foundation

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. 
• Draft a project proposal
• Meet with the RSAC committee 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 TOC 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 TOC at least two weeks in the future (you can do that yourself)
  • Enter your proposal in the wiki (or email) 
  • Send email to toc@lists.o-ran-sc.org notifying the community that it has been posted and include a link to the proposal

The TOC 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, +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 ORAN-SC 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 TOC 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 proposal 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?

The Overview

• What is the problem?

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

• How do you propose we solve it?

The Architecture

• How does your proposal fit with the existing ORAN-SC 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 ORAN-SC 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 

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

Source: Credit to ONAP community for new Project Proposal page guidelines, which we have replicated.