Re: [VOTE][CC] Errata bylaw update

[Beau Simensen]

+1

On Thursday, July 9, 2020 at 3:46:46 AM UTC-5, Alessandro Lai wrote:
>
> Since the mandatory two weeks are passed on the discussion (
> https://groups.google.com/g/php-fig/c/CObJmc5jDcE), I'm hereby calling a 
> CC vote for this bylaw change.
>
> As always, quorum is 50%, majority 2/3.
> Vote will end July 23rd, 23:59:59 UTC.
>
> THIS THREAD IS FOR CORE COMMITTEE VOTES ONLY
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/dc798354-389c-494b-a18d-1b0537352d44o%40googlegroups.com.

Re: [VOTE][CC] TYPO3 Membership vote

[Beau Simensen]

+1

On Friday, July 3, 2020 at 2:16:34 AM UTC-5, Alessandro Lai wrote:
>
> This thread is to collect votes on the TYPO3 Membership vote.
>
> Details:
>  - membership request: 
> https://groups.google.com/d/topic/php-fig/qDOyOuLuoKc/discussion
>  - proposed project representative: Benni Mack, which is project lead
>  - request sponsored by Matteo Beccati 2 weeks ago: 
> https://groups.google.com/d/msg/php-fig/qDOyOuLuoKc/HtwMXZ_jBgAJ
>
>
> Quorum: 50%
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#membership-vote
>
> ONLY CORE COMMITTEE MEMBERS CAN VOTE HERE
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/59ce1354-3e61-4581-99fb-9e840e1ef10co%40googlegroups.com.

Re: [VOTE] Core Committee Election

[Beau Simensen]

 - Korvin Szanto
 - Chris Tankersley
 - Ben Edmunds
 - Enrico Zimuel
 - Massimiliano Arione

On Friday, January 10, 2020 at 2:42:17 AM UTC-6, Alessandro Lai wrote:
>
> Hello everyone,
> as specified in the previous thread (
> https://groups.google.com/d/topic/php-fig/te-IAmuZte0/discussion), 
> yesterday at midnight UTC the nominations ended, and since today it's 
> possible to vote for the renewal of the terms that are up for this 
> elections.
>
> We have *4 spots on the Core Committee* up for reelection; we also have 
> one full-term spot for secretary but, since we have only one unopposed 
> nomination for the secretary election, we will need to vote for the Core 
> Committee positions only, for which we have five nominations (listed in 
> chronological order of nomination):
>
>  - Enrico Zimuel: 
> https://groups.google.com/d/topic/php-fig/G9O263am5Bs/discussion
>  - Massimiliano Arione: 
> https://groups.google.com/d/topic/php-fig/CXS_djlzI6E/discussion
>  - Korvin Szanto: 
> https://groups.google.com/d/topic/php-fig/suq1VFu3N8Y/discussion
>  - Chris Tankersley: 
> https://groups.google.com/d/topic/php-fig/O-qPhtb3li4/discussion
>  - Ben Edmunds: 
> https://groups.google.com/d/topic/php-fig/xk6cHWzOr6s/discussion
>
> Full information about the Core Committee vote and role is visible in the 
> bylaws here: 
> https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee
>
> *Who can vote?*
> As specified in the bylaws, any Project Representative or any participant 
> in the PHP-FIG ML can vote on the CC elections. A ML participant is defined 
> in the bylaws as follows:
> "Any individual that has posted a non-trivial message in the official 
> PHP-FIG venue (mailing list, forum, etc.) at least five (5) times within 
> the past calendar year as of the start of nominations [...] is eligible to 
> vote on Core Committee candidates."
>  
> *When can you vote?*
> Voting will be open in this thread until January 23rd 23:59:59 UTC.
>
> *How to vote*
> The voting system used is STV[1][2], so basically, there is no tactical 
> voting possible (like with FPTP); vote for who you want, even if they are a 
> less popular candidates as your vote will move down to a different 
> candidate if you back an unpopular candidate who doesn't have enough votes; 
> if a candidate is elected, their surplus votes are also re-allocated so you 
> are not punished for backing popular candidates either. There is no quorum, 
> you are of course entitled to not vote and it will not count as a missed 
> vote on the voting sheet. Rank the candidates in order of preference for 
> example:
>
> 1. Luke
> 2. Leia
> 3. Anakin
> 4. Rey
> 5. Padmé
> 6. Finn
>
> At the end of the voting phase I will be announcing the results, and all 
> the newly elected (both CC members and secretary), as announced before.
> Thanks!
>
> Alessandro Lai
> PHP-FIG Secretary
>
> [1]: STV User-friendly Explanation 
> https://www.youtube.com/watch?v=l8XOZJkozfI
> [2]: https://en.wikipedia.org/wiki/Single_transferable_vote
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a9e060ba-3369-4ef8-b6f4-1398c2577f34%40googlegroups.com.

[Nomination][CC] Chris Tankersley

[Beau Simensen]

I re-nominate Chris Tankersley for the position of Core Committee member. 
Chris is also the FIG representative for Sculpin, and he has been an active 
member of both FIG and the larger the PHP community for many years. I trust 
his continued involvement with the CC will continue to be a benefit to this 
organization.

Beau Simensen
PHP-FIG CC

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a665759a-d4ab-46c3-bea9-f8a860658f41%40googlegroups.com.

Re: Underscore for delimiting version numbers with dots in PSR-1

[Beau Simensen]

Late on this one, but in most of the projects I've seen have migrations in 
their own directories. If your project is similar, you might consider 
simply excluding that directory from any automated tools that might be 
doing checks for style issues. You can either ignore those directories 
outright, or tweak the rules for to fit your constraints for that 
directory, like "PSR-1 but [exceptions here]." You'd essentially have two 
separate checks, then.

This probably isn't required in your case, though, as my understanding of 
PSR-1 is there is no problem with having underscores in any part of the 
fully qualified classname. The example in PSR-1 that you linked is showing 
that you should not use _'s for the purpose of namespacing for PHP 5.3+ 
code. Code written for PHP 5.2.x doesn't have namespaces so it can only 
rely on _'s for the purpose of namespacing.

Specifically, the rule for PSR-1 states "*Code written for PHP 5.3 and 
after MUST use formal namespaces"* but does not say anything about *not 
including _'s in namespace or class names*.

There is some ambiguity between PSR-0 and PSR-4 in how _'s are treated in 
resolving the final path to the file that contains the code for a given 
class name, so _'s might be tricky unless you are explicitly using PSR-4. 
However, a lot of projects (like Laravel, for one) don't actually keep the 
version / date / number information in the class name itself and relies on 
something like Composer's classmap autoload functionality.

PSR-4 itself actually includes an example of a class with an _ in the name 
( \Acme\Log\Writer\File_Writer ):

https://www.php-fig.org/psr/psr-4/#3-examples

Hope this helps. :)


On Thursday, October 17, 2019 at 1:17:34 PM UTC-5, Anton Komarev wrote:
>
> How would it help? Class names should be unique, and uniqueness achievable 
> by adding version numbers to it. Even if we'll move version numbers to 
> directories - it wouldn't do the trick because same issue will appear in 
> namespace.
>
> четверг, 17 октября 2019 г., 19:57:35 UTC+3 пользователь Asmir Mustafic 
> написал:
>>
>>
>>
>> On Thursday, 17 October 2019 18:31:12 UTC+2, Anton Komarev wrote:
>>>
>>>
>>> For example migration `from 10.11.2 to 10.11.3` version will look like: 
>>> From10102To10103
>>> This variant will be much readable: From10_11_2To10_11_3
>>>
>>> How to deal with version numbers delimited with dots in class names?
>>>
>>> Probably this does not answer directly your question, but projects as 
>> doctrine migrations allows you to place classes in sub-directories (this 
>> namesapces) grouped by year/month. In this way the number of classes in the 
>> same folder is really lower.
>>
>>
>> Asmir
>>
>>
>>
>>  
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/172cfc7c-f4f3-4a86-8d94-960820808f03%40googlegroups.com.

Re: [VOTE][CC][BYLAW] PSR evolution

[Beau Simensen]

+1

On Monday, November 11, 2019 at 3:48:24 AM UTC-6, Alessandro Lai wrote:
>
> Hello everyone,
> after a long review phase of my PR and multiple fixes and amendments, I 
> think it's now ready: 
>
> https://github.com/php-fig/fig-standards/pull/1195
>
> The PR adds a new document that addresses the issue of upgrading the code 
> of a PSR to leverage new language features. I started working on this draft 
> after a long discussion here on the ML (
> https://groups.google.com/d/topic/php-fig/OyC3plRYhqg/discussion), after 
> that the issue surfaced many times on our communication channels. 
>
> The PR has been reviewed by multiple parties, and I consider it now ready 
> to be put to a vote. So I hereby call a bylaw vote, following our Voting 
> Protocol: 
>
> https://www.php-fig.org/bylaws/voting-protocol/
>
> THIS THREAD IS FOR VOTES OF THE CORE COMMITTEE ONLY; there will be another 
> thread for Project Representative; any other message or "vote" will be 
> ignored. As always, you can vote with a +1, +0 or -1, you will have a 
> period of two weeks to cast your vote, so this will be closed after 
> 23:59:59 UTC of Monday 25th.
>
> There is a 50% quorum for this vote, and a 2/3 majority is required for it 
> to pass.
>
> Thank you.
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/b5d51a60-4a73-4b1f-80b8-ce03924a86e0%40googlegroups.com.

Re: [VOTE] [Accept] PSR-12 Extended Coding Style Guide

[Beau Simensen]

+1

On Friday, July 26, 2019 at 11:10:54 AM UTC-5, Chris Tankersley wrote:
>
> Finally, after a very long review period and much discussion and tweaking, 
> I think we are finally ready for the acceptance vote for PSR-12.
>
> The specification can be found here:
>
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
>
> And the meta document here:
>
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md
>
> Thank you to everyone involved!
>
> -- 
> Chris Tankersley
> http://ctankersley.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/d477b4af-c13b-403f-9e6e-cded4ccbe8c0%40googlegroups.com.

Re: [VOTE] Core Committee Election

[Beau Simensen]

 1 Beau Simensen
 2 Matteo Beccati
 3 Benni Mack
 4 Woody Gilk
 5 Matthew Weier O'Phinney
 6 Larry Garfield
 7 Adam Englander

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/18ceac4d-faeb-4497-b184-878f402736c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-14 Event Dispatcher

[Beau Simensen]

On Wednesday, January 30, 2019 at 12:05:11 PM UTC-6, Cees-Jan Kiewiet wrote:
>
> As of today, with a unanimous vote from the working group, we formally 
> begin the REVIEW phase of the proposed PSR-14 (Event Dispatcher) 
> specification. The proposed specification is in the fig-standards 
> repository at the following locations: 
>
> - Specification:  
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md
>  
> 
>  
> - Metadocument:  
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md
>  
>
> During the Review phase, acceptable changes to the specification include 
> wording, typographical fixes, and clarifications. If you feel major changes 
> are necessary or have, please bring your arguments/questions to the list 
> under this thread. If any major changes are considered, we will return to 
> the Draft phase. 
>
> The Review period will end no sooner than 27 Jan 2019 at 11:59pm.  At that 
> time, if the working group can demonstrate two viable trial 
> implementations, and no need for major changes, I will call for an 
> Acceptance Vote. 
>

I've read the spec, meta document, taken a look at two reference 
implementations, and explored the util package. If the working group is 
happy with the spec as-is, I have little to add or ask questions about at 
this point with one minor exception.

This wording seems a bit unclear: "Listener Providers MUST treat parent 
types identically to the Event's own type when determining listener 
applicability." It seems like there should be an easier way to say this 
that is more direct?

At the same time, the bit just below the example reads: "A Listener 
Provider MUST treat listener() as an applicable listener for $b, as it is 
type compatible, unless some other criteria prevents it from doing so."

Listener Providers MUST treat parent types identically, unless some other 
criteria prevents it from doing so? Is that the correct way to read this?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/28b357de-5785-4070-b0d4-57395c15ff6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ACCEPTANCE VOTE][CC] PSR-18 HTTP Client

[Beau Simensen]

+1

On Sunday, October 14, 2018 at 9:46:40 AM UTC-5, Sara Golemon wrote:
>
> The REVIEW period for the proposed PSR-18, HTTP Clients, hit its minimum 
> required length on 19 September 2018. We continued the period since then to 
> iron out additional clarifications to the specification, which have all 
> since been merged.
>
> At this time, I am opening an ACCEPTANCE VOTE. Per the by-laws, the  
> acceptance vote is limited to Core Committee members. The vote will close 
> either at 23:59:59 UTC on 28 October 2018, or when all CC members have cast 
> their vote, whichever comes earlier. 
>
> The relevant materials are as follows: 
>
> - Specification:  
> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client.md
>  
> - Metadocument:  
> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>  
>
> PLEASE DO NOT VOTE UNLESS YOU ARE A CC MEMBER.
> Current CC Members are as follows:
>
> Beau Simensen
> Larry Garfield
> Matthew Weier O’Phinney
> Sara Golemon
> Cees-Jan Kiewiet
> Lukas Kahwe Smith
> Samantha Quiñones
> Chris Tankersley
> Korvin Szanto
> Stefano Torresi 
> Michael Cullum
> Chuck Burgess
>
> -Sara
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/05b834ce-86a8-4fce-9621-3e2e2bb0f0fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-14][Entrance][VOTE]

