rfc:howto
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:howto [2017/09/22 13:28] – external edit 127.0.0.1 | rfc:howto [2023/02/04 15:05] (current) – Added notes on not re-using RFC docs, and respecting authors danack | ||
---|---|---|---|
Line 5: | Line 5: | ||
If you don't have the skills to fully implement your RFC and no-one volunteers to code it, there is little chance your RFC will be successful. To learn about PHP core development see [[internals: | If you don't have the skills to fully implement your RFC and no-one volunteers to code it, there is little chance your RFC will be successful. To learn about PHP core development see [[internals: | ||
- | - Email internals@lists.php.net to measure reaction to your intended proposal. State who would implement the feature, or whether the proposal is only a " | + | - Email internals@lists.php.net to measure reaction to your intended proposal. State who would implement the feature, or whether the proposal is only a " |
- Get wiki RFC karma (this is only required if you don't have a VCS account for php.net. PHP developers can log on with their credentials and already have the necessary karma to create RFCs): | - Get wiki RFC karma (this is only required if you don't have a VCS account for php.net. PHP developers can log on with their credentials and already have the necessary karma to create RFCs): | ||
- Register for a wiki account at https:// | - Register for a wiki account at https:// | ||
Line 12: | Line 12: | ||
- Log into the wiki with your wiki account. | - Log into the wiki with your wiki account. | ||
- Navigate to a URL like https:// | - Navigate to a URL like https:// | ||
- | - Push the "Create | + | - Push the "Edit this page" button, fill out the supplied [[rfc: |
- Edit https:// | - Edit https:// | ||
- Write the RFC. | - Write the RFC. | ||
Line 18: | Line 18: | ||
- Change the status of your RFC page to "Under Discussion" | - Change the status of your RFC page to "Under Discussion" | ||
- Change its section on https:// | - Change its section on https:// | ||
- | - Send email to internals@lists.php.net introducing your RFC. | + | - Send an email to internals@lists.php.net introducing your RFC. |
- Listen to the feedback, and try to answer/ | - Listen to the feedback, and try to answer/ | ||
- | - When discussion ends, and a minimum period of two weeks has passed since you mailed internals@lists.php.net in step 4, then you can move your RFC to " | + | - When discussion ends, and a minimum period of two weeks has passed since you mailed internals@lists.php.net in step 4, consider one day heads up mail on the mailing list and then you can move your RFC to " |
- Update your RFC page to " | - Update your RFC page to " | ||
- Add the doodle voting macro, for example: < | - Add the doodle voting macro, for example: < | ||
- | <doodle title=" | + | <doodle title=" |
* Yes | * Yes | ||
* No | * No | ||
</ | </ | ||
- | - Add the voting start and end dates to the text of the RFC. | + | - Add the voting start and end dates to the text of the RFC, including the time and timezone that the voting will end. |
- Move your RFC on https:// | - Move your RFC on https:// | ||
- | - Send email to internals@lists.php.net announcing the start of voting for your RFC. Start a new mail thread and put " | + | - Send an email to internals@lists.php.net announcing the start of voting for your RFC. Start a new mail thread and put " |
- Based on the result of the votes and the discussion there are three possible outcomes: | - Based on the result of the votes and the discussion there are three possible outcomes: | ||
- Your RFC is accepted: update the status of your RFC page and its section on https:// | - Your RFC is accepted: update the status of your RFC page and its section on https:// | ||
Line 35: | Line 35: | ||
- A serious issue with your RFC needs to be addressed: update the status of your RFC page and its section on https:// | - A serious issue with your RFC needs to be addressed: update the status of your RFC page and its section on https:// | ||
- When your feature is implemented in PHP, update the RFC with: | - When your feature is implemented in PHP, update the RFC with: | ||
- | | + | - the version(s) it was merged to |
- | - a link to the git commit(s) | + | |
- | - a link to the PHP manual entry for the feature | + | |
- | - a link to the language specification section (if any) | + | |
+ | - Change the status of your RFC page to " | ||
+ | - Change its section on https:// | ||
+ | |||
+ | ==== Notes ==== | ||
+ | |||
+ | === Open new RFCs rather than re-use existing documents === | ||
+ | |||
+ | In general the status of an RFC should not be moved backwards to an earlier status. In practice there will be times when people accidentally open the voting too early, or some serious problem is found with an RFC during the voting phase, in those cases it's fine to move the status back until the problem is fixed. But as a rule, leaving each RFC document with a clear history of what happened to that RFC makes it easier to understand past discussions. | ||
+ | |||
+ | Also, we have rules about when RFCs are allowed to be put into voting. If a RFC document has been re-used there could be some confusion about when it is allowed to be put to a vote. | ||
+ | |||
+ | Leaving the previous RFC document intact, with the results of a vote if one was taken, leaves a clearer document trail than if the document has been recycled. | ||
+ | |||
+ | It can also be useful to create a new RFC document when an RFC changes significantly during it's discussion. Although previous versions of documents are available through the wiki, finding where an RFC was re-written and trying to understand why it was, are quite difficult. Leaving the previous version intact, with a note pointing to the new version makes understanding discussion history much easier. | ||
+ | |||
+ | === RFCs ' | ||
+ | |||
+ | Although minor typos can be fixed by other people, any significant changes should be approved by the original RFC author. | ||
+ | |||
+ | If you wish to 'take over' an RFC, you need the express consent of the RFC author. If you can't get that consent, for example the person doesn' | ||
+ | |||
+ | |||
+ | === Don't list someone as an author without their express consent === | ||
+ | |||
+ | There have been cases where someone has added someone' | ||
+ | |||
+ | If you want to credit someone for having done a large amount of work, e.g. when taking over an abandoned RFC, you can do that by adding the phrase 'based on work by' e.g. " | ||
==== External Resources ==== | ==== External Resources ==== | ||
* [[https:// | * [[https:// |
rfc/howto.1506086901.txt.gz · Last modified: 2017/09/22 13:28 by 127.0.0.1