d8fb682a2b
At the Board of Directors meeting on April 24, 2016 the Board of Directors indicated that as DefCore has evolved it's focus on interoperability and it's working structure, it's name may be a source of some confusion to those outside of the community or who are new to the community. The Board made an informal request that the DefCore Committee consider changing it's name to more clearly reflect it's focus and structure. This patch is the first step in that process. It updates references in various documents to change the name "DefCore Committee" to "Interop Working Group" as agreed at the summer 2016 DefCore Committee Sprint [1]. It should be noted that this patch should be considered a work in progress to generate discussion until the new name is approved by the DefCore Committee and the Board of Directors. Should we elect to go forward with the new name, some other actions will also need to be taken, including but not limited to: 1. We will need to consider updating references on the OpenStack wiki. 2. We will need to consider updating the name of our IRC channel, mailing list, Launchpad project, and git repository. Most of these changes will need to be carefully coordinated with the OpenStack Infrastructure team. 3. We will need to take into account external resources that point to DefCore artifacts, such as Foundation-maintained websites (such as: http://www.openstack.org/interop ). 4. We will need to coordinate with RefStack to minimize impact. 5. We will need to clearly communicate the name change to the rest of the community. Note also that I've intentionally left many historical documents that have been superceded (such as the 2015A process docs, Guidelines that are no longer used, etc) in tact. There seemed little value in spending time on them and cluttering the patch with them since they're now obsolete. [1] https://etherpad.openstack.org/p/DefCoreSummer2016Sprint Change-Id: I79d337c193e75c54d49f1d847468f6347e2ef2b3
2.1 KiB
2.1 KiB
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.
- 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.
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.