[Beau Simensen]

+1

On Sunday, April 8, 2018 at 11:01:51 PM UTC-5, Larry Garfield wrote:
>
> I  hereby call an Entrance Vote to restart PSR-14, Event Dispatcher. 
>
> The proposed working group is as follows: 
>
> Editor:  Larry Garfield 
>
> Sponsor: Cees-Jan Kiewiet 
>
> Other Group Members: 
>
> Elizabeth Smith 
> Benjamin Mack 
> Matthew Weier O'Phinney 
> Ryan Weaver 
>
> The revised scope and charter is in this PR: 
>
> https://github.com/php-fig/fig-standards/pull/1016 
>
> This is an Entrance Vote only, so it's a vote to say "yes, we should have 
> one" 
> rather than a statement on any particular implementation detail. 
>
> This vote is open to Core Committee members only.  Everyone else, please 
> hold 
> your horses. :-)  Please give a +1/-1.  The vote is open until 23 April or 
> until all 11 CC members have voted, whichever comes first. 
>
> --Larry Garfield

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/cc520e84-441d-4669-b4bb-d7da0cb77e01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC][VOTE] PSR-17 Working Group

[Beau Simensen]

+1

On Monday, February 5, 2018 at 12:22:37 PM UTC-6, Matthew Weier O'Phinney 
wrote:
>
> Last year, in May, I opened a discussion period regarding the PSR-17 
> working group, as the proposal pre-dated the latest by-laws... and 
> then evidently forgot to open a vote for it. 
>
> So, I'm opening a vote as of today, 2018-02-05. Per the by-laws, this 
> vote is for Core Committee members only, and will run until all 
> members have voted, or 23:59:59 on 2018-02-19, whichever occurs 
> soonest. 
>
> The proposed working group is as follows: 
>
> - Editor: Woody Gilk 
> - Sponsor: myself 
> - Members: Stefano Torresi, Matthieu Napoli, Korvin Szanto, Glenn 
> Eggleton, Oscar Otero, and Tobias Nyholm. 
>
> -- 
> Matthew Weier O'Phinney 
> mweiero...@gmail.com  
> https://mwop.net/ 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/2ed1ba9e-93bc-43a6-aa5a-8a1d2706439b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][Internals] Secretary election

