Re: [VOTE][CC] Expulsion Vote for eZ Systems

[Paul Dragoonis]

+1 from PPI Framework

On Tue, Oct 17, 2023 at 8:50 AM Alex Makarov  wrote:

> +1
>
> On Tue, Oct 17, 2023 at 10:49 AM Cees-Jan Kiewiet 
> wrote:
>
>> +1 sadly
>>
>> On Mon, 9 Oct 2023 at 17:43, Chris Tankersley 
>> wrote:
>>
>>> +1, unfortunately.
>>>
>>> Chris Tankersley
>>> http://ctankersley.com
>>>
>>>
>>> On Oct 5, 2023 at 10:37:39 AM, Vincent de Lau  wrote:
>>>
 This thread is to collect Core Committee votes on the eZ Systems
 Expulsion vote.

 The proposal is to expel eZ Systems as a Member Project.

 There have been various efforts to prevent this drastic measure,
 without any result. The final discussion thread with the background leading
 to this proposal can be found here:
 https://groups.google.com/g/php-fig/c/zYvUOTH-y3I

 Voting ends by 2023-10-19 17:00 UTC

 Voting options:  For (+1), Against (-1), or Abstain (+0)
 Quorum: 50%
 Majority: 50%
 https://www.php-fig.org/bylaws/voting-protocol/#expulsion-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/f1b409b7-0463-4b67-b840-99ab90011b61n%40googlegroups.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/CAL9n4XOifD2unfL61JEZCG4%3D1SeaX2jAc9k2aV-4i7xHGftmYQ%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> 
>> Website
>> 
>>  | Blog
>> 
>>  |
>> Github  | Linkedin
>>  | Twitter
>> 
>>
>> --
>> 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/CAPY1sU9KNTqMi8zYS_i4wgSiHhcq1zbvbc1%2BE0LPj-cnE7Xb-g%40mail.gmail.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/CA%2BFA5VWaeWjLKKCoUKPw0sBZUjOxS6CyKQ3-PA4Dhupt-6jAMQ%40mail.gmail.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/CAKxcST-XOu%3DiG9pMih%2B92gbre2QJdbsAeqiU3tNOxZ6LR5M9yQ%40mail.gmail.com.

Re: [VOTE][CC] Expulsion Vote for Stormpath PHP SDK

[Paul Dragoonis]

+1 from PPI Framework



On Tue, Oct 17, 2023 at 8:50 AM Alex Makarov  wrote:

> +1
>
> On Tue, Oct 17, 2023 at 10:48 AM Cees-Jan Kiewiet 
> wrote:
>
>> +1 sadly
>>
>> On Mon, 9 Oct 2023 at 17:43, Chris Tankersley 
>> wrote:
>>
>>> +1, unfortunately.
>>>
>>> Chris Tankersley
>>> http://ctankersley.com
>>>
>>>
>>> On Oct 5, 2023 at 10:38:37 AM, Vincent de Lau  wrote:
>>>
 This thread is to collect Core Committee votes on the Stormpath PHP SDK
 Expulsion vote.

 The proposal is to expel Stormpath PHP SDK as a Member Project.

 There have been various efforts to prevent this drastic measure,
 without any result. The final discussion thread with the background leading
 to this proposal can be found here:
 https://groups.google.com/g/php-fig/c/zYvUOTH-y3I

 Voting ends by 2023-10-19 17:00 UTC

 Voting options:  For (+1), Against (-1), or Abstain (+0)
 Quorum: 50%
 Majority: 50%
 https://www.php-fig.org/bylaws/voting-protocol/#expulsion-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/7d95e151-c1ab-42a1-a0bc-177f2b1f0438n%40googlegroups.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/CAL9n4XPQmQOcJpaF_hnYq3-bywzt0dKfvmt8VL0%3DQEp02G3-Ug%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> 
>> Website
>> 
>>  | Blog
>> 
>>  |
>> Github  | Linkedin
>>  | Twitter
>> 
>>
>> --
>> 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/CAPY1sU8iSqsEQFHgxMFPFHN90SnuQeFQ%3DyD-%3DegFaOSNTpr4zQ%40mail.gmail.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/CA%2BFA5VUzQbEa-5VdRh77-hhcf5RbAJnsvGv0ufqFdr1Zjt0FkQ%40mail.gmail.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/CAKxcST9G6AgyYuQ%2BXsSU4pxZn93bc2OEpJh-29PatmoMDaHGNw%40mail.gmail.com.

Re: PSR-7/PSR-15 Sessions

[Paul Dragoonis]

On Thu, 29 Sep 2022, 20:51 Amanda,  wrote:

> Hi Paul,
>
> Thanks for writing back.
>

Hi Amanda,

Good reply!

Which chat room has 6000 people ?

Maybe dont couple it to PSR-7 tho.

That means people have to use and adopt 2 standards to use 1. Keep it
independent.

We thought about this before, and we realised this wasnt the best idea.

Keep up the energy  looking forward to seeing the progress.

Many thanks,
Paul




> I actually presented this idea on the discord channel about a year ago
> first, and at the time people expressed interest, just this week people on
> discord channel it was brought up by somebody else.
>
> In a PHP chat channel of 6,000 members , I frequently come across the
> problem where people want or need to switch out the framework session
> library for one reason or another, e.g they want to start using swoole or
> they companies want to decouple their code from the frameworks that they
> are using, having a PSR for sessions, makes swapping out stuff every easy.
> Also in this day and age companies are using multiple frameworks for their
> projects, in most cases those projects work with sessions, and it would be
> nice if we did not have to learn all the different session libraries for
> each framework.
>
> Furthermore, in most PHP frameworks including symfony and even frameworks
> in other languages such as java (
> https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletRequest.html)
>  ,
> they all have a getSession method, as this is part of the request. So
> having a standard for sessions to complete the existing PSRs is another
> reason.
>
> Also what is the point of learning how to use a PSR request or response
> object then you pull a different session object from it each time, we all
> look for the session object there now.
>
> I actually had the idea when writing a integration testing suite for
> applications that use the PSRs, its gets messy when working with sessions
> because there is no standard way, there are standard requests, standard
> responses, standard request handling, but no standard for storing data
> between requests, and PHP sessions dont work nicely with  PSR 7 response
> objects, so by having a standard we dont need to worry about that anymore.
>
> Amanda.
>
> On Thu, 29 Sept 2022 at 20:11, Paul Dragoonis  wrote:
>
>> Hi Amanda,
>>
>> Ask yourself. What problem in the community are you solving?
>>
>> We don't want to make standards for the sake of it.
>>
>> Are people actively trying to write code in Symfony that doesn't wanna
>> use Symfony sessions?
>>
>> Figure out the demand first, validate it, present some info.
>>
>> I'm not a blocker here in this process, I'm just asking you to have a
>> think.
>>
>> When we started this group (fig) we were wanting to make standards for
>> all sorts of things, including sessions, but after we done the market
>> analysis we realised the masses were not really interested in adopting a
>> generic session standard.
>>
>> If the appetite has changed, then let's do it.
>>
>> Food for thought.
>>
>> Cheers,
>> Paul
>>
>> On Thu, 29 Sep 2022, 18:32 Larry Garfield, 
>> wrote:
>>
>>> On Thu, Sep 29, 2022, at 3:14 AM, Amanda wrote:
>>> > Thanks for your interest, I also agree that the PHP community needs
>>> > this very much.
>>> >
>>> > The code in my proposal is an example and proof that we can make
>>> > everything work together.
>>> >
>>> > The purpose of the working group is to come up with a solution
>>> together
>>> > that can be used by everybody.
>>> >
>>> > Once a working group has been formed (and we have a sponsor), a
>>> > detailed proposal will be written, then the working group would start
>>> > from a blank canvas
>>> > as it would be clearer then what will be covered and what won't in
>>> this
>>> > PSR.
>>> >
>>> > Does anybody know if we need a sponsor to form the working group, or
>>> do
>>> > we need to form the working group to get the sponsor, it is not clear.
>>> >
>>> > Ideally I was hoping for representatives from other frameworks to be
>>> > part of this working group, anybody here?
>>> >
>>> > Amanda
>>>
>>> The formal formation of a working group includes "here's the basic
>>> skeleton of a PSR and what it hopes to do, here's the members of the
>>> working group including a Sponsor, Core Committee please vote to charter
>>> us."
>&g

Re: PSR-7/PSR-15 Sessions

[Paul Dragoonis]

Hi Amanda,

Ask yourself. What problem in the community are you solving?

We don't want to make standards for the sake of it.

Are people actively trying to write code in Symfony that doesn't wanna use
Symfony sessions?

Figure out the demand first, validate it, present some info.

I'm not a blocker here in this process, I'm just asking you to have a
think.

When we started this group (fig) we were wanting to make standards for all
sorts of things, including sessions, but after we done the market analysis
we realised the masses were not really interested in adopting a generic
session standard.

If the appetite has changed, then let's do it.

Food for thought.

Cheers,
Paul

On Thu, 29 Sep 2022, 18:32 Larry Garfield,  wrote:

> On Thu, Sep 29, 2022, at 3:14 AM, Amanda wrote:
> > Thanks for your interest, I also agree that the PHP community needs
> > this very much.
> >
> > The code in my proposal is an example and proof that we can make
> > everything work together.
> >
> > The purpose of the working group is to come up with a solution together
> > that can be used by everybody.
> >
> > Once a working group has been formed (and we have a sponsor), a
> > detailed proposal will be written, then the working group would start
> > from a blank canvas
> > as it would be clearer then what will be covered and what won't in this
> > PSR.
> >
> > Does anybody know if we need a sponsor to form the working group, or do
> > we need to form the working group to get the sponsor, it is not clear.
> >
> > Ideally I was hoping for representatives from other frameworks to be
> > part of this working group, anybody here?
> >
> > Amanda
>
> The formal formation of a working group includes "here's the basic
> skeleton of a PSR and what it hopes to do, here's the members of the
> working group including a Sponsor, Core Committee please vote to charter
> us."
>
> So a Sponsor is needed prior to the Entrance Vote.
>
> --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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/7e8a2e90-efe7-4900-b7f6-d221fd7b2607%40app.fastmail.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/CAKxcST9B5Rp-tK_q4e7-45nhvO1qcyiBVQTqsjhsTTgJqjCVKw%40mail.gmail.com.

Re: [ENTRANCE] [VOTE] [CC] PER Coding Style

[Paul Dragoonis]

Fair play! Sounds like a solid initiative/idea.

On Sun, Jan 16, 2022 at 3:33 AM Chris Tankersley 
wrote:

