Den man. 16. mar. 2020 kl. 20.29 skrev Mike Schinkel <email@example.com>:> > Hi all, > > Seeing people referencing former RFCs that failed when someone brings up an RFC (which is a good thing to reference, BTW) I am finally compelled to comment in hope there would be will to improve it. > > When court justices rule on important decisions they write opinions, or join with the majority or minority opinion. That way judges and others in the future can know why things were decided a certain way. > > However in PHP we have no way of knowing why people voted against a proposal except maybe for those very few who commented negatively on the mailing list. Which is far from concise and frequently not conclusive. > > It is a real shame that the PHP voting process has no way to capture a concise description of why people voted against an RFC. A "No" vote could mean any of the following, or something completely different, and their reasons are really important when it comes to future consideration of the same issue: > > 1. I hate the idea and never want to see it in PHP > 2. I'm okay with the idea but > a. I have a small issue with "x" > b. I have a big issue with "y" > c. I prefer to see it implemented using "z" approach instead > 3. I love the idea but > a. Can't support it given "x" > b. I want it to be implement using "y" approach instead > 4. We can't do this until we do "x" first > 5. We should do "x" instead > 6. Or who knows what other reason? > > Would it be possible to add a feature when voting were people either need to type in a one to two sentence reason why they voted "no" on a proposal OR select from the reasons that others have already given when voting down the specific RFC? > > If we had that we could list the reasons and the number of votes that choose those reasons on the RFC for historical purposes.I am not gonna personally answer a survey everytime I vote against a feature. This is why we have a discussion period to raise issues, of course not everyone will raise all their concerns to each and every RFC (me included, take the annotation RFCS posted over the years, they are awesome but the one thing I dislike is the syntax). I doubt everyone have time to go in details and understand to the teeth what each and every feature does. I instead recommend that you look at Dan Ackroyd's repository which he linked in his reply. Similar to him, I'm also fairly against the development of such a feature. -- regards, Kalle Sommer Nielsen firstname.lastname@example.org
On 18/03/2020 23:22, Kalle Sommer Nielsen wrote:> I am not gonna personally answer a survey everytime I vote against a > feature. This is why we have a discussion period to raise issues, of > course not everyone will raise all their concerns to each and every > RFC (me included, take the annotation RFCS posted over the years, they > are awesome but the one thing I dislike is the syntax). I doubt > everyone have time to go in details and understand to the teeth what > each and every feature does.If a person doesn't have the time or inclination to read into the details of an RFC, and also doesn't have time or inclination to engage in discussion about it, and also doesn't have the time or inclination to give even the briefest of justification about why they are casting their vote a particular way to help inform future discussion... Well, they shouldn't be casting a vote in the first place. That's not to suggest everyone should need to be able to analyse the patch line by line, but if a person is cleary *that* disengaged then IMO they should do the honourable thing and refrain from voting. MR.