[Beau Simensen]

Mark Railton
Robert Parker


On Friday, January 12, 2018 at 8:37:01 AM UTC-6, Alessandro Lai wrote:
>
> Hello everyone,
> as specified in the previous thread (
> https://groups.google.com/forum/?fromgroups#!topic/php-fig/EKDIoSHqMSo), 
> yesterday at midnight the nominations ended, and since today it's possible 
> to vote for the renewal of the terms that are up for this elections.
>
> These are the nominations results: 
> https://docs.google.com/spreadsheets/d/1u_Bi2EXJ47iC_xMAUjkJWjz7Gks_BCW15RDXy_qXR9c/
>
> Since we have 4 unopposed nominations for the CC spots (and the terms are 
> all equals, so no sorting is necessary), we will need to vote for the 
> secretary position only, for which we have two nominations:
>
>  - Mark Railton 
> https://groups.google.com/forum/#!topic/php-fig/U5eaI90NOsc
>  - Robert Parker 
> https://groups.google.com/forum/?fromgroups=#!topic/php-fig/BjxM9CVZ3Bg
>
> Full information about the Secretary vote and role is visible in the 
> bylaws here: 
> http://www.php-fig.org/bylaws/mission-and-structure/#secretaries 
> 
>
> Normally we should use STV, but since we have just one term and two 
> candidates, it will be the same if we simply vote with one direct, single 
> preference. So, to recap:
>
> *Who can vote?*
> As specified in the bylaws, *any Project Representative or Core Committee 
> member* is eligible to vote on Secretary candidates.
>
> *When can you vote?*
> Voting will be open *until 26th January 23:59 UTC.*
>
> *How to vote*
> The voting system used is STV[1][2], so basically, *there is no tactical 
> voting possible* (like with FPTP); *vote for who you want*, even if they 
> are a less popular candidates as your vote will move down to a different 
> candidate if you back an unpopular candidate who doesn't have enough votes; 
> if a candidate is elected, their surplus votes are also re-allocated so you 
> are not punished for backing popular candidates either. There is no quorum, 
> you are of course entitled to not vote and it will not count as a 
> missed vote on the voting sheet. *Rank the candidates in order of 
> preference *for example*:*
>
> 1. Luke
> 2. Leia
> 3. Anakin
> 4. Rey
> 5. Padmé
> 6. Finn
>
> At the end of the voting phase I will be announcing the results, and all 
> the newly elected (both CC members and secretary) on the 28th, as announced 
> before.
>
> Thanks!
>
> Alessandro Lai
> PHP-FIG Secretary
>
> [1]: STV User-friendly Explanation 
> https://www.youtube.com/watch?v=l8XOZJkozfI
> [2]: https://en.wikipedia.org/wiki/Single_transferable_vote
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a9378e92-c15d-46e7-80d7-b9a9f6d9b7d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ACCEPTANCE VOTE][CC] PSR-15 HTTP Server Request Handlers

