I decided to be smart and use a Google Form this time. Hopefully I can still extract the same data from it so I can use the same spreadsheet formulae as before.
All FIG members, *please* take 30 seconds to reply. (Really, it's super-short.) Non-members, your input is welcome and requested as well.If you have trouble viewing or submitting this form, you can fill it out online:
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
How would people who have already voted submit their view on this? I think that when we add the voting web app for members we should add a polling function for this sort of thing so it can all be handled on there. I might have a look at this web app next week if I have a chance.
I'm thinking of- should FIG interfaces depend on a certain existing library that's not in the core (yes - no)As it happened to me once I was writing the previous PSR proposal for cache and it surfaces again
There's still a day or two before I close this one and run the numbers. So far turnout is way below what it was for the first poll, so I'm hoping to get more voting members especially to take 30 seconds to give their input.
Because there's no place to enter comments in the form, I'll add mine here:
The benefit of "FIG interfaces should only standardize established patterns already in widespread use, even if they are only a rudimentary "lowest common denominator"" is that we know, for a fact, that they are actually useful and solve existing problems. The work has already been done in a lot of ways.
The problem with "FIG interfaces should be robust and flexible, even if that means using patterns not already in common, widespread use" is that we then get into the business of designing them (mostly) from scratch, and doing so without benefit of actual usage in the field. Design discussions of this sort take a very long time to resolve, and since they are never tested with real usage before they are finalized, are prone to much more serious flaws.