[POLL] FIG Interface Focus

[lgar...@gmail.com]

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:
https://docs.google.com/forms/d/1Ov_CIWDw_od9ADMzNX441VgNmOGfk0lhAWWnyAdqGXc/viewform?sid=2b5f0b7b0eca7c9f&token=Ye3fcT0BAAA.kS-SreG1JLFCfiPyMG3Gyg.cTvtiV_130cwvsRIHwIu7A

FIG Interface Focus

This brief survey is intended to poll how members of FIG and other active participants feel we should be approaching the development of interface standards.

Should FIG "standardize what is" or "develop future-looking patterns"? *

Which statement is closer to your view?

	1	2	3	4	5	6	7	8	9	10
FIG interfaces should only standardize established patterns already in widespread use, even if they are only a rudimentary "lowest common denominator" Select a value from a range of 1,FIG interfaces should only standardize established patterns already in widespread use, even if they are only a rudimentary "lowest common denominator", to 10,FIG interfaces should be robust and flexible, even if that means using patterns not already in common, widespread use,.											FIG interfaces should be robust and flexible, even if that means using patterns not already in common, widespread use

Are you a voting member of FIG? *

• Yes
• No

What project do you represent?

If you're a FIG member, specify the project. If you are not, specify the *one* project with which you feel most closely affiliated. (Leave blank if none.)

Never submit passwords through Google Forms.

Powered by

This content is neither created nor endorsed by Google.
Report Abuse - Terms of Service - Additional Terms

[Andreas Möller]

Your survey is impossible to be answered if you do not agree that PHP FIG should develop recommendations towards interfaces. 

Andreas
--

Andreas Möller

Web Developer

a...@localheinz.com

--
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.
 
 

[Larry Garfield]

True, but since all but one respondent to the previous poll said FIG should pay at least a little attention to them, and the overwhelming trend was toward emphasizing interfaces et al over soft-specs, I don't think that's an issue.

--Larry Garfield

[Florin Patan]

Larry could you consider opening another poll if this one can't be edited in order to address another question as well?

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.

Best regards,

Florin

[Michael C]

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.

 

Thanks,

Michael Cullum

 

( )

( )

( )

( )

( )

( )

( )

( )

( )

( )

FIG interfaces should be robust and flexible, even if that means using patterns not already in common, widespread use

Are you a voting member of FIG? *

·         ( ) Yes

·         ( ) No

What project do you represent?

If you're a FIG member, specify the project. If you are not, specify the *one* project with which you feel most closely affiliated. (Leave blank if none.)

[Submit]

Never submit passwords through Google Forms.

Powered by

This content is neither created nor endorsed by Google.

Report Abuse - Terms of Service - Additional Terms

--
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.
 
 

--
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.
 
 

--
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.

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/eBrEXdCRWmQJ.

[Evert Pot]

I don't really like voting on this one. I have a clear opinion about this topic when it comes to caching specifically (lowest common denominator ftw), but I'd want to look at that on a case-by-case basis :)

Evert

> This content is neither created nor endorsed by Google.
> Report Abuse - Terms of Service - Additional Terms
>
>

[Larry Garfield]

I goofed slightly and didn't make the "name" field required.  I've changed that now.  However, there are 4 people that didn't submit their name, including one voting member.  If that's you, *you must resubmit the form*.  I'm not going to count submissions without names.  If you're not sure if you included your name, go ahead and resubmit to be sure.  I'll take care of filtering out duplicates.  Sorry for the hiccup.

--Larry Garfield

[Larry Garfield]

If there's enough interest, sure. I have another one lined up already
for after this one closes. :-) (I'm not sure if it's better to do them
all at once or bit by bit.)

--Larry Garfield

[Paul Jones]

Hi all,

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.

Compare, if you will, the log discussion vs the cache discussion. The one started with real-world examples and (eventually) got some research behind it, and was done in a couple of months; the latter started mostly from scratch, lacks research comparisons to existing work, and goes on and on and on.


-- pmj

[Michael C]

Great, I certainly think these polls are a great way to gauge views from the
wider community and present them in a hard, statistical way and you don't
need to read 100 emails to know the outcome/consensus.

The one problem I see with them is perhaps people don't think about their
answer as much compared to a message to the ML but the benefits outweigh the
disadvantages.

Michael C

> -----Original Message-----
> From: php...@googlegroups.com [mailto:php...@googlegroups.com] On
> Behalf Of Larry Garfield
> Sent: 16 March 2013 17:16
> To: php...@googlegroups.com
> Subject: Re: [POLL] FIG Interface Focus
>

[Phil Sturgeon]

Larry could you consider opening another poll if this one can't be edited in order to address another question as well?

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