> As the sponsor for this PER Working Group, I hereby call an entrance vote
> for the PER Coding Style.
>
> The purpose of this PER is to migrate PSR-12 to a living document under
> the new PHP Evolving Recommendations structure. This will allow the coding
> style recommendations to more quickly integrate new syntax features
> provided by the language.
>
> The PER will be worked on here:
> https://github.com/php-fig/per-coding-style
>
> This is a Core Committee vote only.
>
> Editor: Alexander Makarov
> Sponsor: Chris Tankersley
> Working Group:
> - Ken Guest
> - Larry Garfield
> - Korvin Szanto
> - Woody Gilk
>
> We have a few others interested that may join the WG later.
>
> --
> 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/CAL9n4XMhazaQfZxfpuTrSM%3Dy2XcmE5kFD9nXZkgqK9_EuLF3sA%40mail.gmail.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/CAKxcST_4Aye-C4CHBOXtk2pmmR9EJN6Rx%2B-Ux7L7hECLfPEdFQ%40mail.gmail.com.

Re: [VOTE] Core Committee Election January 2022

[Paul Dragoonis]

Voting as the PPI Representative

1. Korvin Szanto
2. Chris Tankersley
3. Ken Guest
4. Enrico Zimuel
5. Florian Engelhardt
6. Navarr Barnier

On Tue, Jan 18, 2022 at 6:02 PM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> Voting as the Laminas representative:
>
> 1. Enrico Zimuel
> 2. Ken Guest
> 3. Chris Tankersley
> 4. Korvin Szanto
> 5. Florian Engelhardt
> 6. Navarr Barnier
>
>
> On Sat, Jan 15, 2022 at 10:51 AM Vincent de Lau  wrote:
>
>> Hello everyone,
>>
>> Yesterday the nomination period ended, and we got 7 nominations in
>> total, which is great!
>> For the secretary seat, we have one uncontested nomination. For the Core
>> Committee, we have 6 nominations against 4 available seats, so this means
>> that we will be holding a proper election, starting now! The nominees are
>> (in temporal order of nomination):
>>
>>- Korvin Szanto - https://groups.google.com/g/php-fig/c/Rv43KRFOt_A
>>- Navarr Barnier - https://groups.google.com/g/php-fig/c/kAOTuIFB7Eg
>>- Chris Tankersley - https://groups.google.com/g/php-fig/c/xtrwd7o6SOQ
>>- Ken Guest - https://groups.google.com/g/php-fig/c/QtKqPOYZ2HA
>>- Florian Engelhardt -
>>https://groups.google.com/g/php-fig/c/wjxZf1VMzDA
>>- Enrico Zimuel - https://groups.google.com/g/php-fig/c/vA-dFT8lXbM
>>
>> You can find information about the nominees inside the linked nomination
>> thread. 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, the vote for CC members is open
>> to Project Representatives and individuals from the community. To be
>> eligible to vote as an individual, the bylaw established the following
>> threshold:: *"Any individual that has posted a non-trivial message in
>> the official 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."* We will obviously
>> consider Discord in this account; feel free to reach to me or any other
>> secretary to check on the matter. *When can you vote?* Voting will be
>> open in this thread until January 29th 17:00 UTC.
>> *How to vote*
>> Votes are cast by replying in this thread on the list. For individuals
>> that have not used the mailing list before, please be sure to identify
>> yourself, for instance by including your Discord or Github handle.
>> 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 all 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, secretaries will be announcing the results, and
>> all the newly elected (both CC members and secretary). Thanks, and happy
>> voting! Alessandro Lai and Vincent de Lau 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/22dd11d5-8d4a-46d7-ab77-e291b4e03f49n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> he/him
>
> --
> 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/CAJp_myWkHHrRKyeKD0U%3DGgTCdg7%3D4%3Dp%2BMyJjg2%3DVzOBPup8Yvg%40mail.gmail.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 

Re: FIG-hosted enumerations

[Paul Dragoonis]

On Sat, May 22, 2021 at 1:51 AM Larry Garfield 
wrote:

> Greetings, FIGlets.  (What does one call a FIG-involved person, anyway?
> FIGlet?  FIGment?)
>

We're definitely FIGlet's ;-) Spiderfig, spiderdig, codes whatever a
spiderfig codes.


>
> As you may be aware, PHP 8.1 is going to include support for
> Enumerations.
>
> https://wiki.php.net/rfc/enumerations
>
> I believe it would be beneficial for some common industrial enumerated
> types to have a common library, rather than everyone making their own.  The
> first examples that jump out at me are HTTP status codes and methods, which
> I have implemented here:
>
> https://github.com/Crell/EnumTools
>
> There are likely others, but I haven't come up with them yet.  (Obviously
> this code won't run on any released PHP version yet, but I'm pretty sure
> the syntax is right...)
>
> I am fine hosting these myself, but it occurs to me that they may be of
> more value if hosted by a more prominent organization, such as FIG.  Of
> course, it's not really a spec; a PSR for these wouldn't make any sense.
> It's more akin to the Util libraries that we maintain for various PSRs, but
> without an associated PSR.
>
> How do folks feel about FIG hosting such an enum collection?  We could
> make it one package or several, depending on how we decide to break it up.
> If FIG is OK hosting it I am happy to dump the enums I already build into
> whatever package FIG wants to use for them.
>

I think we need to gracefully add Enum's into our existing packages (HTTP,
Cache ..etc) and then also see how PHP8.x enum's are being used in the wild.

Over time we'll be able to spot the patterns and then begin reacting
accordingly.

I think we'd be jumping the gun if we tried to go this now. Let's see how
the dust settles in the PHP community, and then we make our move.

I think a generic enum package is fine, but to be honest having it
contextualized inside a particular package (a bounded context) is a
stronger move.


>
> Discuss.
>
> --
>   Larry Garfield
>   la...@garfieldtech.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/9fa79e25-5755-4f3f-9be9-3acc2ee67c6a%40www.fastmail.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/CAKxcST-pSKoEnsA8YfQa6ciGnfgOq7iEVzNvpJasT4kyq4Wevg%40mail.gmail.com.

Re: [IDEA] Transition IRC to Slack/Gitter/Discord

[Paul Dragoonis]

On Wed, 16 Dec 2020, 16:41 Andreas Heigl,  wrote:

> Am 16.12.20 um 17:38 schrieb Ben Ramsey:
> > My $0.02 as one who lurks on the mailing lists:
> >
> > Chat programs, whether it be Slack or Discord or Rocket.Chat or
> > Mattermost or whatever, are inherently bad at transparency, which is
> > paramount to open source. They’re difficult to search, do not provide an
> > easy means to browse through the history, and they almost always require
> > an account to access the history. Mailing lists, on the other hand,
> > provide search, archival browsing, and all discussions can be made
> public.
> >
> > I think chat is great for ad hoc discussions and meetings, but when it’s
> > time to make any decisions, everything (including ideas discussed in
> > chat) needs to move to a medium that can support transparency and
> > openness. Right now, that’s mailing lists.
>
> I second that!
>


Thirded.