[Beau Simensen]

+1

On Friday, January 12, 2018 at 9:47:52 AM UTC-6, Matthew Weier O'Phinney 
wrote:
>
> The REVIEW period for the proposed PSR-15, HTTP Server Request 
> Handlers, hit its minimum required length on 2 January 2018. We 
> continued the period since then to iron out additional clarifications 
> to the specification, which have all since been merged. 
>
> At this time, I am opening an ACCEPTANCE VOTE. Per the by-laws, the 
> acceptance vote is limited to Core Committee members. The vote will 
> close either at 23:59:59 UTC on 26 January 2018, or when all CC 
> members have cast their vote, whichever comes earlier. 
>
> The relevant materials are as follows: 
>
> - Specification: 
>
> https://github.com/php-fig/fig-standards/tree/4b417c91b89fbedaf3283620ce432b6f51c80cc0/proposed/http-handlers/request-handlers.md
>  
> - Meta Document: 
>
> https://github.com/php-fig/fig-standards/tree/4b417c91b89fbedaf3283620ce432b6f51c80cc0/proposed/http-handlers/request-handlers-meta.md
>  
>
> Implementations include those implementing only the 
> `MiddlewareInterface` (e.g., middleware providers) to those 
> implementing full middleware frameworks. Below is a list of some that 
> we feel are particularly representative: 
>
> - https://github.com/northwoods/broker — Maintained by Woody Gilk, our 
> Editor, this is a middleware dispatcher. 
> - https://github.com/middlewares — Maintained by Oscar Otero, a 
> working group member, this is a suite of reusable PSR-15 middleware 
> implementations you can compose into an application. 
> - https://github.com/zendframework/zend-stratigility/pull/134 — This 
> is a patch to an upcoming 3.0 version of zend-stratigility (maintained 
> by Zend Framework) that demonstrates the project plans to implement a 
> pure PSR-15 middleware dispatcher (vs a hybrid dispatcher as we do in 
> version 2). It provides a hybrid request handler/middleware 
> implementation allowing creation of a queue of middleware, and uses an 
> intermediary request handler to manage and dispatch that queue. 
> - 
> https://github.com/zendframework/zend-expressive-skeleton/tree/release-3.0.0 
> — This is a proposed version of Expressive that uses Stratigility v3, 
> and thus represents a full PSR-15 middleware framework. The Zend 
> Framework project also has around 2 dozen middleware packages that all 
> have branches dedicated to PSR-15 support at this time; these are 
> representative of reusable PSR-15 `MiddlewareInterface` 
> implementations. 
> - https://github.com/ellipsephp/dispatcher — Maintained by Pierre 
> Mallinjoud, this is a PSR-15 middleware dispatcher that recursively 
> decorates a middleware queue in request handlers. 
>
> We identified around a half-dozen other projects as well, some of 
> which were still pinned to earlier revisions of the specification, but 
> theoretically compatible with little effort. As such, we more than 
> satisfy the minimum of 2 reference implementations. We can provide 
> additional links on request. 
>
> -- 
> Matthew Weier O'Phinney 
> mweiero...@gmail.com  
> https://mwop.net/ 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/c8386047-4f6c-4846-9199-af8634b10939%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] Secretary Election

[Beau Simensen]

1. Margret Staples
2. Alessandro Lai
3. Mark Railton

On Thursday, October 19, 2017 at 4:17:12 PM UTC-5, Michael Cullum wrote:
>
> Hi all,
>
> We've been attempting to get more nominations so this has been delayed a 
> few times but we now have three candidates so we're rolling with it.
>
> Full information about the Secretary vote and role is visible in the 
> bylaws here: 
> http://www.php-fig.org/bylaws/mission-and-structure/#secretaries
>
> You can check out their nomination topics and ask questions there.
>
> *Votes may be cast by project reps or CC members.* If an individual is 
> both a rep and a CC member, they may one vote once.
>
> *Nominations List*
>
>- Margret Staples - Topic 
>
>- Alessandro Lai - Topic 
>
>- Mark Railton - Topic 
>
>
> *How to vote*
> The voting system used is STV[1][2], so basically, *there is no tactical 
> voting possible* (like with FPTP); *vote for who you want*, even if they 
> are a less popular candidates as your vote will move down to a different 
> candidate if you back an unpopular candidate who doesn't have enough votes; 
> if a candidate is elected, their surplus votes are also re-allocated so you 
> are not punished for backing popular candidates either. There is no quorum, 
> you are of course entitled to not vote and it will not count as a missed 
> vote on the voting sheet. *Rank the candidates in order of preference *for 
> example*:*
>
> 1. Luke
> 2. Leia
> 3. Anakin
> 4. Rey
> 5. Padmé
> 6. Finn
>
> *You may, if you wish, not rank all three candidates* (however this is 
> relatively pointless in STV, only do this if your bottom candidates are of 
> equal preference to you). For example:
>
> 1. Luke
> 2. Anakin
> 3. Padmé
> 4. Leia
>
> *The vote ends at 23:59 UTC on the 2nd November,* and I will close the 
> vote and *announce the result at some point on the 3rd*. At any time, any 
> candidate or voting member may privately ask me to do a count and tell them 
> who would be elected to which term if the vote ended at that point. 
> Please be wary of 'STV calculators' on the internet as there are many 
> different ways of calculating the vote reallocation for STV and many are 
> inaccurate, our methods are dictated in the bylaws.
>
> Good luck to all the candidates!
>
> --
> Many thanks,
> Michael Cullum
> FIG Secretary
>
> [1]: STV User-friendly Explanation 
> https://www.youtube.com/watch?v=l8XOZJkozfI
> [2]: https://en.wikipedia.org/wiki/Single_transferable_vote
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/8bfa4c34-75d5-484e-b02c-1f01d9ceabdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][CC] Entrance vote for PSR-12: Extended Coding Style Guide

