+ An approved Execution Framework Proposal (EFP) may represent the current state of affairs in the Constitution. + An EFP may or may not take effects to change any aspects of affairs in the Constitution depending + on the status of the said EFP. Other than the basic Rules defined in the Constitution, this + Policy refines further for detailed steps and procedures for EFPs. +
++ A Community Member may initiate an EFP via a Pull Request on the respective Repository of EFPs. +
++ When an EFP is being initiated, it must be in the status of "Draft". +
++ An identifier for the EFP shall only be assigned when the Pull Request of the Initiation of the EFP + is accepted under consensus. +
++ Metadata and Contents of an EFP are separately regulated in different aspects. +
++ EFPs are managed and formatted using Extensible Markup Language (XML). + The formats of EFP Documents must be defined in an XML Schema stored in the Repository. +
++ Metadata of an Entry include the title, the management information, reference anchors outside + Contents and references in Contents, where the management information includes the creation + date, categorization and document status. +
++ The creation date should be the date on or before the date at the Coordinated Universal Time (UTC), + the time the Document started being drafted by the Author. +
++ The title must not be empty, but the exact wording depends on the Author's preference under + the consensus of the Document Moderators. +
++ References used must be in topic of the Document. The uses of named and unnamed References + are separated, but the presence of them may be optional. +
++ The Format of the Contents must align with the format of the XML defined in the XML Schema. +
++ The first section is advisory to be an Introduction to the Document being introduced, + with the section heading of "Introduction". It should describe the brief abstract about + the topic the EFP is relevant to, and be kept short but descriptive. +
++ The last section of contents may be a section with a heading of "See also" for readers' + interests and references for advisory uses. +
+
+ All EFP Entries are stored in a directory named efp in the root.
+ Each EFP Entry in the directory should be stored with its own subdirectory named
+ efpXXX, where XXX is a three-digit number assigned identifier
+ of the Entry, with leading zeros filled if any.
+
+ All the affiliated files and the XML Document of the EFP itself should be stored in its directory
+ for its Entry. The main XML Document shall be stored as a file named main.xml in the
+ Entry directory.
+
+ The XML Schema is defined in efp.xsd, and a template of an XML file of an empty EFP
+ is stored in template-efp.xml in the root.
+
+ When EFPs are firstly created, they are in the status of "Draft". +
++ If an EFP may be effective, it may turn into the status of "Provisional" while the Contents + are still mutable. Once EFPs became "Provisional", they may not turn back to "Draft" by any mean. +
++ After reviewing and revisions, an EFP may become "Final" as finalized, and thus immutable. + This means such EFP is confirmed under the consensus of associated parties. +
++ Further revisions and changes regarding the concerning finalized EFP should be conducted + by proposing new EFPs updating or obsoleting the original EFP instead. +
++ A "Draft" or "Provisional" EFP may be "Deferred" when it is paused and its + development may be postponed until future evaluation for continuation. Even if an EFP is + logically "canceled", it would still be assigned to this status but with the implied meaning of being + "indefinitely deferred". This would allow potential pick up of the EFP. If there is a replacement EFP, + the EFP could be marked as "Obsoleted" by the other EFP. +
++ EFPs are up to public's supervision when initiation or modification is published via Pull Requests. +
++ EFPs would undergo peer reviews and may include Executives' oversight depending on the contents. +
++ EFPs must be approved by the Moderators, and may require Executives' approvals for authoritative + proposals depending on Moderators' considerations. +
++ EFPs with a status other than "Final" may be changed in any way, without restriction, + but dedicated modifications to a particular EFP must be organized in a single Pull Request. +
++ Unless necessary, a Pull Request should only modify one EFP Entry. +
++ Once EFPs are finalized, only subtle and trivial changes are allowed to the Contents and + their affiliated files. +
++ Changes to Metadata are allowed, but changes to Contents are limited. +
++ Subtle and trivial changes include errata, corrections of intended wordings and meanings. + However, sentence structure is not recommended to be changed, and any change to + organizations of paragraphs is prohibited. +
++ An EFP must be created to track and conduct the Amendments of Formatting of any Governance Document + System. +
++ Rendering of EFPs should be done by generating Extensible HyperText Markup Language (XHTML) format + according to the XML contents of the Documents. The resultant files are to be deployed to a static site. + Those generated files should not be tracked by the Version Control System (VCS). +
++ Assistant or helper scripts or tools may be introduced for developers' or authors' convenience. +
++ All Pull Requests regarding changes to EFP Entries are under regulation in the following clauses. +
++ When a Pull Request related to an initiation or modification to a particular EFP, its title + must be prefixed with "[EFP N]" and a space, with the Rules of using identifiers. + Its Pull Request identifier number must be recorded in the EFP Document Metadata. +
++ When a Pull Request only changes Metadata of EFPs without any changes to Contents, it may + not be prefixed with an EFP identifier by the above clause. +
++ Generally, when referring to a particular EFP, one may use "EFP N", where N is + a positive integral identifier of the EFP without any leading zero. +
++ In the Repository, if there is any Issue or Discussion relates to any particular EFP, + it may be mentioned in the titles by starting with "[EFP N]" by the above clause. +
+
+ If possible, the EFPs may also be linked in the article contents, by using
+ [EFP N](https://...) (in Markdown) or
+ <a href="https://...">EFP N</a> (in HTML), where
+ the hyperlink address is the rendered webpage of the EFP.
+
+ When changes to existing proposed EFPs are highly significant, separate EFPs that Updates + the target EFPs may be issued, without replacing the presence of the existing EFPs. + Updating EFPs may introduce additional definitions, clarifications, extensions, or amendments + that complement or alter the original Documents. The Updates may address specific aspects, + propose new features, or clarify significant ambiguities without rewriting entire proposals. + The target EFPs are described to be Updated by the Updating EFPs. +
++ When an initiation of an EFP replaces the presence or effectiveness of another EFP, such new EFP + is described to supersede and Obsolete the past EFP. The target EFP is then Obsoleted. + In the absence of concept of withdrawing EFPs, an EFP may be issued to Obsolete the target EFPs. + Obsoleting EFP may not supersede the target EFP, but withdraw its position. +
++ When an EFP involves a thematic relation with another EFP, such EFP may be Derived from + the other EFP. Such derivation or derivative must be in a strong topic relation with the Deriving + EFP. This is different from referencing, while in this case, the entire Derived EFP may be + related to the other EFP. However, overarching proposals are not applicable to be described to + Derive to any derivation or derivative. +
++ The Type of EFP depends on intended purposes of the proposals. If an EFP is to propose anything + that is new, planning or changing to anything, it should be "Formal"; otherwise, + it should be "Informational". +
++ Formal EFPs may still contain non-normative information for examples, clarifications, + suggestions, recommendations or significant comments. Certain information may be purely for + demonstrative purposes without any actual implementations or executions. +
++ Executive and Governance workflows are always classified to be "Governance". + Administration-related proposals may also be classified to this Category. +
++ Overarching proposals for the Architecture and proposals involving relationships and interoperability + between different Executive or Governance Entities, or management of Projects, are classified as + "Organization. +
++ Execution proposals special to a particular Project or a range of Projects with a theme, + are classified as "Project". This includes initiations and directions of Projects, + executions within the Project(s), and shutdowns of Projects. + However, this does not include changes involving adscription of Projects; for such, separate proposals + are recommended. +
++ General standards and specifications without specific references to certain Projects should + be classified as "Standard. Adapting proposals of such should be classified depending + on the adapting targets and scopes, also the natures of the standards or specifications. +
++ Other proposals do not belong to any aforementioned Categories should be classified as "General". + However, this Category should be carefully considered. Proposals under this Category may not function + or be regarded to contain any execution meanings by any means. A new Category may be proposed + if such case occurs while such proposals require executions or attentions. +
+