[PHP-DEV] RFCs and voting - feature requests + an oddity
While we are on the topic of RFCs and voting, I'd like to see the option to directly download the votes to a CSV file with real names and each user's karma list. If the above feature is deemed a good idea, there's also a corollary feature: It would also be useful to be able to download all votes across all RFCs (e.g. a gzip/ZIP file that's updated after each RFC closes). Some people might be interested in running historical analysis of voting patterns to look for data outliers. By the way, on RFC voting pages, I've noticed the "Real name" column appears as "username (username)". Is that intentional, some kind of software limitation, or a bug? -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On Tue, Aug 6, 2019 at 2:55 PM Claude Pache wrote: > > > > Le 6 août 2019 à 20:46, Nikita Popov a écrit : > > > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. > wrote: > > > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > >> It is expected to last two (2) weeks until 2019-08-20. > >> > >> A counter argument to this RFC is available at > >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > >> > >> Best regards > >> > >> George P. Banyard > >> > >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > >> > > > > Side-note: Even if this RFC fails, we should probably still make it an > > error to use we > > may flip the default to off at some later point in time. The current > > default being "on" despite their use being discouraged is half the > trouble. > > > > Nikita > > > That would mean in particular that XML documents could no longer be > preprocessed by PHP without boilerplate around its `` declaration. > I doubt that this is a more acceptable breaking change than deprecating > short_tags. > > —Claude > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Why would you want to use PHP's preprocessor for XML? Why not use the right tool for the job? Such as an XML processor that could also do schema validation? PHP has XML processing packages. It has been a while since I did XML processing, but I don't remember the packages being all that difficult to use. Is this a mixing data and code into the same file problem? Like HTML files that have PHP embedded directly in the file? Or this about stuffing PHP inside of XML documents? Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> Le 6 août 2019 à 20:46, Nikita Popov a écrit : > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. wrote: > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> It is expected to last two (2) weeks until 2019-08-20. >> >> A counter argument to this RFC is available at >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> >> Best regards >> >> George P. Banyard >> >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >> > > Side-note: Even if this RFC fails, we should probably still make it an > error to use may flip the default to off at some later point in time. The current > default being "on" despite their use being discouraged is half the trouble. > > Nikita That would mean in particular that XML documents could no longer be preprocessed by PHP without boilerplate around its `` declaration. I doubt that this is a more acceptable breaking change than deprecating short_tags. —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve visibility of RFC negative feedback
On Mon, Aug 5, 2019 at 8:34 AM Dan Ackroyd wrote: > > # Proposal - improve visibility of negative feedback > > When someone creates an RFC, near the top of that page they should > create a link to a separate page that will contain negative feedback. > People other that the RFC author are free to put whatever negative > feedback think is appropriate on that 'negative feedback' page. > A kind of in the weeds question but would this require karma or just wiki registration? Current discussions are pretty open on the list but karma would lock down this part of the process a lot for better worse.
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> On 6 Aug 2019, at 21:46, Nikita Popov wrote: > >> On Tue, Aug 6, 2019 at 1:34 PM G. P. B. wrote: >> >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> It is expected to last two (2) weeks until 2019-08-20. >> >> A counter argument to this RFC is available at >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> >> Best regards >> >> George P. Banyard >> >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >> > > Side-note: Even if this RFC fails, we should probably still make it an > error to use may flip the default to off at some later point in time. The current > default being "on" despite their use being discouraged is half the trouble. > That’s a good idea. I was genuinely surprised to learn that wasn’t already the case, although the actual impact of that is quite limited given the fact that virtually all common deployments come preconfigured with short tags set to off. Zeev
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On Tue, Aug 6, 2019 at 1:34 PM G. P. B. wrote: > The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > Side-note: Even if this RFC fails, we should probably still make it an error to use
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On Tue, 6 Aug 2019 at 19:25, Chase Peeler wrote: > > > On Tue, Aug 6, 2019 at 1:19 PM G. P. B. wrote: > >> >> >> >> On Tue, 6 Aug 2019 at 19:12, Rowan Collins >> wrote: >> >>> On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote: >>> >>> > I'm not a voter, but, I have a question. If this fails, does that mean >>> the >>> > original RFC that passed is still in effect? >>> > >>> >>> >>> Yes, this is really ambiguous, and risks the situation being even more >>> confusing than it was before. >>> >>> The "No" column on this RFC already includes people who voted "Yes" on >>> the >>> previous version; is this an indication that they have changed their mind >>> about removing short tags, or that they prefer the original proposal? >>> >>> I think we urgently need to clarify this, and may need to reset the vote >>> with one or more clearer questions. >>> >>> Regards, >>> -- >>> Rowan Collins >>> [IMSoP] >> >> >> This RFC supersedes the previous one as stated in the the RFC itself : " >> This RFC supersedes the previous one and proposes a different >> deprecation approach." meaning that the previous one is void. >> I don't know why this is ambiguous and needs to be said once again. >> >> Just to clarify - the existence of this RFC effectively means the > original never existed. > > >> Best regards >> >> George P. Banyard >> > > > -- > Chase Peeler > chasepee...@gmail.com > In a sense yes, however this RFC is a vote on the implementation which would have landed with the previous one but was not the one voted. So you can disregard the result of the previous one not the controversial discussion it generated after the vote was accepted. Hope this clarifies everything. Best regards George P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On Tue, Aug 6, 2019 at 1:19 PM G. P. B. wrote: > > > > On Tue, 6 Aug 2019 at 19:12, Rowan Collins > wrote: > >> On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote: >> >> > I'm not a voter, but, I have a question. If this fails, does that mean >> the >> > original RFC that passed is still in effect? >> > >> >> >> Yes, this is really ambiguous, and risks the situation being even more >> confusing than it was before. >> >> The "No" column on this RFC already includes people who voted "Yes" on the >> previous version; is this an indication that they have changed their mind >> about removing short tags, or that they prefer the original proposal? >> >> I think we urgently need to clarify this, and may need to reset the vote >> with one or more clearer questions. >> >> Regards, >> -- >> Rowan Collins >> [IMSoP] > > > This RFC supersedes the previous one as stated in the the RFC itself : " > This RFC supersedes the previous one and proposes a different deprecation > approach." meaning that the previous one is void. > I don't know why this is ambiguous and needs to be said once again. > > Just to clarify - the existence of this RFC effectively means the original never existed. > Best regards > > George P. Banyard > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
Hello, On Tue, 6 Aug 2019 at 19:19, G. P. B. wrote: > > On Tue, 6 Aug 2019 at 19:12, Rowan Collins wrote: > > > On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote: > > > > > I'm not a voter, but, I have a question. If this fails, does that mean > > the > > > original RFC that passed is still in effect? > > > > > > > > > Yes, this is really ambiguous, and risks the situation being even more > > confusing than it was before. > > > > The "No" column on this RFC already includes people who voted "Yes" on the > > previous version; is this an indication that they have changed their mind > > about removing short tags, or that they prefer the original proposal? > > > > I think we urgently need to clarify this, and may need to reset the vote > > with one or more clearer questions. > > > > Regards, > > -- > > Rowan Collins > > [IMSoP] > > > This RFC supersedes the previous one as stated in the the RFC itself : " > This RFC supersedes the previous one and proposes a different deprecation > approach." meaning that the previous one is void. > I don't know why this is ambiguous and needs to be said once again. > > Best regards > > George P. Banyard Thank you for clarification. From what I understand it is the case where "no" means a status quo and no agreements has been reached on the original RFC. Since the original RFC has been vetoed and so much energy was invested from Zeev and some others commentators then I guess the RFCs fail and we will have two types of opening tags in PHP for ever. Otherwise, as described, yes. -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On Tue, 6 Aug 2019 at 19:12, Rowan Collins wrote: > On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote: > > > I'm not a voter, but, I have a question. If this fails, does that mean > the > > original RFC that passed is still in effect? > > > > > Yes, this is really ambiguous, and risks the situation being even more > confusing than it was before. > > The "No" column on this RFC already includes people who voted "Yes" on the > previous version; is this an indication that they have changed their mind > about removing short tags, or that they prefer the original proposal? > > I think we urgently need to clarify this, and may need to reset the vote > with one or more clearer questions. > > Regards, > -- > Rowan Collins > [IMSoP] This RFC supersedes the previous one as stated in the the RFC itself : " This RFC supersedes the previous one and proposes a different deprecation approach." meaning that the previous one is void. I don't know why this is ambiguous and needs to be said once again. Best regards George P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote: > I'm not a voter, but, I have a question. If this fails, does that mean the > original RFC that passed is still in effect? > Yes, this is really ambiguous, and risks the situation being even more confusing than it was before. The "No" column on this RFC already includes people who voted "Yes" on the previous version; is this an indication that they have changed their mind about removing short tags, or that they prefer the original proposal? I think we urgently need to clarify this, and may need to reset the vote with one or more clearer questions. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
I'm not a voter, but, I have a question. If this fails, does that mean the original RFC that passed is still in effect? If I did have a vote, I would be against this RFC for the reasons laid out by Zeev in the counter argument. However, I feel the negative impacts of possible code leaks that will be caused by the original RFC are even worse. If I did have a vote, I might feel forced to vote for this. At least with this RFC we wouldn't really see any of the other negative impacts until PHP 9, given us time to revisit and possibly reverse that part of this RFC. On Tue, Aug 6, 2019 at 7:34 AM G. P. B. wrote: > The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Improve visibility of RFC negative feedback
On Tue, 6 Aug 2019 at 14:46, Lynn wrote: > The current setup allows for a single author to write down counter > arguments. As the counter arguments seem to primarily be opinionated, I'm > interested to see who's opinion it is, as two people can have different > opinions on the same subject. If person 1 writes down "option A is bad > because of X", person 2 wants to write down that option A is also bad, but > not for the reason mentioned by person 2, and person 3 wants thinks the > arguments mentioned are actually pros and not cons, I don't see how that is > possible right now. > Dan's proposal covered that: > In the (hopefully) rare cases where the people providing negative > feedback can't agree on how that page should be formatted, they may > create a new negative feedback page and also put a link to it on the > actual RFC page, next to the other 'negative feedback' link. > That being said, I feel like this should be more of a personal summary per > person so everyone can look back what the opinions were and why someone > voted yes or no. > That sounds like something rather different from what Dan was proposing, and something that's been discussed before: require voters to give reasons for their votes. I won't go into the pros and cons of that right now, but will highlight why it's fundamentally different: A "negative feedback" / "counterargument" / "dissenting opinion" page is by design a *summary*, designed to *reduce* the amount of reading required to understand the additional viewpoint; a page for every user on the list would not achieve that design goal. This also comes back to the distinction between consensus and majority. If no two participants in a discussion can agree on even a summary of what the issues are, then we have a far bigger problem than how many wiki pages to create. Most voting reasons would amount to "I agree with point 4, but disagree with points 3 and 8", rather than needing to restate the whole case. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Improve visibility of RFC negative feedback
On Tue, Aug 6, 2019 at 3:19 PM Rowan Collins wrote: > > Firstly, I would somewhat question why you need to know who holds an > opinion. RFCs, and any dissenting opinions, are not manifestoes in > elections, they are information presented so that you can form your own > opinion. They should not be read as representative of "the group as a > whole", but nor should the author be particularly important in most cases. > > That said, the current RFC template has an "author" field in the header, > and Dan already proposed a convention of contributors "signing" dissenting > opinions they agree with. The example you link to says "Author: Zeev > Suraski", so I'm not sure what change you're proposing. > The current setup allows for a single author to write down counter arguments. As the counter arguments seem to primarily be opinionated, I'm interested to see who's opinion it is, as two people can have different opinions on the same subject. If person 1 writes down "option A is bad because of X", person 2 wants to write down that option A is also bad, but not for the reason mentioned by person 2, and person 3 wants thinks the arguments mentioned are actually pros and not cons, I don't see how that is possible right now. That being said, I feel like this should be more of a personal summary per person so everyone can look back what the opinions were and why someone voted yes or no. The mailing list is rather chaotic, even when using an interface such as externals.io, and it's hard to get a summary of opinions, and some people might not write down their opinions in the mailing list and will simply vote. The counter argument page feels like a good idea to see why a certain RFC should not be accepted, but why not extend it to a who votes on what and why page? This would be very useful information for people who are not active on the mailing list or externals.io and leeitheraves information behind of why something wasn't accepted at the time. At times when an RFC is accepted or rejected, a lot of people wonder why this happened. "Why isn't this awesome RFC accepted?", "Why is the RFC accepted while it brings more problems than it fixes?", "Why was a partial solution accepted?". There's valuable information in the mailing list, yet some conversations go off-topic fast or get spammed with mails that should probably dealt with in direct conversations between some people, and this makes it hard to follow. > so I'm not sure what change you're proposing. I suppose a page per person allowed to vote where they can summarize their opinion on an RFC, whether it is in favor of, or against. The current setup for counter arguments serves as a nice starting point, as we can read back why people were against an RFC. This means instead of a direct link to a single counter argument page with a single author, a link could be provided to a page where multiple authors post their summary. This could of course also be a page linking to other dedicated pages with one author per page. Regards, Lynn van der Berg
Re: [PHP-DEV] Improve visibility of RFC negative feedback
On Tue, 6 Aug 2019 at 13:54, Lynn wrote: > Taking the current RFC ( > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags) as > example, how do we as reader differentiate between people's counter > arguments? When I read those points, I feel like this is something agreed > upon by the group as a whole, rather than a person and I know that not > everyone might these points as (valid) counter arguments or have different > opinions about each. > > My proposal is to add a name to either a section or argument itself, or > perhaps each person could create a page with their counter arguments, > meaning the current page becomes an index. This makes it very clear to see > who provides which arguments. > Firstly, I would somewhat question why you need to know who holds an opinion. RFCs, and any dissenting opinions, are not manifestoes in elections, they are information presented so that you can form your own opinion. They should not be read as representative of "the group as a whole", but nor should the author be particularly important in most cases. That said, the current RFC template has an "author" field in the header, and Dan already proposed a convention of contributors "signing" dissenting opinions they agree with. The example you link to says "Author: Zeev Suraski", so I'm not sure what change you're proposing. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Improve visibility of RFC negative feedback
On Tue, Aug 6, 2019 at 2:33 PM Rowan Collins wrote: > The key difference between an RFC and a discussion thread is that it > presents a summary or synthesis, which can be much more easily digested > than a full discussion. It is also, crucially, editable, so can be reworded > or corrected to clarify points; in an email thread, a reader often has to > read the first attempt at conveying something, then follow a series of > errata down the sub-thread. > > As Zeev mentioned, it might be enough to have a standard format for this, > rather than always requiring it. > > Hi, Taking the current RFC ( https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags) as example, how do we as reader differentiate between people's counter arguments? When I read those points, I feel like this is something agreed upon by the group as a whole, rather than a person and I know that not everyone might these points as (valid) counter arguments or have different opinions about each. My proposal is to add a name to either a section or argument itself, or perhaps each person could create a page with their counter arguments, meaning the current page becomes an index. This makes it very clear to see who provides which arguments. Regards, Lynn van der Berg
Re: [PHP-DEV] Improve visibility of RFC negative feedback
On 5 August 2019 14:33:53 BST, Dan Ackroyd wrote: >When someone creates an RFC, near the top of that page they should >create a link to a separate page that will contain negative feedback. >People other that the RFC author are free to put whatever negative >feedback think is appropriate on that 'negative feedback' page. Hi Dan, I think this is a really sensible idea. The key difference between an RFC and a discussion thread is that it presents a summary or synthesis, which can be much more easily digested than a full discussion. It is also, crucially, editable, so can be reworded or corrected to clarify points; in an email thread, a reader often has to read the first attempt at conveying something, then follow a series of errata down the sub-thread. As Zeev mentioned, it might be enough to have a standard format for this, rather than always requiring it. I also think the term "negative feedback" might be a bit ... negative. Elsewhere in your message, you used "dissenting", which I think captures the essence better. The difference from the main page is not inherently about positive vs negative, but about allowing different voices. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fw: New error format in php.ini
Hello, how about add json_errors like html_errors and option for injecting
json_errors in response(if response json object(ex. {"success":false}) append
new field(ex. php_error {"success":false,"php_errors":{"stack":...}}))?Thanks.
[PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
The voting for the "Deprecate short open tags, again" [1] RFC has begun. It is expected to last two (2) weeks until 2019-08-20. A counter argument to this RFC is available at https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags Best regards George P. Banyard [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
Re: [PHP-DEV] Counterargument to Short Tags Deprecation (was: Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2)
On Mon, 5 Aug 2019 at 23:51, Zeev Suraski wrote: > On Mon, Aug 5, 2019 at 10:05 PM G. P. B. wrote: > > > > > I'd prefer Dan's approach and having a seperate page linked at the top of > > the RFC. > > > > I'll start voting tomorrow and will link to your page in the same message > > as the voting announcement. > > > > Thanks George. I created a page with a counterargument to the deprecation > proposal here: > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags and > linked it from the RFC. > > If others have additional input to add there, please let me know. > Please keep this sort of content inside the relevant mailing list thread, we don't need yet more places to go hunting for comments on RFCs. I'm not sure what the value is of a dedicated wiki page is (for context, I have read Dan's thread suggesting the idea), other than to have a new soap box to shout from for the most loud voices. Key feedback to RFCs should at minimum appear in the respective discussion thread on the list. If it does, then this page is redundant. If it doesn't, then it should. > > Zeev >