[Beau Simensen]

+1

On Thursday, October 19, 2017 at 11:39:36 AM UTC-7, Korvin Szanto wrote:
>
> Hi Everyone,
> PSR-12 was already accepted and assigned the number 12 back in FIG 2.0[0], 
> however, it turns out that my post on the 30th of June[1] was way too late 
> to qualify as a grandfathered recommendation. So in order to make sure we 
> follow the process properly, we're holding an entrance vote and asking 
> kindly that the CC allows us to keep the number 12. 
>
> Our working group is as follows:
>
> Editor:
> Korvin Szanto
>
> Sponsor:
> Chris Tankersley
>
> Working Group Members:
> Alexander Makarov
> Michael Cullum
> Robert Deutz
>
>
> If you'd like to read more about PSR-12, check out the completed draft[2] 
> and the meta document[3] but please keep in mind that we are not voting on 
> the content of this draft.
>
> Thank you for your time!
> Korvin Szanto
>
> [0]: https://groups.google.com/d/msg/php-fig/P9atZLOcUBM/_jwkvlYKEAAJ
> [1]: https://groups.google.com/d/msg/php-fig/iqLzVvj6C2c/2hEOAQFbAAAJ
> [2]: 
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
> [3]: 
> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a59b7b6a-5c45-4537-84f6-a0d563187950%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minimal HTTP middleware

[Beau Simensen]

On Wednesday, May 17, 2017 at 12:42:29 AM UTC-5, Rasmus Schultz wrote:
>
> I think it's great that you're coming around to the idea, Woody :-)
>
> But I am no longer trying to view this as an alternative to PSR-15, 
> because, assuming we standardize on that handler-interface first, there is 
> nothing about PSR-15 that prevents us from exploring other options.
>

Indeed, if the end result of this discussion is extracting 
DelegateInterface into its own proposal as its own handler interface that 
can be used as the delegate in PSR-15, I'm happy with that.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/eefff869-eac0-47c7-b946-5d2149519aa8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minimal HTTP middleware

[Beau Simensen]

On Sunday, May 14, 2017 at 11:13:46 AM UTC-5, Rasmus Schultz wrote:
>
> > the middleware themselves cannot be autowired and *must* be created 
> manually by the factory.
>
> Are you highlighting this as a problem?
>
> Of course the factory would need to create the middleware - that's what a 
> factory is for. (?)
>

I think there is confusion between your solution and the middle-ground 
David was proposing. I had hoped I kept that post more clear but it appears 
I failed. :( My bad.

First, yes, it is a problem because a middleware that could previously be 
autowired can now only be created manually by a factory, even though the 
middleware has not changed much at all.

Second, with the existing proposal we don't need a factory. Yes, David's 
proposal has a factory so yes, obviously, it should be used to create the 
middleware. If we ended up going with something like David proposed, I do 
not disagree that this is where the middleware should be created. :)

My entire set of example code was intended to show what would happen to one 
of my real world middleware if we implemented Davdi's proposal.

 

> > At the end of the day it comes down to whether the delegate/next of a 
> middleware should be a runtime dependency or an instance dependency. I 
> think that is the core of what Rasmus is exploring here. It seems like he 
> has decided it should not be a runtime dependency
>
> I don't feel it's a decision so much as a conclusion.
>
> I'd like it not to be the case, because it would surely be simpler, but 
> the fact is that there isn't always precisely one delegate - which leads me 
> to conclude it can't be a runtime dependency, or at least not if you want 
> the model to reflect reality, which is something I always strive for.
>

This is the same reasoning I would use to argue for why the delegate should 
be a runtime dependency. There is never precisely one delegate. The state 
that is important at the point in time that the middleware is executed is 
the request and the delegate. The middleware instance itself does not 
depend on the delegate any more than it does on the request.

 

> > I'm not happy about the idea that every middleware is going to 
> effectively require two classes be written
>
> Let's explore that problem.
>
> I think, first of all, you need to not think of this as "middleware 
> consisting of two classes" - it's really two different classes, one is a 
> handler, the other is middleware: they have different purposes in different 
> contexts.
>

Again, this line of thought was directly related to David's proposal.

I'm confused by what you said here, though, so maybe you can elaborate. Not 
sure if this is talking about something else or about David's proposal 
or?

What I had said was not that "middleware would consist of two classes", but 
that "writing middleware would require writing two classes." Since this was 
about David's proposal, this was a factory and a middleware. Where I 
previously had one middleware class, it turned into a middleware class and 
a factory class. The example I shared showed the BEFORE code with one 
MiddlewareInterface implementation and AFTER showed two classes, a 
MiddlewareFactoryInterface and a MiddlewareInterface.

What you said is something different. What do you mean by "one is a 
handler, the other is a middleware?" Also, "they have different purposes in 
different contexts." Can you show me what that looks like using the example 
code I shared with BEFORE / AFTER on the User ID metadata enricher 
middleware? Because I'm starting to wonder if I've completely missed 
something major here. Probably easiest to just start with the simple BEFORE 
middleware and then I'd be able to compare against what I came up with for 
my AFTER to see if I can follow this better.

 

