The Board of Directors of OpenDaylight has set in place the following policies to govern the operation of the Technical Steering Committee (TSC).  These policies relate to release processes, technical scope, business goals, etc. The TSC will, to the best of its ability, adhere to these policies.  In cases where the TSC makes a judgment that the goals of OpenDaylight are better served by making exceptions to these policies, it is expected that the TSC will make these exceptions and indicate their reasons to the board at the next board meeting,

The following relate to the projects initiated by the TSC and the artifacts created therein.

• Singularity: To the extent possible, there should be no overlap between the goals of the core projects and artifacts created by them
• Cohesiveness: The artifacts created within each mature project should connect appropriately to other mature/core projects to form a cohesive system.  (It is understood that this will not apply to artifacts that are stand-alone by design.)

The following relates to the choice of projects, assignments of tasks and delivery of code.

• Simultaneous Release: The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals.

The following relate to the operation of the TSC:

• Communication: All communication between and within projects will be in a fair, open and consistent fashion.
• Openness: The TSC should ensure that all technical decisions are made in an open and transparent fashion. Notes from all meetings as well as other TSC information can be found on the TSC wiki page.

Scope: Projects chosen by TSC are limited to the following areas:

• The OpenDaylight controller
• Software for forwarding elements
• Southbound plugins to enable the controller to speak to the OpenDaylight supplied and other network elements
• Northbound plugins to expose interfaces to those writing applications to the controller
• Network services and applications intended to run on top of the controller, integration between the controller and other elements, and
• Support projects such as tools, infrastructure, or testing.
• Plugins for inter-controller communication