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.
Designated if the code provides the project external REST API
Designated if the code is shared and provides common functionality for all options
Designated if the code implements logic that is critical for crossplatform operation
NOT Designated if project design explicitly intended this section to be replaceable
NOT Designated if code extends the project external REST API in a new or different way
NOT Designated if code is being deprecated
NOT Designated if code interfaces to vendorspecific functions
NOT Designated by Default
Unless code is designated, it is assumed to be undesignated.
This aligns with the Apache license.
We have a preference for smaller core.
Designated by Consensus
If the community cannot reach a consensus about designation then it is considered undesignated.
Time to reach consensus will be short: days, not months
Except obvious trolling, this prevents endless wrangling.
If there’s a difference of opinion then the safe choice is UNdesignated.
Designated is Guidance
Loose descriptions of designated sections are acceptable.
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.
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.