> And IIRC this has been a discussion on this list several times and so
> far the result was always to stay with the mailinglist format!
>
> Cheers
>
> Andreas
> --
>   ,,,
>  (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> | https://andreas.heigl.org   |
> +-+
> | https://hei.gl/appointmentwithandreas   |
> +-+
>
> --
> 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/c6409fd9-2ae6-6d0d-b251-9213b4e8c162%40heigl.org
> .
>

-- 
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/CAKxcST__iTh2pQmisDxt_Jpnd07cMCe%3DSD1yL0GLQWErpQDAHg%40mail.gmail.com.

Re: laravel new-feature!!

[Paul Dragoonis]

Saeed, this question is out of scope.

Your question/conversation is better suited for reddit.
https://www.reddit.com/r/PHP/


On Tue, 4 Feb 2020, 11:46 saeed jahanakbari, 
wrote:

> We know that composer adds file dependencies and we can also save our
> custom dependencies to composer.json file.
> Now we have a tool that looks like a composer but we can add any template
> bootstraps we want to the project.
>
> We know templates are made up of some css, js, and so on and Laurel uses
> blades.
>
> The tool I'm talking about picks up the template and does the following:
>
> 1. It stores all files of different types (css, js, ...) separately in
> resources And creates the transfer path in the webpack.mix.js file.
>
> 2. I recall that templates were created from different pages and Laraval
> used blades. This means that the tool speaks to the Shatter pages and then
> moves them to the view folder
>
> 3. It also creates routes based on the filenames that have been converted
> to blades in web.php.
> How effective do you think this tool is?
>
> --
> 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/336d58bc-467b-4b06-8547-07572ae8d548%40googlegroups.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/CAKxcST8h9o-L0zn_f6Epk66Gdg%2Bc4Y41uPXFo7PSba_EmC5W5Q%40mail.gmail.com.

Re: [VOTE] Core Committee Election

[Paul Dragoonis]

1. Chris Tankersley
2. Korvin Szanto
3. Enrico Zimuel
4. Ben Edmunds
5. Massimiliano Arione

On Fri, 10 Jan 2020, 13:43 Woody Gilk,  wrote:

> 1. Chris Tankersley
> 2. Korvin Szanto
> 3. Ben Edmunds
> 4. Enrico Zimuel
> 5. Massimiliano Arione
> --
> Woody Gilk
> https://www.shadowhand.com
>
>
> On Fri, Jan 10, 2020 at 7:31 AM Alex Makarov  wrote:
>
>> 1. Korvin Szanto
>> 2. Enrico Zimuel
>> 3. Chris Tankersley
>> 4. Massimiliano Arione
>> 5. Ben Edmunds
>>
>> On Fri, Jan 10, 2020 at 3:50 PM Michael Cullum 
>> wrote:
>> >
>> > 1. Korvin Szanto
>> > 2. Chris Tankersley
>> > 3. Enrico Zimuel
>> > 4. Ben Edmunds
>> > 5. Massimiliano Arione
>> >
>> > Thanks,
>> > Michael
>> >
>> > On Fri, 10 Jan 2020, 8:42 am Alessandro Lai, <
>> alessandro.la...@gmail.com> 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/c9f56a7f-adf7-4b31-b5a9-65635560d104%40googlegroups.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/CAAqcDMgDEg3pWNOzu4cMgWGg_n3PeDxdubiPyrta8S6ea_KUTw%40mail.gmail.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
>> 

Re: PSR-11 and the next steps - Service Provider Interop

[Paul Dragoonis]

As per last year, I'm still keen to continue to contribute to this.

I have already implemented and solved this situation for the laravel
project.

I gave my client container interop and interoperable service providers and
respective config, and brought this to laravel projects

This was to share code between symfony, laravel and a bespoke product, and
it increased performance massively too since laravel was quite slow in its
lookups until my impl.

I also solved this issue with the PPI Framework project in the past, and
the objective of that project was to solve these things in advance, and
give them to real world clients,  prior to it popping up in FIG and the
wider community.

As such I have the experience and drive to work on this and see it through
to release.

If you'd like me involved then let me know. In turn I will show up at the
next get together we have (online) to talk about technical details,
implementation and next steps.

Just send me the invite.

Many thanks,
Paul






On Wed, 8 Jan 2020, 19:37 Benjamin Mack,  wrote:

> Hi list,
>
> since we (TYPO3 CMS) are continuing our path in modernizing our PHP stack,
> we've been looking for ways to standardize our container implementation.
> While it's good to have PSR-11 for Service Containers - and we utilize this
> with our latest version - we had some discussions around the actual service
> providers (factories, extensions), and my _guess_ is that it was a too much
> to put into PSR-11 and to tackle container PSR first, and then "at some
> point" see if service provider PSR would be feasible.
>
> We found the service-provider package (air quotes EXPERIMENTAL,
> https://github.com/container-interop/service-provider/) to be extremely
> cool, but were reluctant to depend on the package, but would really love to
> see such a (IMHO common) need to be provided as a PHP Standards
> Recommendation.
>
> So, my question is: Is there an interest (either by the original PSR-11
> gang, CC or by somebody else in this list) to invest this topic further? Or
> did I just miss some communication that this isn't something that is
> feasible in moving forward?
>
> Thanks in advance for any hints and clarification!
>
> Benni Mack,
> TYPO3 Project Lead
> https://typo3.org - inspire people to share.
>
> --
> 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/F9B5D08F-3134-420F-9128-12245F919C2D%40gmail.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/CAKxcST9tYH1sRQ5QPz2NWMY%3Dp-SYcWP3mcMwoAA26hCswtRU-g%40mail.gmail.com.

Re: PSR-6 reserved characters constant

[Paul Dragoonis]

Hey Gabriel,

Thanks for showing an interest in PSR-6, and for making PRs in the first
place! All community feedback is welcomed.

I noticed Larry commented on github already.

Although we don't like to change a spec once published, for adding new
features, this is actually a good addition which doesn't introduce anything
new.

The reserved characters are in the written spec but we forgot to add it
into the interfaces. Such things are easily missed.

It would be valuable to add this in, and it has my support.

What's the group's latest procedure for making updates to specs; an errata
or something?

Many thanks,
Paul





On Mon, May 21, 2018 at 11:23 PM, Gabriel O  wrote:

> So I created this PR https://github.com/php-fig/cache/pull/16 but it
> found very little publicity.
>
> Issue which followed https://github.com/php-fig/cache-util/issues/15 got
> no publicity.
>
> As I still think this is good idea to do with no BC break risk, I would
> like to try reach more people which are involved with PSR-6 via this
> mailing list.
>
> --
> 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/451cafce-2ad3-4aad-9a54-de7f7a01c034%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST_CZJnW9pwt8r6wYraMMA8LooDZagdSfGdESjMMbBsvrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New representative for Magento

[Paul Dragoonis]

Welcome Anton

On Tue, 15 May 2018, 18:04 Ben Marks,  wrote:

> Hi all,
>
> Effective immediately the representative for Magento will be Anton Kril (
> anton.k...@gmail.com), who is Magento's Director of Architecture. His
> knowledge and experience make him a much better fit for the
> responsibilities.
>
> Cheers,
> Ben Marks
> Evangelist @ Magento
>
> --
> 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/67649613-8dfa-415c-b35e-343d8482a081%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST96tCC8%2BaSPy5qOHSqjU%2BAuWYmna31UbdpdauQbTw3vJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-16 question

[Paul Dragoonis]

Hi Alice,

It's recommended not to throw \Exception but throw your own cache exception
class, which implement's PSR-16's CacheException.

"""
use Psr\SimpleCache\CacheException;
class MyProjectsCacheException extends Exception implements CacheException
"""

This way you'll be able to continue to catch(Exception $e) in general, but
also be specific and typehint on CacheException if you need to.

I hope that answers your question.

Many thanks,
Paul


On Sat, Feb 24, 2018 at 8:02 PM, Chuck Burgess  wrote:

> Purpose of the interfaces is to make those exact exception types
> *catchable*... that's all.
>
> On Feb 24, 2018 13:56, "Alice Wonder"  wrote:
>
>> I have a personal cache class that would be cake to port to use PSR-16,
>> but PSR-16 also defines two exception interfaces.
>>
>> Is it really necessary I extend those two interfaces rather than extend a
>> different exception interface?
>>
>> zetacomponents base package has an abstract exceptions class I sometimes
>> extend.
>>
>> If I have to implement the interface in PSR-16 to be compliant than to
>> use that abstract class I would have to change that abstract class to
>> implement the PSR-16 exception interfaces instead of just \Exception and it
>> strikes me that that is just, well, absurd since the PSR-16 interfaces
>> don't do anything or even extend \Exception.
>>
>> Am I not understanding the purpose of those interfaces?
>>
>> --
>> 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/ms
>> gid/php-fig/85594732-4a0a-4058-a263-a48db4738e70%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CANsgjns%3DWYjjQ43OC0RMkgLSRBUAmrjKGcaP
> bhU8cyVsgf3HpA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST9fLRvD89KCosbX8Q1YW0f-EVMLgXM36gz9ymOot7%2BxQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-16 / NullCache / CacheAwareInterface / CacheAwareTrait

[Paul Dragoonis]

I will talk to Jordi about it and get back to you. Cheers

On 9 Nov 2017 19:46, "Pol Dellaiera"  wrote:

> In the meantime, I've created a PR for php-fig/cache-util: https://
> github.com/php-fig/cache-util/pull/13
>
> Let's see if we can add it to that repo or create a new repo for it.
>
> On Thursday, November 9, 2017 at 8:28:59 PM UTC+1, Pol Dellaiera wrote:
>>
>> Hi all,
>>
>> Today I submitted my first PR against psr/simple-cache
>> : https://gith
>> ub.com/php-fig/simple-cache/pull/10
>>
>> I went on IRC to get some feedback about it and Crell told me something I
>> didn't know yet, that those PSR packages are almost "immutable" and only
>> very simple trivial changes were allowed.
>>
>> So, if I want to add a NullCache object a CacheAwareTrait trait and a
>> CacheAwareInterface, it should be done in a fig/*-util repository
>> .
>>
>> The question that I would like to submit in you is the following, if I
>> would like to add a NullCache object, a CacheAwareTrait trait and a
>> CacheAwareInterface, should it be done in php-fig/cache-util
>>  or a new repository
>> php-fig/simple-cache-util repo ?
>>
>> Let me know what you think.
>>
>> Thanks in advance.
>>
> --
> 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/803e84c2-d26e-40b2-bcc8-5d9baba814c2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST_x0fqLte%3D88os%2B8n2ih%2BmQb-KR1WbuaFsDstyUs0C4Kg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] Secretary Election

[Paul Dragoonis]

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

On Mon, Oct 23, 2017 at 10:16 PM, Joe Ferguson  wrote:

> 1. Margret Staples
> 2. Mark Railton
> 3. Alessandro Lai
>
> Good Luck and Godspeed Secretaries :D
>
> - Phergie
>
> On Mon, Oct 23, 2017 at 4:06 PM, GeeH  wrote:
>
>> 1. Margret Staples
>> 2. Mark Railton
>> 3. Alessandro Lai
>>
>>
>> G
>>
>> --
>> 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/ms
>> gid/php-fig/4be2bf62-dbce-4f1c-a5a1-28fc1cf927ba%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> - Joe Ferguson
> JoeFerguson.me
> MemphisPHP.org
>
> --
> 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/CABj1BaYyYue1%3DGu20HfK999gD-cKszrA_7QJSBnt-
> -R8c2VHvQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST_2kkTCK0J5BKjUTNWUbhyAk%2B7eAz2vRFrG1DZCC%3DuMzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Paul Dragoonis]

On 20 Oct 2017 4:38 pm, "Sara Golemon"  wrote:

On Thursday, October 19, 2017 at 2:39:36 PM UTC-4, 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.
>
>
+1


+1

-- 
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/48229367-d63e-4fcf-9ec8-728d6991dcd5%40googlegroups.com

.

For more options, visit https://groups.google.com/d/optout.

-- 
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/CAKxcST8Kc%3DY5DBZrBn%2BbDsg7nhR5oG95OyHdPQSGW6q%2B%3DHyimw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Service providers PSR: seeking members for a working group

[Paul Dragoonis]

I already worked a lot on these problems with PPI. If you want me to join
the WG then i will help out

On 28 Mar 2017 11:01 am, "David Négrier"  wrote:

> Hey list!
>
>
> PSR-11 has been accepted so we have standardized how to fetch entries from
> containers.
>
> The next logical step is to find a common way to put things into a
> container. More generally, the goal we are seeking is to make it possible
> for a package author to provide/modify entries in any container (rather
> than having to write a module/bundle for each framework as it's the case
> today as I described in this talk: https://thecodingmachine.
> github.io/forumphp2016talk/index_en.html#60).
>
>
> Let's be clear that the goal is NOT to define a single way of configuring
> a container. Each container has its own strategy (configuration files,
> autowiring, PHP code...) that makes it worthwhile. What we are trying here
> is to find an additional *shared* way of putting things into a container
> specifically for package authors. Because it's almost impossible for
> package authors to write a bridge for every framework out there).
>
>
>
> Also, since FIG 3.0 has passed, it's time that we officially create a
> working group.
>
>
> As a reminder, we (the container-interop participants) explored several
> strategies:
>
>
> - unified file format
>
> - common interfaces for container definitions
>
> - common interfaces for dumping PHP code representing container definitions
>
> - service providers
>
>
> I have summarized this in those 2 blog posts:
> https://www.thecodingmachine.com/psr-11-an-overview-of-
> interoperable-php-modules/ and https://www.thecodingmachine.
> com/psr-11-get-ready-for-universal-service-providers/ .
>
>
> The conclusion we reached was that standardized service providers are the
> way to go. Among many criteria, they are easy to write, and if done right,
> can be properly optimized by compiled containers.
>
>
> We started working on it at https://github.com/container-
> interop/service-provider/
>
>
> Work is well advanced: we have prototype integrations available with the
> major frameworks out there.
>
>
> There is still a lot of work to be done:
>
>
> - Recently, Rasmus Schultz came up with an alternative proposal. The idea
> is that rather than trying to provide factories to the containers (what
> service providers do), a module could provide its own container and publish
> to the "main container" the list of entries it contains. Rasmus detailed
> the idea here: https://github.com/container-interop/service-provider/
> issues/40 . This idea looks a bit like the "delegate lookup feature" that
> was removed from PSR-11 in the philosophy (several containers running
> side-by-side), but is different in the implementation. I'd be interested to
> gather feedback from the community on Rasmus' proposal (I suspect it might
> be complementary to container-interop/service-provider rather than
> opposite)
>
> - With the current proposal, we can already add services and extend
> existing services. We need to know if we want to be able to do more (like
> adding/extending services conditionally based on the container's
> configuration). More generally, we need to discuss the exact scope of the
> PSR (limited to simple use cases? extended?)
>
> - Finally, there will be a huge amount of work waiting for us in the
> nitty-gritty (exceptions handling, etc...)
>
>
> I'm hereby calling *interested members to step up* to create a working
> group, and for member projects to give as much feedback as possible. PSR-11
> has made a big leap forward in the very last days because "big players"
> joined the party a bit late :). For this PSR, it would be great to have
> some feedback from you guys early on in the process.
>
>
> ++
>
> David.
>
> Twitter: @david_negrier
>
> Github: @moufmouf
>
> --
> 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/1573992a-355d-42a8-bd1f-c53ebaa43fd1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST-1yWFrZHus-k8H9rcEbAZHL42S%2Bhn7xug4v465HyC-bQ%40mail.gmail.com.
For more options, visit 

Re: Service providers PSR: seeking members for a working group

[Paul Dragoonis]

I already worked a lot on these problems with PPI. If you want me to join
the WG then i will help out.

On 28 Mar 2017 11:01 am, "David Négrier"  wrote:

> Hey list!
>
>
> PSR-11 has been accepted so we have standardized how to fetch entries from
> containers.
>
> The next logical step is to find a common way to put things into a
> container. More generally, the goal we are seeking is to make it possible
> for a package author to provide/modify entries in any container (rather
> than having to write a module/bundle for each framework as it's the case
> today as I described in this talk: https://thecodingmachine.
> github.io/forumphp2016talk/index_en.html#60).
>
>
> Let's be clear that the goal is NOT to define a single way of configuring
> a container. Each container has its own strategy (configuration files,
> autowiring, PHP code...) that makes it worthwhile. What we are trying here
> is to find an additional *shared* way of putting things into a container
> specifically for package authors. Because it's almost impossible for
> package authors to write a bridge for every framework out there).
>
>
>
> Also, since FIG 3.0 has passed, it's time that we officially create a
> working group.
>
>
> As a reminder, we (the container-interop participants) explored several
> strategies:
>
>
> - unified file format
>
> - common interfaces for container definitions
>
> - common interfaces for dumping PHP code representing container definitions
>
> - service providers
>
>
> I have summarized this in those 2 blog posts:
> https://www.thecodingmachine.com/psr-11-an-overview-of-
> interoperable-php-modules/ and https://www.thecodingmachine.
> com/psr-11-get-ready-for-universal-service-providers/ .
>
>
> The conclusion we reached was that standardized service providers are the
> way to go. Among many criteria, they are easy to write, and if done right,
> can be properly optimized by compiled containers.
>
>
> We started working on it at https://github.com/container-
> interop/service-provider/
>
>
> Work is well advanced: we have prototype integrations available with the
> major frameworks out there.
>
>
> There is still a lot of work to be done:
>
>
> - Recently, Rasmus Schultz came up with an alternative proposal. The idea
> is that rather than trying to provide factories to the containers (what
> service providers do), a module could provide its own container and publish
> to the "main container" the list of entries it contains. Rasmus detailed
> the idea here: https://github.com/container-interop/service-provider/
> issues/40 . This idea looks a bit like the "delegate lookup feature" that
> was removed from PSR-11 in the philosophy (several containers running
> side-by-side), but is different in the implementation. I'd be interested to
> gather feedback from the community on Rasmus' proposal (I suspect it might
> be complementary to container-interop/service-provider rather than
> opposite)
>
> - With the current proposal, we can already add services and extend
> existing services. We need to know if we want to be able to do more (like
> adding/extending services conditionally based on the container's
> configuration). More generally, we need to discuss the exact scope of the
> PSR (limited to simple use cases? extended?)
>
> - Finally, there will be a huge amount of work waiting for us in the
> nitty-gritty (exceptions handling, etc...)
>
>
> I'm hereby calling *interested members to step up* to create a working
> group, and for member projects to give as much feedback as possible. PSR-11
> has made a big leap forward in the very last days because "big players"
> joined the party a bit late :). For this PSR, it would be great to have
> some feedback from you guys early on in the process.
>
>
> ++
>
> David.
>
> Twitter: @david_negrier
>
> Github: @moufmouf
>
> --
> 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/1573992a-355d-42a8-bd1f-c53ebaa43fd1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST97zFumVeNAiPs5kgDrDJ7Uc3F8Q_wf-qTQ%2B2%3D8ndQuPg%40mail.gmail.com.
For more options, 

Re: Final underscore in class names

[Paul Dragoonis]

Hi Marco,

On Fri, Mar 10, 2017 at 9:25 AM, Marco Perone <pasaf...@gmail.com> wrote:

> Hi Paul, thanks for your answer,
>
> I know that the final underscore is not passing the PSR-1 codesniffer
> test. That's where I started from (https://github.com/squizlabs/
> PHP_CodeSniffer/issues/1382). I was more wondering if that is the correct
> approach.
>

The correct approach is to stick to StudlyCaps for class name. If it
deviates from that then it's considered "not compliant".


>
> I agree it should be generally avoided to name classes after language
> constructs, but there are cases (see the PHP parser library I linked) where
> that seems exactly the most reasonable thing to do, and I am asking how
> these cases should be handled.
>

Indeed projects like this aimed to emulate the tokens of the language will
find themselves falling outside of PSR-1. There's nothing wrong with that
really.

A personal suggestion, so you're sticking to StudlyCaps, is you could do
something like TokenEcho TokenEmpty for class names, if PSR-1 is important
to you.


>
> 2017-03-10 9:49 GMT+01:00 Paul Dragoonis <dragoo...@gmail.com>:
>
>> Hi Marco,
>>
>> Comments inline.
>>
>> On Thu, Mar 9, 2017 at 10:40 PM, Marco Perone <pasaf...@gmail.com> wrote:
>>
>>> As per PSR-1 specifications, class names must be in StudlyCaps.
>>>
>>>
>>> However, if I want to define a class named Echo (or any other Php
>>> keyword), I am not able to do that beacuse if I do so I obtain a parse
>>> error.
>>>
>>>
>>> It seems that the standard solution to this issue is to add an _ at the
>>> end of the class, as in Echo_.
>>>
>>
>> No, this is not the standard solution.
>>
>>
>>> For example, look in https://github.com/nikic/PH
>>> P-Parser/tree/3.x/lib/PhpParser/Node/Stmt.
>>>
>>
>> This would not pass PSR-1 codesniffer tests.
>>
>>>
>>> Should this be counted as a violation of PSR-1?
>>>
>>> Could it be the case to state this explicitely in PSR-12, allowing the
>>> presence of a final underscore in a class name, maybe only when the class
>>> name in a reserved keyword?
>>>
>>>
>>> Where possible you should avoid naming your classes after language
>> constructs and tokens.
>>
>>
>>> More broadly, could it be the case to provice a precise definition of
>>> what StudlyCaps mean? (If it's not present elsewhere and I'm missing 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/ms
>>> gid/php-fig/e07dbe3c-2488-4630-8850-bdb04ccae52b%40googlegroups.com
>>> <https://groups.google.com/d/msgid/php-fig/e07dbe3c-2488-4630-8850-bdb04ccae52b%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "PHP Framework Interoperability Group" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/php-fig/0yEk60y2RVE/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/ms
>> gid/php-fig/CAKxcST_xhaRhpnn8jV8jVDRQXMO4c98%2BN3HsV3d3mJ-
>> Zyri%2BhQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/php-fig/CAKxcST_xhaRhpnn8jV8jVDRQXMO4c98%2BN3HsV3d3mJ-Zyri%2BhQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Marco Perone
>
> @marcoshuttle <https://twitter.com/marcoshuttle>
> https://github.com/marcosh
> http://marcosh.github.io/
>
> --
> 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@goog

Re: Final underscore in class names

[Paul Dragoonis]

Hi Marco,

Comments inline.

On Thu, Mar 9, 2017 at 10:40 PM, Marco Perone  wrote:

> As per PSR-1 specifications, class names must be in StudlyCaps.
>
>
> However, if I want to define a class named Echo (or any other Php
> keyword), I am not able to do that beacuse if I do so I obtain a parse
> error.
>
>
> It seems that the standard solution to this issue is to add an _ at the
> end of the class, as in Echo_.
>

No, this is not the standard solution.


> For example, look in https://github.com/nikic/PHP-Parser/tree/3.x/lib/
> PhpParser/Node/Stmt.
>

This would not pass PSR-1 codesniffer tests.

>
> Should this be counted as a violation of PSR-1?
>
> Could it be the case to state this explicitely in PSR-12, allowing the
> presence of a final underscore in a class name, maybe only when the class
> name in a reserved keyword?
>
>
> Where possible you should avoid naming your classes after language
constructs and tokens.


> More broadly, could it be the case to provice a precise definition of what
> StudlyCaps mean? (If it's not present elsewhere and I'm missing 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/e07dbe3c-2488-4630-8850-bdb04ccae52b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST_xhaRhpnn8jV8jVDRQXMO4c98%2BN3HsV3d3mJ-Zyri%2BhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Paul Dragoonis]

+1 from PPI

On Fri, Feb 10, 2017 at 5:29 AM, Shefik  wrote:

> + 1 from Zikula
>
> - Shefik
>
> On Feb 8, 2017, at 9:01 AM, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
> +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%2F
>> bz9sr8q8yHI#!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/421e02c1-fc37-486a-8ff8-c8bc202bd75b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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/E803DD8D-2B95-43C7-970B-9E38FF6C02E5%40gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST-YHd0sQAwFDcy0R_%3DWQL530_5ghDKU0XORjtGrMMfy7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][Accept] PSR-11 ContainerInterface

[Paul Dragoonis]

+1 from PPI

On 2 Feb 2017 4:05 pm, "André R."  wrote:

> +1 from eZ
>
> Best,
> André R.
>
> --
> 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/042513a9-a9ac-4d52-999e-1542926b0d38%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST9OiDTK23czDmeqCb0WyKpZPhfMBF8YdS-%3Do7Qaqzh%2BPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Seeking Explanations of PRS-2 Standards

[Paul Dragoonis]

Used most used (the commonalities) between the frameworks and major
libraries at the time.

Cognitive load for switching between these frameworks and providing a level
of consistency between them.

Phpstorm has an auto formatter to format your code for you, so even if its
not natural to you it will format it for you. Phpcsfixer does the same.



On 24 Jan 2017 03:18, "Spencer Hill"  wrote:

Thanks for the reply Christopher! So, are you saying that basically what
this survey revealed as used most often is what was adopted as the
standard? Or was this just showing what was common and then discussion
about reasoning for those practices went from there? Thanks for your time!

On Mon, Jan 23, 2017 at 6:18 PM Christopher Pitt  wrote:

> Hey Spencer,
>
> To answer these why's, the team behind PSR-2 did a survey of commonalities
> amongst PHP frameworks: http://www.php-fig.org/psr/psr-2/#appendix-a-
> survey
>
> Kind regards
> Chris
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/php-fig/y4ZKrsHMWXY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/47b838f4-b96a-4938-bfb7-2bf603770248%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
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/CAM7kXxcHqywt8t-zNmn%3DzgavwsMDEPz4NXsXVn828iP6iC17
qg%40mail.gmail.com

.

For more options, visit https://groups.google.com/d/optout.

-- 
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/CAKxcST9thGqdnfPkYKqpe4ctrAb37uTR4RifXrOHmdmY7ASDvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][Accept] PSR-16: Simple Cache

[Paul Dragoonis]

On Mon, Jan 2, 2017 at 1:44 PM, Jordi Boggiano  wrote:

> Happy new year everyone!
>
> The vote ended yesterday, and passed! Thanks all for taking the time to
> review.
>

What Jordi said :-)

Upon putting together the initial version of PSR-16, I set up some Docker
environments against real backends with implementations & tests for Redis.
I will see how I can apply these into a simplecache-utils library so that
other may benefit from it too. I'm wanting it to be more of a "checker" for
your implementation, so basically you inject your PSR-16 compliant class
into it, and it will call the public interface methods on it to check it's
behaving as it should.


>
> Here are the stats:
>
> Number of Non-Voters 10
> Positive Votes   24
> Negative Votes   3
> Abstain Votes0
> Voters   27
> Total Number of Members  37
> Quorum Number13
> Quorum Met   Yes
> Percentage Voted 73%
>
> List of voters:
>
> +1
>
> Composer
> PPI
> Contao
> ReactPHP
> Symfony
> Jackalope
> Neos
> phpBB
> Yii
> PHPixie
> Sculpin
> Phing
> Pyro
> PEAR
> Revive Adserver
> Slim
> Icicle
> Joomla
> SilverStripe
> Zikula
> Wikibase
> Magento
> Concrete5
> eZ
> PrestaShop (late vote, not counted above, just for reference)
>
> -1
>
> IBMiToolkit
> Lithium
> Zend Framework
>
> Cheers
>
> --
> Jordi Boggiano
> @seldaek - http://seld.be
>
> --
> 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/ms
> gid/php-fig/09d81b5d-a031-dcbe-1919-d6eac2819f29%40seld.be.
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST8r%3DqHd1CJGCwCJpsAPtTM6rj5i8sYiOKo9ocBG2a0DaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][Accept] PSR-16: Simple Cache

[Paul Dragoonis]

Hey,

+1 for PPI Framework Engine

Can the rest of the group please get behind this, and vote?

Many thanks,
Paul

On Sun, Dec 18, 2016 at 3:26 PM, Jordi Boggiano  wrote:

> Before I forget, +1 for Composer :)
>
> --
> Jordi Boggiano
> @seldaek - http://seld.be
>
> --
> 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/ms
> gid/php-fig/46de4887-0c6d-6c91-970c-948f6bcd2478%40seld.be.
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST_RvQEFM%3D7TLhSr-%2BqWqUwVMe-DUSuPaJippvxNCNxGgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Paul Dragoonis]

Hi Guys,

I'm busy with my 3 children over the weekend so I'll be back on on wagon on
Monday.

To clarify: what I've been working on is a HTTP Router specification, that
uses HTTP Messages standard, and the PSR Middleware standard.

Speak on Monday.

Many thanks,
Paul


On Sat, Nov 19, 2016 at 6:12 PM, Woody Gilk <woody.g...@gmail.com> wrote:

> Larry,
>
> I think this may be a difference, or lack of clarity, with language. My
> interpretation is that this would be an HTTP Router proposal that would use
> HTTP Messages. My feeling is that this area is definitely open to
> standardization, as there are many "routing" packages that effectively do
> the same thing.
>
> That said, I am not necessarily convinced that a callable is the correct
> target. My only concern with allowing a "mixed" type is that it cannot be
> strongly typed at the interface level.
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
> On Sat, Nov 19, 2016 at 11:49 AM, Larry Garfield <la...@garfieldtech.com>
> wrote:
>
>> Background: My primary experience with routing systems is the conversion
>> of the Drupal 7 menu/routing system to the Drupal 8 Symfony-based routing
>> system, and realizing the issues with the way most systems seem to do
>> routing today. :-)
>>
>> I am quite skeptical about a routing PSR at this point.  Routing could be
>> based on a wide variety of inputs, not just the URL.  Not even just the
>> request, although conceptually the non-request data (likely derived from
>> it, but also including DB calls) could be added to the attributes array for
>> later access.  Even then, producing "a callable" may also be limiting, as
>> I've been questioning some of the decision we made in Drupal to allow
>> arbitrary callables as a route handler (controller).
>>
>> At this point I remain unconvinced that a Routing PSR would be viable
>> unless it was super-trivial.  Even a Route definition object would be hard
>> to standardize; Drupal has a lot more there than Symfony does, and we're
>> based on the same underlying libraries.
>>
>> I've not looked at what Expressive is doing or what Paul is proposing,
>> but at this point it doesn't feel like an area with enough "natural
>> standardization" for a PSR to be viable.
>>
>> --Larry Garfield
>>
>> On 11/19/2016 11:51 AM, Cees-Jan Kiewiet wrote:
>>
>> Same here, would be very interested to see what Paul has in mind for a
>> routing PSR
>>
>> On Sat, Nov 19, 2016 at 5:18 AM, Woody Gilk <woody.g...@gmail.com> wrote:
>>
>>> And if you have anything ready to share, I'd be interested to see it.
>>>
>>> --
>>> Woody Gilk
>>> http://about.me/shadowhand
>>>
>>> On Fri, Nov 18, 2016 at 3:54 PM, Paul Dragoonis <dragoo...@gmail.com>
>>> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I have been waiting to announce this until after I finish with PSR16,
>>>> but there's no time like the present.
>>>>
>>>> I have been working on the routing PSR for some time now, given my
>>>> passion and experience at integrating 5 different routers into PPI
>>>> Framework Engine.
>>>>
>>>> I have spoke with a few others about this over the past while i.e: MWOP
>>>> and others.
>>>>
>>>> I would be happy to push forward this PSR, by way of Editor, by
>>>> partnering up with someone (MWOP?), since we both have the experience at
>>>> building routing interop engines.
>>>>
>>>> On the basis that someone is willing to sponsor me.
>>>>
>>>> What do we say, is it time to release the cracken ?
>>>>
>>>> Many thanks,
>>>> Paul
>>>>
>>>> On 18 Nov 2016 1:01 p.m., "Damiano Petrungaro" <
>>>> damianopetrung...@gmail.com> wrote:
>>>>
>>>>> What do you think about an interface that will be used by
>>>>> RouterInterface for dispatch an event using a specific method?
>>>>> In this way the dispatching implementation will be bounded inside a
>>>>> single RouterInterface (so we could imagine different RouterInterfaces and
>>>>> everyone will have a RouterDispatcherInterface implemented).
>>>>>
>>>>> It's ok to put the dispatching is somewhere else on the
>>>>> implementation level, but i would like to put it inside to PSR.
>>>>>
>>>>> On Fri, Nov 18, 2016 at 7:06 AM Benni Mac

Re: [REVIEW] PSR-16 Simple Cache

[Paul Dragoonis]

Hey,

Just wanted to say thanks everyone for the compliments and for the
constructive feedback.

If there's any more clarifications in the spec that you feel are *not*
tight enough please continue to raise here or make a PR so we can review it.

Many thanks,
Paul

On Fri, Nov 18, 2016 at 4:21 PM, Nicolas Grekas 
wrote:

> Hi,
>
> PSR-6 makes it very clear that the expiration date/interval is really a
> maximum and that implementations are free to make the actual item removal
> happen anytime before.
> Actually, memcached kind of proved that *for the cache use case*, it can
> be verify effective to let the backend clean items use LRU or similar.
> If PSR-6, or 16 now, would have added a requirement for storages to be
> able to store items that never expires, that would have immediately
> disqualified these strategies and related backends.
>
> Which means to me eveything is already fine for the cache use case.
>
> But this also means that PSR-6/16 are NOT fine for non-cache related use
> cases (e.g. session storage on PSR-6 is a BAD idea exactly because of this).
>
> Regards,
> Nicolas
>
>
> 2016-11-18 4:54 GMT-05:00 Jordi Boggiano :
>
>> I will try to add it to the meta document or maybe add more text to the
>> spec regarding this default expiration. I think that's the best way to make
>> people aware of it.
>>
>> That said, the symfony cache I mentioned for example, is a PSR-6
>> implementation, and will most likely implement PSR-16, while letting you
>> have items that don't expire if you use NULL. You just don't get that
>> guarantee at the spec level, I see that.
>>
>> Cheers
>>
>> On 17/11/2016 21:21, Andrew Carter wrote:
>>
>>> I don't agree with the decision, but I understand the trade off.
>>>
>>> What we're trading is the ability to set a default value in the cache
>>> configuration at the cost of not having an interoperable way for
>>> developers to create items which don't expire.
>>>
>>> From what I can tell, the PSR-6 API that we are both replacing and
>>> trying to maintain compatibility with (?) is the only cache that
>>> operates in this manner. Most other caches operate with a NULL or 0 TTL
>>> corresponding to an entry that doesn't have a natural expiry time: apc
>>> , memcache
>>> , redis
>>> , xcache
>>> , doctrine
>>> >> /latest/reference/caching.html#saving>,
>>>
>>> the symfony one you mentioned, etc..
>>>
>>> This is my last post on the subject, but I'd like whoever calls the vote
>>> to make sure that this decision and the existence of our discussion has
>>> been made clear to the voting members. I'm not sure if there's any
>>> requirement for the voting threads to draw attention to this - but I
>>> think that would be a good precedent to set if not.
>>>
>>> My last post on the subject as I think we understand each other, just
>>> disagree on the outcome.
>>>
>>> Cheers,
>>>
>>> Andrew
>>>
>>> On Thursday, November 17, 2016 at 7:09:15 PM UTC, Jordi Boggiano wrote:
>>>
>>> I see what you mean, but down the line it doesn't actually matter as
>>> it
>>> is merely a cache.
>>>
>>> You can never rely on anything you store in there being there when
>>> you
>>> want to read it again, no matter what expiration you set. The backend
>>> might be full and wiping stuff early, etc. All you can do is
>>> *request*
>>> that something be stored for a given amount of time.
>>>
>>> Given that fact I think that the null as it is now is kinda ok, it
>>> lets
>>> an application developer if they so wish configure their lib to make
>>> all
>>> cache entries expire after X hours by default, or they can say no
>>> actually keep everything forever unless otherwise specified, or if
>>> you
>>> have specific needs as a library author you can give specific
>>> expiration
>>> times. It adds a tiny bit of control for the app developer, and
>>> doesn't
>>> really remove anything from lib developers as they can anyway not
>>> rely
>>> on any guarantee from the cache.
>>>
>>> Does this make sense to you?
>>>
>>> Cheers,
>>> Jordi
>>>
>>>   On 17/11/2016 18:43, Andrew Carter wrote:
>>> > Not sure I fully understand that - as a user I can't rely on common
>>> > sense implementations doing it right. If it's not part of the
>>> standard,
>>> > I can't guarantee it as a feature and I can't use it.
>>> >
>>> > My only course of action for using that feature would be tightly
>>> > coupling to a cache library that did support items which don't
>>> expire,
>>> > and losing interoperability (as I have done in the past).
>>> >
>>> > On Wednesday, November 16, 2016 at 4:15:21 PM UTC, Jordi Boggiano
>>> wrote:
>>> >

Re: Routing PSR

[Paul Dragoonis]

Hello everyone,

I have been waiting to announce this until after I finish with PSR16, but
there's no time like the present.

I have been working on the routing PSR for some time now, given my passion
and experience at integrating 5 different routers into PPI Framework Engine.

I have spoke with a few others about this over the past while i.e: MWOP and
others.

I would be happy to push forward this PSR, by way of Editor, by partnering
up with someone (MWOP?), since we both have the experience at building
routing interop engines.

On the basis that someone is willing to sponsor me.

What do we say, is it time to release the cracken ?

Many thanks,
Paul

On 18 Nov 2016 1:01 p.m., "Damiano Petrungaro" 
wrote:

> What do you think about an interface that will be used by RouterInterface
> for dispatch an event using a specific method?
> In this way the dispatching implementation will be bounded inside a single
> RouterInterface (so we could imagine different RouterInterfaces and
> everyone will have a RouterDispatcherInterface implemented).
>
> It's ok to put the dispatching is somewhere else on the implementation
> level, but i would like to put it inside to PSR.
>
> On Fri, Nov 18, 2016 at 7:06 AM Benni Mack 
> wrote:
>
>> Hey Hari,
>>
>> On 18 Nov 2016, at 06:27, Hari K T  wrote:
>>
>> I believe , we should allow Router to do one thing, finding / matching
>> the route, generating the route.
>>
>> Well, I think it should exactly do one thing - namely finding/match the
>> route. The generation is IMHO separate, and belongs to a route generator or
>> even URI/URL generator.
>>
>> I agree, dispatching is somewhere else on the implementation level...
>>
>> Best,
>> Benni.
>>
>> -- TYPO3 Core Team Leader
>> Support the project: http://typo3.org/donate/
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "PHP Framework Interoperability Group" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/php-fig/Fj0QoGB1xLU/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/A8BB6ABD-75E9-4678-9180-F6EE02FA2A4E%40gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CAOOfSh5-QJYg%3D77HVqDT5pHo5tuymc3vAsKrQm93S
> W%3DqKMMzYQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST9KiOSi1auXTNgxxU5mP1-_X4Rr4xEfwQC4UgZcrnpaBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internals][FIG 3.0] Extending Nomination Period & Delaying FIG 3.0 Transition

[Paul Dragoonis]

Hi Michael,

I am happy with this. I think it is the right call to make.

Many thanks,
Paul

On 9 Nov 2016 17:09, "Michael Cullum"  wrote:

Hi all,

Does anyone have any objections to extending the Core Committee nomination
period one month and pushing the FIG 3.0 implementation timetable back a
month (so the new implementation date will be 1st February)?

There are still a number of people looking to be nominated or considering
standing; meanwhile right now we only have 7 candidates when 15-20 would be
a much more appropriate number for a fair election and we think at least 12
at a minimum is still achievable if given a little more time.

--
FIG Secretaries

-- 
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/CAAqcDMhSgM3qMZAnV9674xuLuLF3YQtx_otOv53ANJHsk%2Bq%2B7Q%
40mail.gmail.com

.
For more options, visit https://groups.google.com/d/optout.

-- 
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/CAKxcST8%2BvEMBw2_Xm__MB0cEFDtm9t-D3HDrDbvN5BX9J_Fg7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Who can vote in CC elections?

[Paul Dragoonis]

Hello,

We all know quality != quantity. I'm sure you're factoring that in here.

There's people in this group that aren't that active, whom I rely on their
judgement to vote on such matters.

Can you, Michael or another appointed secretary, open up to the whole FIG
group the logic behind deciding a selective list of people can vote in CC
rather than the group as a whole?

I am of the opinion that all projects who have expressed an interest to
remain in FIG after 3.0 transition who will represent us in the CC, and
thus it should not be closed off but instead open to all member projects.

Many thanks,
Paul

On Sun, Nov 6, 2016 at 7:53 PM, Michael Cullum  wrote:

> Hi all,
>
> Just a quick note/reminder that community members who are active in the
> FIG may be eligible to vote in the upcoming Core Committee elections. We
> (the secretaries) are currently compiling a list of people which we'll post
> shortly but if you think you might be entitled to vote (the main guideline
> is 5 posts on FIG mediums such as the mailing list or Github) then please
> drop us a message so we can ensure that we've considered you and added you
> if you are eligible.
>
> As a secondary request, does anyone have a script that uses the google
> groups API to output a list of posters and how many emails they've sent to
> a google group over a time period. I recall someone this did this a few
> years ago but I cannot remember who nor find the google groups email
> thread. This would make this process a little easier as whilst we still
> need to consider people posting on other mediums like Github and check if
> posts meet the non-trivial requirement, it at least gives us a list of
> names we can begin to work from.
>
> --
> Michael C
> FIG Secretary
>
> --
> 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/CAAqcDMjZBuFAQk8SMkK9uova5bAvLDAf18ig76wPHTBhFzM98A%40mail.
> gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST-yH-pdbGOEXW-5TYCqX6Fnm0RMfYMzc5OxYaEAg-1NPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Important] [Internals] All projects must declare intention to remain members

[Paul Dragoonis]

PPI Framework will remain.

On 6 Oct 2016 9:09 a.m., "Dracony"  wrote:

> PHPixie of course will stay, +1 :)
>
> On Monday, October 3, 2016 at 1:44:02 AM UTC+2, Michael Cullum wrote:
>>
>> As per the FIG 3.0 bylaws, all member projects must, between the 1st
>> October and 31st October, declare they wish to remain a member project of
>> the FIG. If you don't wish to remain, then it would be useful for you to
>> also state this so we don't chase you up on it. Project reps, simply reply
>> to this topic if you wish to remain.
>>
>> I'd note that with FIG 3.0; there is much less of a burden/requirement
>> for project reps to put time into FIG efforts, but of course remaining
>> ensures you can still have a main seat at the table in deciding who steers
>> the FIG and assurance to be involved in any PSRs that are relevant to your
>> project and you can of course continue to be as actively involved (or more
>> so) than presently too.
>>
>> Should any old member projects who have previously left wish to re-join
>> the FIG due to the new lower requirement on activity, I imagine in January
>> there will be a combined vote for new member projects.
>>
>> Many thanks,
>> The Secretaries
>>
> --
> 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/7e7498cf-d8a3-44ba-9eb9-9cd6ef906015%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST-3dVyjB2ad3rq__Xv9SHAs4JJY01yrkTUYuo_MzuGKUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] "FIG 3.0" Bylaw amendments (Take 2)

[Paul Dragoonis]

PPI votes +1

On 24 Sep 2016 00:00, "Chuck Burgess"  wrote:

> +1 from PEAR
>
> On Sep 23, 2016 13:39, "Michiel Rook"  wrote:
>
>> +0 Phing
>>
>> On 17-9-2016 1:14, Larry Garfield wrote:
>>
>> I hereby open a vote for the following bylaw changes, colloquially known
>> as "FIG 3.0".  I'm fairly certain anything that needs to be said has been
>> said by now by all parties.
>>
>> https://github.com/php-fig/fig-standards/pull/752
>>
>> The vote will be open for 2 weeks, closing on 30 September 2016.
>>
>> As usual, the vote is open to voting representatives only and is a simple
>> +1/-1 vote.
>>
>> --Larry Garfield
>>
>>
>>
>>
>> --
>> [image: Avast logo] 
>>
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.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 post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/php-fig/79b8ee73-95f6-ba4d-97d1-fd0806469d61%40gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CANsgjnu1NeCXY%2BySPtLMr3%3Dno_Txi3N43T0WT-
> ve4jWCzJfRew%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST_FaNcGa3Gw1VhkQH0Ma3vnnZ9vCSLkzaYMV72Z0pPzAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] [Bylaw Amendment] Do not require interface suffix on future PSR Interfaces

[Paul Dragoonis]

-1 from PPI Framework

On Sat, Sep 10, 2016 at 2:53 AM, Andres Gutierrez <
gutierrezandresfel...@gmail.com> wrote:

> -1 from Phalcon
>
> On Sunday, 4 September 2016 11:26:50 UTC-5, Michael Cullum wrote:
>>
>> Hi all,
>>
>> The PSR-11 Editors have requested we open this vote for them as they are
>> unable to do so not being voting members.
>>
>> *Status Quo:* The bylaw states that all interfaces in PSRs published by
>> the PHP FIG must have the interface name suffix of 'Interface' e.g.
>> `LoggerInterface`
>> *Change:* The proposed change is that we no longer require that
>> interfaces are suffixed by 'Interface' so `ContainerInterface` would become
>> `Container`
>>
>> Arguments for/against and [two week] *discussion*: http://bit.l
>> y/interface-suffix-discussion
>> *Pull request for bylaw change*: http://bit.ly/interface-suffix-pr
>>
>> Note: This will only affect future PSR production (of PSRs in draft or
>> not yet through an entrance vote) so will not break or change any current
>> PSRs. It is also not a standard or recommendation for the PHP community or
>> member projects, but an internal bylaw on how we name interfaces in our own
>> interfaces in PSRs.
>>
>> Voting will close in two weeks on the 18th September at 23:59 UTC. Voting
>> is available to voting members and may be cast as +1 (For), -1 (Against) or
>> 0 (Abstain).
>>
>> --
>> Many thanks,
>> Michael Cullum
>>
> --
> 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/de834c7a-1078-4b99-961e-452836588166%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST_P8xTXxiEz9bRWnuKf73W2uSiskGWOLb483yH%3DMTRbWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Github Permissions Update

[Paul Dragoonis]

On Mon, Jul 11, 2016 at 2:23 PM, Michael Cullum <m...@michaelcullum.com> wrote:

> Hi Paul,
>
> This was back in May. Can I ask what you need access to the website for
> and we can re-instate it?
>

To continue to maintain the Jekyll, HTML, styling amongst other website
related things.


>
> It was removed when we did a cleanup because we didn't see a need for you
> to have access (and abiding by the agreed policy of only give access when
> it's needed or serves a distinct purpose) and it was, if I recall
> correctly, removed after you merged a pull request removing member projects
> from the listing that us [the secretaries] had intentionally not merged as
> we were waiting on confirmation from member projects concerned.
>

I will be no longer merging any "member project" related PR's.


>
> Whilst Jonathan for example has access to the website repo, he only merges
> things relating to the styling, formatting and Jekyll stuff without
> checking with us, not procedural things like the [canonical] member list
> and as the guy who built essentially the entire site, he knows it better
> than anyone.
>

You missed a step.

Me, bobthecow and Phil S (amongst others) are the people who built and
maintained the php-fig website, for a number of years. We're very happy
with the recent skin that Jonathan provided on top. However, the point
you're missing is that because a new community member comes along and adds
a skin then the existing team gets booted out.

I'd like to be re-instated back into the web team.


>
> Thanks,
> Michael
>
>
> On Monday, 11 July 2016 12:55:32 UTC+1, Paul Dragoonis wrote:
>>
>> All of a sudden my RW access to the website got removed. Can this be
>> reinstated please. Thanks.
>>
>> On Sat, Jul 9, 2016 at 2:40 PM, Michael Cullum <m...@michaelcullum.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I've just done a bit of updating with regards to github permissions.
>>> Those who should have access to things (Ping me if you don't):
>>>
>>>
>>>- Every Draft or Review PSR has it's sponsor, editor and coordinator
>>>with write access to php-fig/fig-standards, so long as they are voting
>>>representatives
>>>- We have a website team consisting presently of just Jonathan
>>>Reinink who has access to the website. At the moment this is more of a
>>>discretionary thing for people contributing a lot to the website such as
>>>Jonathan who wrote our current site and helps us [secretaries] out
>>>regularly with frontend and jekyll stuff.
>>>- Secretaries are owners
>>>- Relevant PSR-teams have push access to any particular repos
>>>concerning their PSR e.g. the log and cache interface repos.
>>>
>>>
>>> Should you ever wish to mention PSR's working group [past or present] or
>>> the like, all teams are public and @mention-able by their PSR number e.g.
>>> @php-fig/psr-5 or @php-fig/secretaries.
>>>
>>> I'd also like to extend the privilege of access to php-fig/fig-standards
>>> write access to editors who have been around for a while [around in member
>>> projects, the FIG or the PHP Community], are trusted but are not voting
>>> representatives (e.g. Woody, Matthieu, David and Michael). As the editor
>>> they have (as per the bylaws) the final yes/no for what goes into their
>>> specifications so not giving them push access seems a little odd. All
>>> branches are protected anyway so they cannot force push and any rouge
>>> commits would be noticed very quickly so I see little risk. It would also
>>> increase the usefulness of @mention'ing the teams of PRs as it would always
>>> include the Editor. Are there any objections to this?
>>>
>>> Finally, but most importantly, just a regular reminder to those with
>>> access, and to those just receiving access,* please only ever merge
>>> changes which only concern your own [draft stage] PSR*; any merges to
>>> approved PSRs [typos], the index, licenses or to other PSRs (when the WG is
>>> unable to do so) should be left to secretaries (feel free to highlight us
>>> with @php-fig/secretaries if you feel we've missed something).
>>>
>>> --
>>> 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.
>&

Re: [VOTE] Secretary Election August 2016

[Paul Dragoonis]

Votes for PPI

1. Samantha Quiñones
2. Jonathan Reinink
3. Amanda Folson
4. Matthew 'Matt' Trask
5. Paul 'PMJ' Jones
6. Phil Sturgeon


On Sun, Aug 14, 2016 at 10:31 PM, Dracony  wrote:

> Votes for PHPixie:
>
> Paul 'PMJ' Jones
> Samantha Quiñones
> Amanda Folson
> Jonathan Reinink
> Matthew 'Matt' Trask
>
>
>
> On Saturday, August 13, 2016 at 12:24:40 AM UTC+2, Michael Cullum wrote:
>>
>> Hi all,
>>
>> So for those unaware, it's that time again. Every 8 months a secretary's
>> term ends and on this occasion, we have both a term ending (Previously
>> filled by Samantha) and a vacancy to fill (after Joe's resignation), so two
>> secretaries will be elected. Whoever comes first will be in post until
>> August 2018 and the term of whoever is second will end in 8 months.
>>
>> Samantha is standing for re-election, but she is just as any candidate,
>> and therefore may be elected into either term, or neither. No matter the
>> outcome, I am sure you will all join me in offering a word of thanks on
>> behalf of the FIG to both Samantha and Joe for their work these past 6-8
>> months.
>>
>> Full information about the Secretary vote and role is visible in the
>> bylaws here: https://github.com/php-fig/fig-standards/blob/master/bylaws/
>> 003-membership.md#fig-secretary
>>
>> I suggest you check out their nomination topics for information about
>> themselves and to ask questions. All candidates except Paul (as his
>> nomination was quite late in the process) have spoken with Samantha or
>> myself about what the role entails and I'd add that they all appear to be
>> aware of both the commitment required and the role/responsibilities defined
>> in the bylaws.
>>
>> *Nominations List*
>>
>>- Jonathan Reinink - Topic
>>
>>- Samantha Quiñones - Topic
>>
>>- Matthew 'Matt' Trask - Topic
>>
>>- Phil Sturgeon - Topic
>>
>>- Paul 'PMJ' Jones - Topic
>>
>>- Amanda Folson - 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 six 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 26th August,* and I will close the
>> vote and *announce the result at some point on the 27th*. 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.
>>
>> *Finally*, I will repeat something I have reiterated privately to
>> candidates and in a nomination topic:
>>
>>> I'd ask everyone keep this election fair and clean. Secretaries are in
>>> the role they are in to be neutral and I'd ask people consider the impact
>>> that bringing (for lack of a better term) politics into a Secretary
>>> election could have on that Secretary's ability to do their job and in the
>>> same way, candidates may very well be expected to soon represent a neutral
>>> position so I would recommend they keep this in mind throughout the
>>> election. In the same fashion, I'd ask that once a Secretary is elected,
>>> whoever they may be, they are given the chance to execute their duties
>>> properly and are given a chance *by all*; nobody wants to see the FIG
>>> split due to who has been elected, or who hasn't been elected, as Secretary.
>>
>>
>> Good luck to all the candidates!
>>
>> --
>> Many thanks,
>> Michael Cullum
>> FIG Secretary & August 2016 Secretary Election Returning Officer
>>
>> [1]: STV User-friendly Explanation https://www.youtube.com/watch?
>> v=l8XOZJkozfI
>> [2]: 

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Paul Dragoonis]

On 9 Aug 2016 9:22 p.m., "Samantha Quiñones" 
wrote:
>
> As Gary said, please let's keep this on-topic and not personal. I advise
you to please assume that others are contributing constructively unless
it's been shown otherwise.

I want to aplogise for the personal nature of my reply, i didn't mean it
like that. I mean nothing personal and was opposing the general idea
proposed

>
> --S
>
> --
> 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/c91cead9-a79a-419c-a662-de5271fc5d7b%40googlegroups.com
.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAKxcST_DGLWAgRug9%3DkhZNQVvPYwdYP-8QwVA5%2Bw1znBmqCGWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Paul Dragoonis]

On 9 Aug 2016 17:54, "Larry Garfield"  wrote:
>
> Given that there's ~9 specs being worked on currently in various stages,
the idea that FIG's work is "done" seems completely unsupportable.
>
> FIG is already the de facto PHP Standards Body.  That much is very clear;
some here don't want to admit that, but that's very clear from the Reddit
thread on the subject, talks at conferences, impacts on projects and
tooling (PSR-2 preset in PHPStorm?) and general zeitgeist.
>
> As Michael noted previously, if a "new" body were to form one of two
things would happen:
>
> 1) FIG would continue, there'd be 2 competing standards bodies, and thus
no actual standards.  This is the worst possible outcome for
interoperability and collaboration.
>
> 2) FIG would die off, either quickly or slowly, and the new group would
try to fill its ecological niche.  That would be a very messy and
complicated process with an ugly, confusing transition period, which
benefits no one.  The only way to minimize that would be for FIG to
actively shut itself down completely as soon as the new group is setup, and
publicly say "they're replacing us, kthxbye".  Which... would have the same
net effect as FIG just evolving, but would be more logistically complicated
and confuse a bunch of people needlessly.
>
> FIG isn't "done".  It's not "dead."  It's just evolving.  That's OK.
Really!  We should be accustomed to this by now.  PHP as a language and
community is one of the fastest evolving around.  PHP has reinvented itself
in the last 6-7 years, and FIG has been a part of that.  That's something
we should be proud of.
>
> But FIG can and should evolve along with PHP.  We've done it before.  The
FIG of 2009 is not at all what we are today.  When the entirely
cowboy-free-for-all way of working on specs broke down, we changed the
process and added more formality.  (FIG 2.0, which added the formal Editor,
Sponsor, and Coordinator.)  It was an improvement.  Now, we're still
growing and see a need to evolve our structure further.  That doesn't mean
FIG is "done", just that we're evolving to improve ourselves.  In a few
years, might the situation have changed further and we need to tack again,
with a FIG 4?  Quite possibly!  And when that time comes we should be
prepared to evolve with it.
>
> We, as a community and as FIG, should be looking forwards, how we can
continue to help PHP into the future.  Not closing up shop because "whelp,
autoloading and coding standards are done, peace out."
>
> Closing up shop or turning into just a passive rubber-stamp for people we
refuse to let collaborate in our space is short-sighted and ultimately
self-defeating.
>
> The fact that there are 9 groups trying to build additional collaborative
standards within FIG should be a sign that people do see value in FIG, and
we're nowhere close to "done".  If anything, it's a sign of a potentially
bright future for FIG and PHP, if we approach it properly.
>
> --Larry Garfield

Well said Larry.

Seriously Joe ?

I've been contributing to all iterations of FIG for years now, and I'm not
impressed by people wanting to shut it down. Not one bit.

Seriously folks, can we stop feeding the dragon and instead focus on the
task at hand ?

Thanks.

>
>
> On 08/09/2016 11:17 AM, Joe Ferguson wrote:
>>
>> By “standards for the language” I mean an official (or as close to
official as it can get)  Standards for the PHP language. PHP has never (as
far as I’m aware) had a Standards Body. FIG is as close as we’ve come. My
observation is that FIG 3.0 should skip FIG and become that standards body.
>>
>>> On Aug 9, 2016, at 11:10, Alessandro Pellizzari  wrote:
>>>
>>> On 09/08/2016 16:37, Joe Ferguson wrote:
>>>
 I would rather see FIG marked complete, and those leaders interested in
 moving forward start a new PHP Standards Body that would adopt (not
 claim) the previous PSRs from FIG and begin work on more standards for
 the language, not frameworks or packages.
>>>
>>> I partly agree with what you say, but what do you mean by "standards
for the language"? Could you give some examples?
>>>
>>> Bye.
>
>
> --
> 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/779690d4-8d55-90d3-2849-013f16947732%40garfieldtech.com
.
>
> For more options, visit https://groups.google.com/d/optout.

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

Re: Status of PSR-12 survey

[Paul Dragoonis]

On 31 Jul 2016 8:28 p.m., "'Alexander Makarov' via PHP Framework
Interoperability Group" <php-fig@googlegroups.com> wrote:
>
> While I agree that it could be a good idea to wait till PHP7 adoption and
usage rate will raise, I think that it would be better if PSR-12 current
state (master) will reflect what people prefer or like even if they aren't
using PHP7 yet. It's definitely better alternative than not being backed up
by any statistics.
>
> After the survey proposal will be changed. Then it could be frozen till
certain level of PHP7 adoption or not. That's to be discussed later.

This is a fair compromise

>
> On Sunday, July 31, 2016 at 10:12:16 PM UTC+3, Paul Dragoonis wrote:
>>
>> On 31 Jul 2016 19:58, "Paul Jones" <pmjo...@gmail.com> wrote:
>>
>> >
>> >
>> > > On Jul 31, 2016, at 13:36, Michael Cullum <m...@michaelcullum.com>
wrote:
>> > >
>> > > Hi Paul,
>> > >
>> > > A mix of the two.
>> >
>> > Well, let's remove one part of that mix, then.
>> >
>> >
>> > > As previously stated, this PSR was always going to include a degree
of both being prescriptive and being descriptive,
>> >
>> > Yes, and it's a mistake for it to be so.  The better course is to see
what people actually do in their own projects, and then collect it, rather
than make things up.  The place for creation-anew is in individual projects
(bottom up) not here in the FIG (top down).
>>
>> I second this.
>>
>> I want us to replicate the success of PSR2 which means we need to wait
for a significant amount of major projects, that support PHP7 in a stable
release, to collect such results.
>>
>> If the PSR-12 contributors have good reasons to show that we don't need
to wait then i would like to hear it.
>>
>> Cheers,
>> Paul
>>
>> >
>> >
>> >
>> > --
>> >
>> > Paul M. Jones
>> > http://paul-m-jones.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.
>>
>> > To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/D980BBCA-30E4-4D83-A2E1-6ADF43C7E39A%40gmail.com
.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/70a8d8bb-47cd-459f-b8cf-8b2bb3c0e6a2%40googlegroups.com
.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAKxcST-oMRORaJ11SVD0GG7W8AWLqPijQz0xVwjnCgnPND-cew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of PSR-12 survey

[Paul Dragoonis]

On 31 Jul 2016 19:58, "Paul Jones"  wrote:
>
>
> > On Jul 31, 2016, at 13:36, Michael Cullum  wrote:
> >
> > Hi Paul,
> >
> > A mix of the two.
>
> Well, let's remove one part of that mix, then.
>
>
> > As previously stated, this PSR was always going to include a degree of
both being prescriptive and being descriptive,
>
> Yes, and it's a mistake for it to be so.  The better course is to see
what people actually do in their own projects, and then collect it, rather
than make things up.  The place for creation-anew is in individual projects
(bottom up) not here in the FIG (top down).

I second this.

I want us to replicate the success of PSR2 which means we need to wait for
a significant amount of major projects, that support PHP7 in a stable
release, to collect such results.

If the PSR-12 contributors have good reasons to show that we don't need to
wait then i would like to hear it.

Cheers,
Paul

>
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.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 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/D980BBCA-30E4-4D83-A2E1-6ADF43C7E39A%40gmail.com
.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAKxcST-UBg8%3DR-SkQVx6JkUR-Xbr8%2B84zsCTOyzED8Onm-X9jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Cache] Errata regarding \DateTimeInterface

[Paul Dragoonis]

On Thu, Jul 28, 2016 at 5:28 PM, Larry Garfield 
wrote:

> Hm.  I would be open to this.  We can include the sample code to
> copy-paste in the errata, and include it in the utlis package.
>
> Does anyone object to this recommendation for the errata?  Paul and Robert
> especially?
>
> --Larry Garfield
>

Hey Larry,

Can you ping me on twitter or something when you need my attention, I'm not
checking every thread message. You should ping Robert manually too as I
doubt he's noticed this, his input will be of value.

I agree with the rejection of non DateTime|DateTimeImmutable parameters to
CacheItemInterface::expiresAt($expiration).

I'm happy with the trigger_error() approach that Brent Shaffer provided as
a way to mimic PHP5 and PHP7 invalid type handling.

Many thanks,
Paul


>
>
> On 07/28/2016 11:19 AM, Brent Shaffer wrote:
>
> If we want to mimic a type error, we could do the following:
>
> $error = sprintf('Argument 1 passed to %s::expiresAt() must be an
> instance of DateTime, string given', get_class($this));
> if (class_exists('TypeError')) {
> throw new \TypeError($error);
> }
> trigger_error($error, E_USER_ERROR);
>
> It's verbose but it's the closest we can get to native handling while
> still obeying the spec.
>
> - Brent
>
> On Wednesday, July 27, 2016 at 11:21:30 AM UTC-7, Brent Shaffer wrote:
>>
>> Unfortunately, there is no way to trigger an E_RECOVERABLE_ERROR. You can
>> only trigger user-level errors, so E_USER_ERROR is the closest you can get.
>> E_USER_ERROR is catchable via set_error_handler(), so this should be
>> approximately the same.
>>
>> - Brent
>>
> --
> 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/b38673aa-3cac-4c29-bbc3-69030036dfbf%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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/9e949206-2349-1392-35d8-658dc91a0e0a%40garfieldtech.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST-qoRDod75XumXZTzhDZHjOdNseiUOzqYwdVekNcfXgRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Vote] Require Aura project to replace its representative

[Paul Dragoonis]

-1 PPI

On 29 Jul 2016 2:54 p.m., "Michael Cullum"  wrote:

> Judd,
>
> Voting is for project representatives of member projects only as per the
> voting protocol[1] and only votes, not discussion or opinion polling,
> should take place in this thread.
>
> Thanks,
> Michael Cullum
> FIG Secretary
>
> [1]: http://www.php-fig.org/bylaws/voting-protocol/
>
> --
> Michael C
>
> On 29 July 2016 at 14:48, Judd Bundy  wrote:
>
>> -1
>>
>> On Thursday, July 28, 2016 at 4:56:52 PM UTC-7, Samantha Quiñones wrote:
>>>
>>> All,
>>>
>>> The discussion period having concluded, I am now opening a vote on the
>>> matter of the proposal to require the Aura project to name a new voting
>>> representative.
>>>
>>> The discussion thread is available here:
>>> https://groups.google.com/d/msg/php-fig/w38tCU4mdgU/R1oyiIMuAAAJ
>>>
>>> To summarize, I am opening this vote at the request of a number of
>>> voting representatives who have asked that this matter be taken up under
>>> the Voting Representatives section of the Membership Bylaw, the full text
>>> of which is located here:
>>> http://www.php-fig.org/bylaws/membership/#voting-representatives. The
>>> relevant section of the bylaw is as follows:
>>>
>>> "If, in the judgement of PHP-FIG, a Voting Representative is acting
>>> inappropriately and to the detriment of PHP-FIG's ability to meet its
>>> objectives, a vote may be taken to request a replacement Voting
>>> Representative in accordance with the Voting Protocol bylaw or to expel the
>>> Member Project where replacing a Voting Representative is not possible."
>>>
>>> A vote of +1 is a vote for requiring the Aura project to name a new
>>> voting representative.
>>>
>>> A vote of -1 is a vote against requiring the Aura project to name a new
>>> voting representative.
>>>
>>> If the motion passes, the current voting representative (Paul M. Jones)
>>> will be removed as the listed voting representative for the Aura project.
>>> The Aura project may then name a new representative in the usual fashion.
>>> If the project fails to name a new representative, it is subject to
>>> expulsion under the bylaws.
>>>
>>> If the motion fails, the Aura project will not be required to name a new
>>> representative.
>>>
>>> This vote will proceed according the Voting Protocol and will close on
>>> 11-August-2011 at 23:59 UTC.
>>>
>>> To further clarify, this vote is not a vote to ban Paul M. Jones from
>>> participation in the FIG, only to request the Aura project to name a new
>>> voting representative. Further, this vote is not about whether you like or
>>> dislike Paul, but if you believe that he has acted in a way detrimental to
>>> the FIG.
>>>
>>> I want to make it explicitly and unequivocally clear that the purpose of
>>> this thread is for qualified voting members to vote on the matter at hand.
>>> This is a very sensitive issue and I will not tolerate discussion or
>>> flaming in this thread. I ask that all participants please respect Paul's
>>> dignity, as well as the dignity of the FIG, and refrain from personal
>>> attacks or other disruptive or divisive behavior. There are human beings
>>> involved in absolutely every step of this process and I further ask you to
>>> give one another the benefit of the doubt and operate from the assumption
>>> that others are working as hard for the success and advancement of the FIG
>>> as you are.
>>>
>>> If you have any questions about this vote, please direct them to info
>>> [at] php-fig.org.
>>>
>>> Thank you for your participation,
>>> Samantha Quiñones, Secretary
>>>
>> --
>> 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/8b551e91-d85e-4784-a547-65e6a71bda79%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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/CAAqcDMiv%2BJPdff%3D-ENCLmArZ7t7C1t6x89phj_GTvRDCfLjk4A%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received 

Re: Github Permissions Update

[Paul Dragoonis]

All of a sudden my RW access to the website got removed. Can this be
reinstated please. Thanks.

On Sat, Jul 9, 2016 at 2:40 PM, Michael Cullum  wrote:

> Hi all,
>
> I've just done a bit of updating with regards to github permissions. Those
> who should have access to things (Ping me if you don't):
>
>
>- Every Draft or Review PSR has it's sponsor, editor and coordinator
>with write access to php-fig/fig-standards, so long as they are voting
>representatives
>- We have a website team consisting presently of just Jonathan Reinink
>who has access to the website. At the moment this is more of a
>discretionary thing for people contributing a lot to the website such as
>Jonathan who wrote our current site and helps us [secretaries] out
>regularly with frontend and jekyll stuff.
>- Secretaries are owners
>- Relevant PSR-teams have push access to any particular repos
>concerning their PSR e.g. the log and cache interface repos.
>
>
> Should you ever wish to mention PSR's working group [past or present] or
> the like, all teams are public and @mention-able by their PSR number e.g.
> @php-fig/psr-5 or @php-fig/secretaries.
>
> I'd also like to extend the privilege of access to php-fig/fig-standards
> write access to editors who have been around for a while [around in member
> projects, the FIG or the PHP Community], are trusted but are not voting
> representatives (e.g. Woody, Matthieu, David and Michael). As the editor
> they have (as per the bylaws) the final yes/no for what goes into their
> specifications so not giving them push access seems a little odd. All
> branches are protected anyway so they cannot force push and any rouge
> commits would be noticed very quickly so I see little risk. It would also
> increase the usefulness of @mention'ing the teams of PRs as it would always
> include the Editor. Are there any objections to this?
>
> Finally, but most importantly, just a regular reminder to those with
> access, and to those just receiving access,* please only ever merge
> changes which only concern your own [draft stage] PSR*; any merges to
> approved PSRs [typos], the index, licenses or to other PSRs (when the WG is
> unable to do so) should be left to secretaries (feel free to highlight us
> with @php-fig/secretaries if you feel we've missed something).
>
> --
> 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/4d12fd38-bbf5-4163-832e-b3656b083914%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKxcST_2gDqFrPDsaeW3pgjo2GYSiXV3xg%2BdR5dj-YrDxG8QxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.