Move PIP and PIP template to codebase - #17270
Conversation
There was a problem hiding this comment.
I can see we already have a dev folder. What if place these files under dev/proposals? Also, we can move the current release guide there. It's more expressive than wiki.
Well. It seems the content under dev folder is outdated. Let's postpone the decision later. Still, I think we should take care of files layout to manage it and perhaps organize a dev guide (finally on the website).
| ## Template for a PIP design doc | ||
|
|
||
| ``` | ||
| ## Motivation | ||
|
|
||
| Explain why this change is needed, what benefits it would bring to Apache Pulsar | ||
| and what problem it's trying to solve. | ||
|
|
||
| ## Goal | ||
|
|
||
| Define the scope of this proposal. Given the motivation stated above, what are | ||
| the problems that this proposal is addressing and what other items will be | ||
| considering out of scope, perhaps to be left to a different PIP. | ||
|
|
||
| ## API Changes | ||
|
|
||
| Illustrate all the proposed changes to the API or wire protocol, with examples | ||
| of all the newly added classes/methods, including Javadoc. | ||
|
|
||
| ## Implementation | ||
|
|
||
| This should be a detailed description of all the changes that are | ||
| expected to be made. It should be detailed enough that any developer that is | ||
| familiar with Pulsar internals would be able to understand all the parts of the | ||
| code changes for this proposal. | ||
|
|
||
| This should also serve as documentation for any person that is trying to | ||
| understand or debug the behavior of a certain feature. | ||
|
|
||
|
|
||
| ## Reject Alternatives | ||
|
|
||
| If there are alternatives that were already considered by the authors or, | ||
| after the discussion, by the community, and were rejected, please list them | ||
| here along with the reason why they were rejected. | ||
|
|
||
| ``` No newline at end of file |
There was a problem hiding this comment.
Duplicate to the PIP-template. We can remove this content.
If you're not in a hurry. Let's review the content. Or if you want to push this migration first (since the content is already there for a long time) and improve the content later, we can do it as a follow-up.
There was a problem hiding this comment.
Please see my comment on the mailing list https://lists.apache.org/thread/0w2s87yp79sqdfdk7o8tfq90o9x20c9n.
This can be a significant process change. We should reach an explicit consensus first instead of rushing into PRs. Especially, we don't know what clear proposal process we agree on now.
| A PIP proposal can be in these states: | ||
| 1. **DRAFT**: (Optional) This might be used for contributors to collaborate and | ||
| to seek feedback on an incomplete version of the proposal. | ||
|
|
||
| 2. **DISCUSSION**: The proposal has been submitted to the community for | ||
| feedback and approval. | ||
|
|
||
| 3. **ACCEPTED**: The proposal has been accepted by the Pulsar project. | ||
|
|
||
| 4. **REJECTED**: The proposal has not been accepted by the Pulsar project. | ||
|
|
||
| 5. **IMPLEMENTED**: The implementation of the proposed changes have been | ||
| completed and everything has been merged. | ||
|
|
||
| 5. **RELEASED**: The proposed changes have been included in an official | ||
| Apache Pulsar release. | ||
|
|
||
| The process works in the following way: | ||
|
|
||
| 1. The author(s) of the proposal will create a GitHub issue ticket choosing the | ||
| template for PIP proposals. | ||
| 2. The author(s) will send a note to the dev@pulsar.apache.org mailing list | ||
| to start the discussion, using subject prefix `[PIP] xxx`. | ||
| 3. Based on the discussion and feedback, some changes might be applied by | ||
| authors to the text of the proposal. | ||
| 4. Once some consensus is reached, there will be a vote to formally approve | ||
| the proposal. | ||
| The vote will be held on the dev@pulsar.apache.org mailing list. Everyone | ||
| is welcome to vote on the proposal, though it will considered to be binding | ||
| only the vote of PMC members. | ||
| I would be required to have a lazy majority of at least 3 binding +1s votes. | ||
| The vote should stay open for at least 48 hours. | ||
| 5. When the vote is closed, if the outcome is positive, the state of the | ||
| proposal is updated and the Pull Requests associated with this proposal can | ||
| start to get merged into the master branch. |
There was a problem hiding this comment.
You may try to list the proposed process here and we start to practice the process discussing on a pull request.
Anyway, this content doesn't reflect what was discussed on the mailing list.
@tisonkun I have replied to the mailing list to avoid confusion. This PR is not intended to change something before we have a result on the mailing list. As I said in the PR description, just to be able to reflect all subsequent modifications(historical records). Thanks for point it out, it might also confuse other people. |
tisonkun
left a comment
There was a problem hiding this comment.
@codelipenghui Thanks for your clarification! Then I approve merging this pull request.
Motivation
According to the discussion https://lists.apache.org/thread/4gwcy3ds2mcmdmcrso24bx55wzlz2gp8
This is the first PR to move the PIP and PIP template into codebase
This PR 100% copied from the wiki page, any improvements should happen with additional PRs which
will have all the historical records.