Designated Sections

Designated Sections Illustration

Designated Sections Selection Guidance

_Approved 2014 Dec 2_

The Interop Working Group identified 10 selection criteria. The first seven are technical from the TC and last three allow the Board to resolve issues without needing a technical judgement.

1. Designated if the code provides the project external REST API

2. Designated if the code is shared and provides common functionality for all options

3. Designated if the code implements logic that is critical for cross­platform operation

4. NOT Designated if project design explicitly intended this section to be replaceable

5. NOT Designated if code extends the project external REST API in a new or different way

6. NOT Designated if code is being deprecated

7. NOT Designated if code interfaces to vendor­specific functions

8. NOT Designated by Default

   1. Unless code is designated, it is assumed to be undesignated.

   2. This aligns with the Apache license.

   3. We have a preference for smaller core.

9. Designated by Consensus

   1. If the community cannot reach a consensus about designation then it is considered undesignated.

   2. Time to reach consensus will be short: days, not months

   3. Except obvious trolling, this prevents endless wrangling.

   4. If there’s a difference of opinion then the safe choice is UNdesignated.

10. Designated is Guidance

    1. Loose descriptions of designated sections are acceptable.

    2. The goal is guidance on where we want upstream contributions not a code inspection police state. Guidance will be revised per release as part of the Interop Working Group process.

Designated Sections

Effective April 2015, approved Designated Sections are maintained in the Board approved Interoperability Guidelines. The 2015.03 Guideline was set to match the Board action of 2014 December 2.

Please see the current Guidelines to determine which Designated Sections apply.