+ As established in the Constitution, Executive Policy Charters (EPCs) are executive-led, versioned, + and policy-defining. They establish organizational principles, governance structures, and policies, + but must always be initiated and guided by corresponding Execution Framework Proposals (EFPs). +
++ The latest iteration of an EPC may represent the current Policies, Rules and Regulations + in the Constitution. It shall be a formal document with authoritative language. + Any Members scoped from an EPC shall obey and have obligations to follow the Contents. + Other than the basic Rules defined in the Constitution, + this Proposal refines further for detailed steps and procedures for EPCs. +
++ A full EPC identifier includes a serial number and a revision version string. + EPC Streams shall be strictly sequential for the serial number, + with the major version as the year of issue of an EPC version, + and the minor version as the sequence of issue in an EPC stream in the year. + An EPC Stream is a collection of all Versions for an EPC under the same serial number and title. + Since EPCs are versioned, new versions of an EPC may override or supersede the older versions + of the EPC series. + However, a deprecation of an EPC may not lead to or be caused by another EPC. +
++ A Community Member may initiate an EPC via an EFP within a single Pull Request. +
++ When an EPC is being initiated, it must be in the status of "Draft". +
++ Identifiers for the EFP and EPC shall only be assigned when the Pull Request of the Initiation + is accepted under consensus. +
++ Metadata and Contents of an EPC are separately regulated in different aspects. +
++ EPCs are managed and formatted using Extensible Markup Language (XML). + The formats of EPC Documents must be defined in an XML Schema stored in the Repository. +
++ Metadata of an Entry include the title, the management information and references in Contents, + where the management information includes the creation date 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. +
++ Preamble is optional, where the present depends on intention of the Author; + the Preamble shall be purely advisory and non-normative, as a brief abstract about the EPC. +
+
+ All EPC Entries are stored in a directory named epc in the root.
+ Each EPC Stream in the directory should be stored with its own subdirectory named
+ with a single decimal number as the assigned serial number of the Stream.
+
+ All the affiliated files and the XML Documents of the EPC itself should be stored in its directory
+ for its Stream. The main XML Documents shall be stored as a file named N.xml
+ in the Stream directory, with N the sequential number of the Version in the Stream.
+
+ The XML Schema is defined in epc.xsd in a root directory named schemas.
+
+ The status of an EPC Entry must be aligned with the status of its Proposal. +
++ A new iteration of Version of an EPC Stream shall be made only when the latest Version + is "Active"; otherwise, modifications shall be made to the latest Version. +
++ When EPCs are firstly created, they are in the status of "Draft". +
++ If an EPC may be effective, it may turn into the status of "Provisional" while the Contents + are still mutable. + Once EPCs became "Provisional", they may not turn back to "Draft" by any mean. +
++ After reviewing and revisions, an EPC may become "Active" as finalized, and thus immutable. + This means such EPC Entry is confirmed under the consensus of associated parties. +
++ Further revisions and changes regarding the concerning finalized EPC Entry should be conducted + by proposing new Version of the EPC updating the latest Version, or new EPC Stream 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 EPC 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 EPC. If there is a replacement EPC, + the EPC could be marked as "Deprecated" by the other EPC. +
++ When an initiation of an EPC Entry of a new EPC Stream replaces the presence or effectiveness + of another EPC, such new EPC is described to supersede and Deprecate the past EPC. + The target EPC is then Deprecated by the other EPC; + the latest Version of the replaced EPC shall be marked as "Deprecated" by the new EPC Stream. + In certain cases, an EPC Stream may be solely "Deprecated" without a Deprecating EPC + Stream, by marking the latest Version of that EPC Stream as "Deprecated". +
++ EPC Entries with a status other than "Active" may be changed in any way, without restriction, + only when there is only a single Entry in the EPC Stream, + but dedicated modifications to a particular EPC Entry and its EFP must be organized + in a single Pull Request. +
++ When there are more than one Entries in the EPC Stream and the latest Entry is not "Active", + only changes to the Contents and subtle and trivial changes to other Parts are allowed; + the Titles must remain immutable and unchanged. +
++ For changes to "Active" EPC Entries, only changes to Metadata are allowed; + subtle and trivial changes to non-latest Versions are preferred to be in new iterations. +
++ 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. +
++ Unless necessary, a Pull Request shall, at most, only modify one EFP Entry and one EPC Entry. +
++ 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 EPC Entries are under regulation in the following clauses. +
++ When a Pull Request related to an initiation or modification to a particular EPC, its title + must be prefixed with "[EPC N]" and a space, with the Rules of using identifiers, + even the changes to its EFP are included in the Pull Request. + Its Pull Request identifier number must be recorded in its EFP Document's Metadata. +
++ When a Pull Request only changes Metadata of EPCs without any changes to Contents, it may + not be prefixed with an EPC identifier by the above clause. +
++ Generally, when referring to a particular EPC, one may use "EPC N", where N is + a positive integral identifier of the EPC without any leading zero; + this syntax usually refers to the latest Version or the Version by the time this syntax is used. +
++ In the Repository, if there is any Issue or Discussion relates to any particular EPC, + it may be mentioned in the titles by starting with "[EPC N]" by the above clause. +
+
+ If possible, the EPCs may also be linked in the article contents, by using
+ [EPC N](https://...) (in Markdown) or
+ <a href="https://...">EPC N</a> (in HTML), where
+ the hyperlink address is the rendered webpage of the EPC.
+