2019年8月20日(火) 16:47 Rowan Tommins <rowan.coll...@gmail.com>: > On 20/08/2019 13:51, G. P. B. wrote: > > - I seriously don't appreciate that the RFC has been edited*WITHOUT* > my > > knowledge to add endorsement names on the counterargument to the RFC on > the > > RFC itself when the appropriate place would have been the counter > argument > > document. > > > While I appreciate that there is a certain implication of "ownership" > when you are the author of an RFC, it is ultimately a resource for the > community as a whole to understand the discussion, which is why the > guide at https://wiki.php.net/rfc/howto explicitly mentions including > both positive and negative feedback. > > The only problem I can see with other people editing "your" RFC is if > later readers could mistake the edits for your own opinion; even if the > whole counter-argument had been a section rather than a separate page, > it would be clear that readers shouldn't do that. In this case, the only > edits are to add a list of names, which is basically what the voting > widget does anyway, so I really can't see any reason to be upset about it. > > Regards, > > -- > Rowan Tommins (né Collins) > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Citation: > Note: An RFC is effectively “owned” by the person that created it. If you > want to make changes, get permission from the creator. Taken from: https://wiki.php.net/rfc I'm upset that a voting document is edited without my knowledge, and I don't see why I haven't been asked (probably because I would have said no to the edits) On Tue, 20 Aug 2019 at 17:18, Sara Golemon <poll...@php.net> wrote: > This has been a topic of discussion in the past. The agreement was that > non-author edits are permitted if they are isolated to a clear > "counter-arguments" section. If someone had changed the meaning of the RFC > or of your arguments in favor of it that would be another story, but that's > not what happened here. > > -Sara > Gotcha so from now on I'll just add a sentence "George Peter Banyard supports this RFC" every time I'm in agreement with an RFC to the RFC because having your name tied to a vote is apparently irrelevant, because this is exactly what you did (but only on the RFC not the counter argument page). On Tue, 20 Aug 2019 at 18:02, Chase Peeler <chasepee...@gmail.com> wrote: > > I think that now we need to fix the documentations out there. short > > tags will stay in PHP for at least another 10+ years, so maybe we > > should simply consider them not a part of legacy but a special kind of > > a feature. There are some parts in PHP comments and docs that needs > > this fixed and sorted out better a bit (probably - specially in the > > ini files itself etc). > > > > I think we should still discourage their use. We should be explicit in > the > documentation that code which uses short tags might not be portable. Just > because they exist, doesn't mean we should suddenly change our treatment of > them when it comes to best practices. If there is any documentation that > doesn't make this clear, submit a bug report. The document has been discouraging their use for god knows how long. > PHP also allows for short open tag *<?* (which is discouraged since it is > only available if enabled using the short_open_tag > <https://www.php.net/manual/en/ini.core.php#ini.short-open-tag> php.ini > configuration file directive, or if PHP was configured with the > *--enable-short-tags* option). > See: https://www.php.net/manual/en/language.basic-syntax.phptags.php On a final note, I don't think I have anything more to add to this topic so I probably won't respond to subsequent messages in this thread. Best regards George Peter Banyard
