diff --git a/epc/1/1.xml b/epc/1/1.xml new file mode 100644 index 0000000..7300ad1 --- /dev/null +++ b/epc/1/1.xml @@ -0,0 +1,285 @@ + + + + + + + +

+ 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. +

+ +
+
+ +

+ 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. +

+ +
+
+ +

+ 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. +

+ +
+ +