> If the only problem is deferring the loading and creation of handlers, and 
> the issue is "not knowing" which constructor-argument is the delegate, 
> maybe we could solve this by marking that argument somehow...
>

I think that has been the biggest sticking point for me. We never had a 
good solution for this for Stack except for the conventions that allowed 
Stack Builder to be successful. It suffered drawbacks as discussed 
previously in this thread.

If this bit of code is doing what I think it is, it might be an interesting 
idea:

https://bitbucket.org/mindplaydk/middleware-experiment/src/d5c26eba9e445f2f9d2b9f3fd8ee465812c2ab0c/src/Dispatcher.php?at=master=file-view-default#Dispatcher.php-49

The only problem is that I'm not sure how many containers would support 
this. I *think* this is the first time I've seen this in a container.



I'm still hung up on the runtime dependency vs not. I don't agree with the 
conclusion. That doesn't mean I cannot be convinced otherwise. :)

I think I'm starting to better understand what you're getting at, though. 
Is this an accurate summary of your conclusion?

The only difference between a handler and a middleware is the delegate. If 

Re: Minimal HTTP middleware

[Beau Simensen]

On Saturday, May 13, 2017 at 12:31:20 PM UTC-5, Woody Gilk wrote:
>
> On Sat, May 13, 2017 at 12:12 PM, Rasmus Schultz  > wrote:
>
>> What do you mean by "middleware that does not return a response"?
>>
>
> Ultimately it will. In PSR-15 this is done via delegate. My question is 
> more about how the interfaces proposed by David would do this delegation. 
> Right now I don't see how it would be possible without passing a factory to 
> a middleware, which (I thought) he was attempting to avoid.
>

I don't think that was what he was attempting to avoid. I think his was an 
attempt to solve the DI problem (the thing I care about) while still not 
having to pass the delegate to every middleware handle/__invoke call (I 
believe the idea that Rasmus is exploring). From what I see, this is done 
by injecting a factory concept into the workflow.

The factory would receive the next/delegate at runtime and could thus be 
instantiated by an autowiring DI container upfront without any problems.

It still requires the individual middleware & factory combo to have a way 
to ensure that the middleware instance stores the next/delegate prior to 
being invoked. Which means, most likely, that the middleware themselves 
cannot be autowired and *must* be created manually by the factory.

In my mind, it moves the magic around in a way that is slightly more 
automated (meaning, I'd only be able to whine about DI concerns at a 
fraction of the volume of before because the *middleware factory* can still 
be autowired...) at the expense of adding an explicit factory to the 
workflow of every middleware.

While I think this is a great way to move the discussion forward, I'm not 
happy about the idea that every middleware is going to effectively require 
two classes be written. I would guess that most factories are going to end 
up being proxies and will have all of the dependencies of the original 
middleware just to pass them on via constructor injection.

Here is what this would look like using an actual middleware I've used in 
the past. I've kept the delegate naming for now just to show what we're 
actually talking about here in practical terms.

BEFORE

class UserIdMetadataEnrichment implements MiddlewareInterface
{
private $metadataEnricherChain;
private $userIdentityMapper;

public function __construct(
MetadataEnricherChain $metadataEnricherChain,
UserIdentityMapper $userIdentityMapper
)
{
$this->metadataEnricherChain = $metadataEnricherChain;
$this->userIdentityMapper = $userIdentityMapper;
}

public function __invoke(RequestInterface $request, DelegateInterface 
$delegate)
{
// ... do stuff

}
}



AFTER

class UserIdMetadataEnrichmentFactory implements MiddlewareFactoryInterface
{
private $metadataEnricherChain;
private $userIdentityMapper;

public function __construct(
MetadataEnricherChain $metadataEnricherChain,
UserIdentityMapper $userIdentityMapper
)
{
$this->metadataEnricherChain = $metadataEnricherChain;
$this->userIdentityMapper = $userIdentityMapper;
}

public function createMiddleware(DelegateInterface $delegate)
{
return new UserIdMetadataEnrichment(
$delegate,
$this->metadataEnricherChain,
$this->userIdentityMapper
)
}
}


class UserIdMetadataEnrichment implements MiddlewareInterface
{
private $metadataEnricherChain;
private $userIdentityMapper;
private $delegate;

public function __construct(
DelegateInterface $delegate,
MetadataEnricherChain $metadataEnricherChain,
UserIdentityMapper $userIdentityMapper
)
{
$this->metadataEnricherChain = $metadataEnricherChain;
$this->userIdentityMapper = $userIdentityMapper;
$this->delegate = $delegate;
}

public function __invoke(RequestInterface $request)
{
// ... do stuff

}
}






At the end of the day it comes down to whether the delegate/next of a 
middleware should be a runtime dependency or an instance dependency. I 
think that is the core of what Rasmus is exploring here. It seems like he 
has decided it should not be a runtime dependency. I disagree.

If the same middleware class is used in several points throughout an 
application, why might each individual instance know about the delegate it 
is responsible for? In which situations would this impact how the 
middleware will actually run?

I've neither seen nor written middleware where the same instance mounted 
several places throughout an application did not work as intended and 
expected.


TL;DR?

The original proposal treats the delegate as a runtime dependency along 
with the request in question at that point in time. Rasmus is proposing the 
delegate becomes an instance dependency tying each instance of the 
middleware explicitly to a specific point in the application when it is 
constructed, 

Re: Minimal HTTP middleware

[Beau Simensen]

>
> What's a "non-response value"? You have "middleware" that doesn't return
> a Response object?


It was something I was playing with at the time. It worked fine w/ Relay as
Relay wasn't paying attention at all to what was returned from the
middleware.

This allowed actions run from the action handler middleware to return
values that were not response values that the view transformer middleware
could pick up. Provided the view transformer middleware was able to handle
whatever type object it got back from the delegate, it would transform it
into a response. The response assertion middleware would throw an exception
if a the response from its delegate was still not yet a ResponseInterface
instance.