Interfaces should be generic, there is no way they should be relying on random third-party non-core packages. But feel free to start up your own poll, because adding questions to an existing one means some folks wont get a chance to answer the new questions.

[Larry Garfield]

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.

--Larry Garfield

On 03/16/2013 01:23 AM, lgar...@gmail.com wrote:

[Beau Simensen]

On Thursday, March 21, 2013 11:54:30 PM UTC-5, Larry Garfield wrote:

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.

It seems like there has been very little FIG traffic in general for the last week or so. This might be contributing to lower voting numbers. On the other hand, it could be the poll itself? I had it open a day or so after you posted it and I kind of stared at it blankly. I sort of felt similar to Evert, I feel like I'd want to vote on this one on a case-by-case basis.

I thought about it a little bit more and decided I would cast my vote for what I thought was closer to my ideal goals for FIG. I think we should always be looking toward the future and not putting all of our focus on what we have now. Sometimes it may be the case that the current solutions the majority have been using for years are the right solutions. Sometimes it is not.

[Amy Stephen]

On Saturday, March 16, 2013 12:46:54 PM UTC-5, pmjones wrote:

Hi all,

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.

+1 Paul ... and, to add, that it satisfies the groups goal of interoperability.  Wasn't that the goal? To figure out ways to use code from various projects together? Knowing that overtime, that might reduce duplication and increase value.

If the effort is about determining what is the best code, then isn't this about making FIG a new project we are all contributing towards that will eventually take over member projects?

Not to suggest I think the second will come true. I've been on enough personal journeys were I opted for what is perfect over what is realistic enough, winding up with very little at the end. In sum, that's my fear for FIG at this point.

I hope member projects get a good handle on scope and process soon. I think this is a very important initiative.

[Moisa Teodor]

On Sat, Mar 16, 2013 at 7:46 PM, Paul Jones <pmjo...@gmail.com> wrote:

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.

+1 on that.

--
Doru Moisa
web: http;//moisadoru.wordpress.com
tel: +40 720 861 922
Bucharest, Romania

[Larry Garfield]

And results!

The data and analysis is here:

https://docs.google.com/spreadsheet/ccc?key=0AsMrMKNHL1uGdDdhSTI2WjdzWnNablZuODRqTmRqdnc#gid=1

Once again, the scale was:

1) Standardize what is, even if that means lowest-common-denominator.
10) Look toward the future, even if that means not fully proven techniques.

Analysis:

- Turnout was much lower this time, with only about half of voting
members participating. So, take with the appropriate quantity of salt.
(And harass other voting members to participate. I really think this is
a useful tool for consensus building.)

- I added a standard-deviation calculation to both this and the previous
survey. The standard deviation was considerably higher for this poll
than the last. For the focus poll, stdev was about 2 overall, and 1.6
among members. That is, reasonably consensused. (Or whatever the word
is.) For this poll, it is 3 overall and 2.4 among members. So there's
less of a clear consensus.

- That said, the median rating overall, among members, and among
non-members was 7. The average was 6.14 overall and 6.85 among members;
that is, members marginally leaned more toward future-looking.

- The most common score though was 8.

- Once again, Symfony had the most participants (although the Symfony
representative, Fabien, didn't vote).

Interpretation:

(Aka, the Larry-subjective part)

My take on these data is that we should be "cautiously forward
looking". We should not be really innovative, or developing new ideas
or techniques out of whole cloth. This isn't the place for that.

At the same time, however, we should not constrain ourselves to just
"document what is". Just because something isn't universal doesn't mean
we shouldn't be developing a spec for it, or using a given technique.

The guideline I'd recommend is :
* Is no existing implementation in this space doing it this way? Let's
not go there yet.
* Is at least one implementation in this space doing it this way? Let's
consider it, cautiously.
* Are at least 2 implementations in this space doing it this way? Let's
fully consider it on its merits.
* All else equal, which approach would allow for more
backward-compatible experimentation and extension by others, and/or
extension by future PSRs? Let's do that.

Does that seem like a reasonable guideline for us to take, given the
above data?

--Larry Garfield

[Michael C]

I'd say those are good points to take away and use as rules of thumb.

I do agree that voting turnout could have (and probably should have) been higher, especially from voting members. Whilst I don't think comparing it to the previous poll is very fair considering how much external interest the previous issue was generating and how important it was to the fabric of the group, I believe we should still have had more regular members voting.

These polls are are a good way to gauge opinion from voting members and the public. They also help us both reach consensus and show, in a non-subjective (or less subjective at least) statistical fashion, what that consensus is.

Thanks to Larry for once again for the time spent formulating formulae to calculate all this.

--
Thanks,
Michael Cullum