Initial commit

Author: xiaomin1397

0000-template-en.md

@@ -0,0 +1,57 @@
+- Proposal date: (in the format of YYYY-MM-DD)
+- Affected version: (e.g. 1.2.0.X)
+- Related Issues: (if any)
+
+## [Mandatory] Overview
+
+Briefly describe the feature.
+
+## [Mandatory] Motivation
+
+Why do we need to make this change? What scenarios does it generally address? What will be the result of this change?
+
+## [Mandatory] API specifications and use cases
+
+If the proposal adds or modifies an API, please specify the API specifications in the following format and provide a basic code example.
+
+#### Interface Definition
+
+##### Parameters:
+
+| Parameter Name | Type | Mandatory | Description |
+| -------------- | ---- | --------- | ----------- |
+|                |      |           |             |
+
+For more API specifications, please refer to [Interface](https://doc.quickapp.cn/features/).
+
+##### Code Example
+
+*Show a simple code snippet of API usage*
+
+## [Mandatory] Will the proposer implement the feature themselves?
+
+*Yes: The proposer is willing to implement the feature themselves after the proposal is approved;*
+
+*No: After the proposal is approved, other developers in the community will need to help implement it;*
+
+## Detailed Design
+
+Optional. Please explain to someone familiar with the implementation of hapjs how to implement this feature in hapjs or what steps are required to implement this feature.
+
+## Defects
+
+Can we not implement this feature? Please consider:
+
+- The investment required to implement this feature, including the complexity of the code, the increase in code size, and the manpower required to implement the feature.
+- Whether this feature does not need to be provided by hapjs and developers using hapjs can even implement it better at the application layer.
+- The impact on the established development habits of hapjs.
+- The impact on the published versions and existing features, as well as the cost of user migration.
+- The impact on other RFC proposals that have not yet been implemented.
+
+## Alternative Choices
+
+Are there other options to implement this feature?
+
+## Adaptation Strategy
+
+If we implement this proposal, is there any way to help developers adapt to this change better?

README-en.md

@@ -0,0 +1,68 @@
+# hapjs RFC
+
+Most code changes for feature updates and bug fixes can follow the normal GitHub Flow process and be completed by submitting a pull request and undergoing code review. However, some updates may cause fundamental changes to the system architecture and APIs - for these types of updates, we need to design a process to ensure consensus between the hapjs team and the community.
+
+RFC (Request for Comments) is a process mechanism designed to ensure that significant feature updates and architectural changes can be smoothly advanced.
+
+## Which types of changes require the RFC process
+
+As mentioned earlier, any change that causes changes to the system architecture or APIs or causes changes to the overall code structure requires the RFC process, for example:
+
+- Adding a package that needs to be installed by developers
+- Modifying API parameters or deleting APIs
+- Changing the scheme for hapjs's established development practices
+- Any changes that render published versions unusable
+
+The following types of changes do not require the RFC process:
+
+- Bug fixes
+- Feature iterations that do not affect the use of published versions
+- Adding or deleting warnings
+- Internal architecture adjustments or code refactoring
+- Performance improvements or compatibility improvements
+
+If a developer submits a pull request that should go through the RFC process, the hapjs team will close the pull request and ask the developer who submitted the pull request to execute the RFC process in the RFC repository.
+
+## Why do we need the RFC process?
+
+Cumbersome processes are undoubtedly harmful to development and iteration efficiency, but for the following reasons, let us introduce the RFC mechanism even if we are willing to reduce iteration efficiency:
+
+1. Stability. The existing RFC process can minimize the impact of each iteration on old users as much as possible. The RFC process is also tied to a certain extent with version releases to ensure that hapjs iterations comply with semantic versioning specifications as much as possible.
+2. Openness and transparency. We hope that hapjs iterations are as open, public, and transparent as possible, and that everyone can participate in the RFC discussion and influence the next version of hapjs. At the same time, we also hope to increase the participation of the hapjs community through this and let more people participate in the core construction of hapjs.
+3. Code quality. The existing RFC process requires a design document before implementation, which is very helpful for specific code implementation.
+4. Design tracking. We hope that every RFC document and the PR behind it can reflect the thinking and compromise behind adding, canceling, or modifying a feature, which is very important for the long-term development of hapjs and developers who want to delve into hapjs.
+
+## RFC process mechanism
+
+In short, if the RFC change needs to be released in future hapjs versions, the RFC proposal document needs to be merged in the RFC repository first.
+
+- Fork hapjs RFC repository: #TODO;
+- Copy `0000-template.md` to `rfcs/0000-my-feature.md` (`my-feature` needs to be changed to a word that can describe the RFC, and `0000` is the RFC number, which does not need to be changed for now);
+- Fill in the RFC proposal according to the template in active/0000-my-feature: The RFC needs to describe the motivation and reasons clearly, show specific cases and design details, and the possible problems. The RFC proposal enters the `Pending` stage;
+- Submit a pull request to hapjs RFC repository. At this stage, hapjs team and the community will discuss the RFC proposal together;
+- When the RFC proposal reaches consensus in the community, the RFC proposal enters the `Active` stage;
+- The code implementation of the RFC proposal is merged into the hapjs main repository, and the RFC proposal enters the `Landed` stage. The RFC proposal is also merged into the RFC repository;
+- Finally, the hapjs team will decide which version to release the RFC proposal changes.
+
+## RFC proposals in the `Pending` stage
+
+When an RFC proposal is submitted as a pull request:
+
+- The RFC proposal will be discussed by the hapjs team and the community together, and the details and conclusions finally obtained may not be consistent with the initial RFC proposal;
+- The RFC proposal may be rejected due to failure to reach consensus, and at least one member of the hapjs team will give the reason for rejection;
+- When the RFC proposal reaches consensus in the community, it enters the `Active` stage, and the hapjs team or the community can begin to implement the proposal's code;
+- The RFC proposal may fail to reach consensus due to no discussion, and the hapjs team can decide whether to accept the proposal based on the actual situation.
+
+## RFC proposals in the `Active` stage
+
+When an RFC proposal reaches consensus in the community and enters the `Active` stage, it does not mean that the changes proposed in the RFC proposal are set in stone, and the code implementation of the RFC proposal may not be merged into the hapjs main repository. However, when the RFC proposal enters the `Active` stage, it does mean that the hapjs team and the community recognize the changes proposed in the RFC proposal and believe that this is something that should be implemented in the future.
+
+That is to say, when an RFC proposal enters the `Active` stage, it does not mean that this change has been assigned a priority, and the specific release time also needs to be determined after the code implementation.
+
+## Implementation of RFC proposals
+
+The author of the RFC proposal document is not obligated to implement the RFC proposal code. Of course, if the author of the RFC proposal (or any developer) is willing to implement the code after the RFC proposal document is accepted, this is also very welcome.
+
+Accepted RFC proposals need to include a pull request link in the hapjs main repository (even if the PR is still being drafted or incomplete), and the author of the RFC proposal and the hapjs team need to urge the RFC implementation PR to move in the direction described in the RFC proposal document.
+
+The hapjs RFC process mechanism is inspired by Taro RFC, Rust RFC Process, React RFC Process, and Vue RFC Process.