This was experimental on my part. I remember talking to Matthew about it at
one point while I was working on it. I think it was an interesting idea but
definitely not a mainstream way to do things. I felt as long as my
framework was handling everything from ActionHandler to ResponseAssertion,
I'd be safe.

I'll be the first to say that not all of my ideas are the best ones. :)

I've since run into other middleware pipeline projects that ensure every
response is indeed a ResponseInterface instance. So I've adjusted this
behavior so that this work is done elsewhere. If I could apply this new
logic to the code I shared above, my stack would look like this:

NikicFastRoute::class, // routing
FixBrokenDiactorosCookieHeaderBehaviour::class, // workaround until a
cookie fix to diactoros could be tagged
CorsCompletelyOpenForDevelopment::class, // utility middleware that was
soon to be swapped for a better proper impl
UserAuthentication::class, // ensured that the request was made by an
authenticated user
OrganisationAuthorization::class, // ensured that the authenticated
user was authorized to access organisation resources
UserIdMetadataEnrichment::class, // used to ensure that the
authenticated user would be added to event envelopes
ActionHandler::class, // dispatcher



This goes into the discussion on creating a "handler" interface, I suppose.
Requiring the handler to always return a response object means that the
handler is going to have to do a lot. At the very least, the handler is
going to need to have a ResponseFactory injected into it. Having the option
to make my handlers support a hypothetical handler PSR would be nice, but I
would probably end up using ad-hoc handlers that could return
DTO/DomainObjects and have another layer that could convert those responses
into HTTP Responses. But I think that is a discussion for another thread at
this point.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAP75ejOAWsUQkbW%2BkZDR9ZLUbbV0xA1Ky%3DDqdahi%3D%3DgLvP2ymA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC][VOTE] PSR-15 WG

[Beau Simensen]

+1

On Tuesday, May 9, 2017 at 1:20:19 PM UTC-5, Matthew Weier O'Phinney wrote:
>
> As the two week discussion period regarding the PSR-15 working group 
> is now over, I am calling an entrance vote for the PSR-15 working 
> group, with the current membership: 
>
> - Editor: Woody Gilk 
> - Sponsor: myself 
> - Members: Stefano Torresi, Matthieu Napoli, Korvin Szanto, Glenn 
> Eggleton, Oscar Otero 
>
> As an entrance vote, this vote requires a quorum of 50%,or 6 voting 
> members of the core committee, and a 2/3 majority of those voting. 
>
> This vote is open to CORE COMMITTEE MEMBERS ONLY; please do not vote 
> unless you are a core committee member. 
>
> Voting will remain open until 23:59 UTC on 23 May 2017, or all members 
> of the CC have voted, whichever comes first. 
>
> -- 
> Matthew Weier O'Phinney 
> mweiero...@gmail.com  
> https://mwop.net/ 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/7a6795e9-c7ed-4fa2-b60a-7ac016b3a25d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minimal HTTP middleware

[Beau Simensen]

On Friday, April 21, 2017 at 10:42:11 AM UTC-5, Rasmus Schultz wrote:
>
>
> $kernel = new NotFoundMiddleware();
> $kernel = new RouterMiddleware(new Router(...), $kernel);
> $kernel = new CacheMiddleware($kernel);
> $kernel = new ErrorHandlerMiddleware();
>
>
Off the top of my head, it feels like this would be difficult to 
automatically wire with a DI container since each middleware will need to 
be constructed with the previous middleware already instantiated. 
Especially given you cannot have consistent known arguments, this will be 
difficult to automate.

return $this->container->get($id)->process($request);


I think you tried to address this with the ContainerProxyMiddleware but it 
skips the construction part. How would the container know which $kernel to 
use in the constructor for the object at $id? This looks nice, API-wise, 
but it is ignoring how this object would actually be constructed.

One of the things we did with Stack was required the first argument to 
always be the kernel and any additional arguments (if any at all) would 
have to follow after that. We used Stack Builder to help try and solve 
those problems. It still seemed messy and I was never very happy with it.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/99e602d1-e871-4d19-829a-1330252b508c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Vote] [Core Committee] Membership Application: Phergie

[Beau Simensen]

+1

On Monday, February 6, 2017 at 10:54:18 AM UTC-6, Chris Tankersley wrote:
>
> It's been well past 2 weeks while having a discussion period on allowing 
> Phergie as a member project, and here is the voting thread for Core 
> Committee.
>
> Please vote with a -1/0/+1, like normal.
>
> Discussion Thread: 
> https://groups.google.com/forum/?!topic%2Fphp-fig%2Fbz9sr8q8yHI#!topic/php-fig/bz9sr8q8yHI
>
> There is a separate thread for the Member Projects
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/39d3f511-4bb8-4bed-95ff-00ad015ab7e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] First Core Committee Elections

[Beau Simensen]

Beau Simensen
Matthew Weier O’Phinney
Larry Garfield
Samantha Quiñones
Jason Coward
Lukas Kahwe Smith
Korvin Szanto
Chris Tankersley
Cees-Jan Kiewiet
Graham Daniels
Tobias Nyholm
Jeremy Coates
Michael Heap
David Négrier
Sara Golemon
Steve Winter
Marc Alexander
Same Minée
Gary Hockin
Stefano Torresi


