EFP Architecture

Execution Framework Proposals, or EFPs, are the structured documents that:

1. outline how a project or initiative will be executed, managed, and monitored to achieve its goals; or
2. explain or define a certain architecture which would be applied onto the project, including its community.

An EFP may involve the community, an architecture, a plan or a scheme. It may not be highly executive, but may involve certain objectives, deliverables, or boundaries of the project. There may not be time constrains, but the milestones and objectives may be decided in the roadmap. Moreover, it would be intended to standardize and guide the project or a process. Sometimes, some EFPs may solicit feedback from the community depending on the context, so EFPs may be updated and revised upon feedbacks or progressions. However, the topics or the themes of the EFPs should not be changed, or else a new EFP should be issued for the new content and updates. Certainly, detailed descriptions should always be included to ensure the goals and methods are generally understood.

EFPs are publicly visible and allow open project supervisions by the public, while keeping the project workflow streamlined enough. These could provide clear guidelines and information about various topics, so as the processes. This would also allow certain public involvement in the project while keeping certain intent of organized workflow.

When mentioning "repository" in the following, it refers to the GitHub repository hosting all the EFPs of the project and the community. The specific context may involve directory structure of the repository and the files included.

An EFP includes the following sections:

• Introduction
• Main content
• See also (optional)
• References

The Introduction describes the brief abstract about the topic the EFP is relevant to. The content should be kept short but descriptive enough to open the topic.

All the content goes into the Main content with their respective sections with appropriate titles. There is no restriction to the details.

If there are other related articles, EFPs or webpages, these may be listed in See also, but it is not mandatory. This only includes highly relevant content, otherwise they may be regarded as off-topic.

If there is any reference to particular content mentioned in the EFP, these may be referred with appropriate citation reference. This is handled by the EFP system. Depending on the usages, they may be named or unnamed, but they should be separated. There may be no reference.

All EFPs are stored in the same efp folder from the root directory of the repository. For each EFP, all the related files of an EFP is included in a subfolder of the efp folder, named efp<XXX>, where XXX is a 3-digit number assigned identifier of the entire EFP, with leading zeros filled if any. The identifiers are assigned with increments of the latest proposed EFP, to new EFPs. However, it is possible that the identifier later changes to 4 digits. Thus, the format change is different from the EFP content change process, and may be conducted directly, but proposing EFP(s) is still recommended for tracking.

All EFP documents are formatted in XML, with XHTML generated accordingly with the Node.js scripts. The XML Schema is defined in efp.xsd at the root directory of the repository. The main XML document is stored as main.xml in the EFP folder. Any other files including images are stored in the same directory and referred in the same directory. It is possible to have child XML documents in the same EFP, but not recommended and instead should all be kept in the same document, even if there is any "appendix".

• An Informational EFP is non-normative and describes background, explanations or other information about various topics. It may also provide insights and overviews about some topics.
• A Process EFP is normative and describes or proposes a change to a community or project process, workflow or governance. It may also provide guidelines, processes, and best practices for the community and/or the project.
• A Standard EFP is normative and describes about a feature for the project, with descriptive standards, protocols or specifications. It may also include implementation change or interoperability standard for the project.

All changes to the content of any EFP are submitted via Pull Requests. Anyone is allowed to submit Pull Requests, but the final decisions of them are conducted by the repository maintainer(s).

If the entire EFP document is not completed, it is kept as Draft. The EFP is at the initial stages of development. The EFPs under this status are under construction and open to revisions and additions before they are ready for wider scrutiny.

Then, before it is fully accepted or adapted, it becomes Provisional. This stands for "Provisionally Adapted". If it is temporarily adapted without full consensus, and it was a Draft without further changes, it is also Provisional. Any Provisional EFP would not turn back to Draft by any mean.

After everything is confirmed, it would become Final. This includes reviewing and revisions. Only subtle and trivial changes are allowed when it has already beenFinal. Further revisions and changes should be conducted by proposing new EFPs updating or obsoleting the original EFP instead.

However, it is possible that if the particular EFP had already been accepted before being drafted, Draft and/or Provisional may be skipped. Only to ensure that the content is definite enough, with appropriate reviews and consensus. Informational EFPs are likely in this case.

An EFP may also be Deferred. If there is a particular EFP Draft has been worked on but later paused, the EFP development may be postponed until future evaluation for continuation. Even if an EFP is logically "cancelled", it would still be assigned to this status but with the wording "indefinitely deferred". This would allow potential pick up of the EFP. If there is a new EFP replacing, the EFP could be marked as "Obsoleted" by the new EFP.

• Python PEP 1
• RFC 2026