On Friday, December 9, 2016 at 10:47:36 AM UTC-6, Michael Cullum wrote:
>
> Hi all,
>
> We’ve finally got to the voting stage in the first set of Core Committee 
> Elections where 12 CC members will be elected to staggered terms.
>
> Candidates List (Alphabetical)
>
> 
>
> View full list of candidates with twitter handles and links to nomination 
> topics here <http://bit.ly/cc-election-candidates> (
> bit.ly/cc-election-candidates) or a list of names in copy/pasteable 
> format below.
>
> Beau Simensen
>
> Cees-Jan Kiewiet
>
> Chris Tankersley
>
> David Négrier
>
> Gary Hockin
>
> Graham Daniels
>
> Jason Coward
>
> Jeremy Coates
>
> Korvin Szanto
>
> Larry Garfield
>
> Lukas Kahwe Smith
>
> Marc Alexander
>
> Matthew Weier O’Phinney
>
> Michael Heap
>
> Samantha Quiñones
>
> Same Minée
>
> Sara Golemon
>
> Stefano Torresi
>
> Steve Winter
>
> Tobias Nyholm
>
> Role of the CC
>
> --
>
> The brief summary of the new FIG structure is summised in bit.ly/fig-3-0. 
> The quote pertaining to ‘What is the CC’ is:
>
> They hold the entrance votes and final acceptance vote. These votes are to 
>> see if the FIG wants to consider this problem for a PSR, and to have 
>> oversight of Working Groups and make sure working groups have all relevant 
>> stakeholders have their interests represented within them. Their final 
>> acceptance vote is on the quality of the spec, ensuring consistency 
>> throughout the FIG, ensuring it meets the FIG’s overall direction and aims, 
>> making sure stakeholders interests were represented, and the competence of 
>> the working group.
>
>
> Essentially they are a technical steering committee for the PHP FIG and it 
> is designed to represent (and be representative of) the entire PHP 
> ecosystem from different types of PHP project (Framework, Library, Consumer 
> Package) to non-PHP things that relate to the ecosystem like PHP Runtimes, 
> IDEs, PHP in business to different generalised areas of specialty such as 
> security or async.
>
> Who can vote?
>
> 
>
> You can vote if you are
>
>- 
>
>A project member
>- 
>
>Have been active in the FIG group’s discussions or activities within 
>the past 12 months and are listed here <http://bit.ly/cc-voters> (
>http://bit.ly/cc-voters).
>
>
> If you wish to be on the list of community members please see here 
> <https://gist.github.com/michaelcullum/9f5fd32efce27fb5517dd43bf814f16f#file-xnotetocandidates-md>
>  
> about how to be added. Votes of anyone not on the list will be discarded.
>
> How to vote?
>
> ---
>
> The voting system used is STV[1][2], so basically, there is no tactical 
> voting possible; vote for who you want, even if they are a less popular 
> candidates as your vote will move down to a different candidate if you back 
> an unpopular candidate who doesn't have enough votes; if a candidate is 
> elected, their surplus votes are also re-allocated so you are not punished 
> for backing popular candidates either. There is no quorum, you are of 
> course entitled to not vote and it will not count as a missed vote on the 
> voting sheet. 
>
> You may, if you wish, not rank all twenty candidates but only rank those 
> with whom you have a preference (top 5, 12, 15 etc.).
>
> Reply to this topic ranking the candidates in order of preference for 
> example:
>
> 1. Luke
>
> 2. Leia
>
> 3. Anakin
>
> 4. Rey
>
> 5. Padmé
>
> 6. Finn
>
> The vote ends at 23:59 UTC on the 23rd December, and the result will then 
> (hopefully/likely) be announced on the 24th December.
>
> Note to candidates:
>
> --
>
> People have asked about this so to clarify, you are highly encouraged to 
> vote for yourselves. For full rationale please see here 
> <https://gist.github.com/michaelcullum/9f5fd32efce27fb5517dd43bf814f16f#note-to-candidates>
> .
>
> Many thanks,
>
> Michael Cullum
>
> [1]: STV User-friendly Explanation 
> https://www.youtube.com/watch?v=l8XOZJkozfI
>
> [2]: https://en.wikipedia.org/wiki/Single_transferable_vote
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/cabf5c01-dd90-42f6-b347-2f3a3cd0850b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC] Candidate introductions

[Beau Simensen]

On Saturday, December 17, 2016 at 5:43:11 PM UTC-6, Magnus Nordlander wrote:
>
> Hi!
>
> In an effort to not have the CC votes just be a popularity contest, I 
> would like to know more about the candidates. Some of the candidates I know 
> personally, some I know by reputation, others I don't know at all. While I 
> can do some research into the candidates myself, I think it is would be 
> good, and make the elections more fair if candidates also do a pitch of 
> their own.
>
> I did notice the Korvin posted a short message in his nomination thread, 
> and I was hoping that the other candidates would follow suit. However, that 
> did not happen. While there have already been a fair number of votes cast, 
> I hope that such messages would help make up the minds of us remaining 
> voters.
>
> As such, I would welcome any and all of the candidates to give a reply 
> with a quick elevator pitch for their candidacy: Who they are, why they're 
> running, why they're a good candidate for the CC, what they want to 
> accomplish in the CC, etc.
>

I went with [About Candidate] but on looking back right after clicking send 
(as always) I realized that [Candidate Introduction] would probably have 
been better. Needless to say, I think this was a good idea. Great 
suggestion, Magnus. :) 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/bb0702b8-4532-47cd-8308-1bfea075a564%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Beau Simensen]

On Tuesday, July 12, 2016 at 3:26:42 PM UTC+1, Rob Allen wrote:
>
> Where did the word "Frame" come from and in what context is it used. It 
> means nothing to me and I don't think I'm alone in having no clue how I 
> would be able to infer that $frame might have a next() method. It's very 
> weird and I think it's a negative when looking at the function signature as 
> it's a meaningless word unless you know some back story that I clearly 
> don't?
>
> I would love an explanation as it looks to me like an area of confusion 
> for people new to writing middleware.
>

I believe it has something to do with the concept of call stacks / stack 
frames? Reading a bit real fast on that I'm not 100% sure it fits entirely 
but I think that was the intention.

http://stackoverflow.com/questions/10057443/explain-the-concept-of-a-stack-frame-in-a-nutshell

"A call stack is composed of 1 or many several stack frames. Each stack 
frame corresponds to a call to a function or procedure which has not yet 
terminated with a return." 



-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/7d8e9648-958b-45fb-ba6b-a38c197fd43d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.