Re: naming PSR

[Lukas Kahwe Smith]

some more work went into tweaking the language and structure. I have
another review scheduled with a content expert at Liip.

but I would also like to get an indication how to shape this further to fit
FIG.

I could envision moving the list of examples to a separate document that is
neither a PSR or by-law but that is updated once per year (or more often),
that is referenced from an inclusive language PSR similar to the other
resources.

wdyt?

regards
Lukas

On Wed, 19 Aug 2020 at 16:11, Lukas Kahwe Smith 
wrote:

>
>
> On Tue, Aug 11, 2020 at 6:02 PM Alessandro Lai 
> wrote:
>
>> Thanks Lukas for the continued effort on this topic. You're basically
>> stumbling on a recurring problem that we have here at PHP-FIG: we don't
>> have a way to stipulate a "living document", something that is similar to a
>> PSR but can evolve.
>>
>> IMHO this could actually work if we write down a new bylaw that handles
>> this case, and it would solve similar issues like the coding standard (see
>> PSR-12) where the PSR can't keep up with how fast the language is evolving.
>> I'll give this some more thought and try to find a way to draft a bylaw
>> that encapsulates a basic solution to this.
>>
>
> thx!
>
> in the meantime, here is a first draft of a document about inclusive
> language
>
> https://docs.google.com/document/d/1-5iNw4xcfWLquVoV22QceYHFKdKode0VEhmQaC3fbcQ/edit#
>
> I have enabled comments/suggestions.
> It can become whatever .. a PSR, a by-law or something else. Once we have
> figured this out we can convert it to a PR.
>
> regards,
> Lukas
> --
> regards,
> Lukas
>
>
> --
regards,
Lukas

-- 
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/CAEFKHaE4yF0zZ3m1_yiH9_ZW-BQ_uoWmTQKn0g-oTK9bDKQ-kQ%40mail.gmail.com.

Re: naming PSR

[Lukas Kahwe Smith]

On Tue, Aug 11, 2020 at 6:02 PM Alessandro Lai 
wrote:

> Thanks Lukas for the continued effort on this topic. You're basically
> stumbling on a recurring problem that we have here at PHP-FIG: we don't
> have a way to stipulate a "living document", something that is similar to a
> PSR but can evolve.
>
> IMHO this could actually work if we write down a new bylaw that handles
> this case, and it would solve similar issues like the coding standard (see
> PSR-12) where the PSR can't keep up with how fast the language is evolving.
> I'll give this some more thought and try to find a way to draft a bylaw
> that encapsulates a basic solution to this.
>

thx!

in the meantime, here is a first draft of a document about inclusive
language
https://docs.google.com/document/d/1-5iNw4xcfWLquVoV22QceYHFKdKode0VEhmQaC3fbcQ/edit#

I have enabled comments/suggestions.
It can become whatever .. a PSR, a by-law or something else. Once we have
figured this out we can convert it to a PR.

regards,
Lukas
-- 
regards,
Lukas

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

Re: FIG CoC - take 2

[Lukas Kahwe Smith]

On Sun, Aug 9, 2020 at 12:14 AM Larry Garfield 
wrote:

> Getting back to this...
>
> It looks like there's a couple of different threads here, which I will try
> to separate:
>
> 1) Code Manifesto vs Contributor Covenant.  I really wish we wouldn't get
> hung up and side tracked on this, honestly.  That said, I read over the CC
> v2 link that Lukas posted and it looks like v2 addresses a lot of my
> concerns with v1, especially the negative/punitive structure of it.  That's
> very good to see.  I still favor the Manifesto model, and even CC v2 would
> need some tweaking for FIG (as below) but I am not as firmly opposed to CC
> v2 as I was to v1.
>
> 2) Regarding enforcement, I have to admit I'm confused.  The Manifesto
> doesn't include an enforcement model built in, that's true.  But the PR
> does.  It very clearly lays out that violation of the CoC is grounds for
> removal, and in what situations and by whom such removal happens.  Does
> anyone have input on that specifically?
>

yes but the issue is that the manifesto does not sufficiently define what
problematic behavior is. also the covenant v2 also tries to give an
indication of the consequence ladder which helps to increase clarity.


> Of note, for official positions there is an existing removal process
> already in place (there's votes for it), which I believe is appropriate to
> retain.  While for most people having the Secretaries (what the CC v2 calls
> Community Leaders) temp ban or perma-ban someone for mouthing off too far
> is fine, for elected positions I do believe a bit more formality is
> appropriate and warranted.  I was also trying to keep the procedural
> changes to a minimum, when we already have procedures in place.
>

if that remains the case, then I guess the indeed secretaries are
automatically also tasked with handling reports.
now in case of the most extreme offenses resulting in a need to ban
someone, which would also require an expulsion if that person holds a
formal position, there would need to be some sort of process by which
voters get informed but in a manner that respects the privacy of the
accuser and accused.


>
> 3) Michelle, are you suggesting we should have a separate
> CoC/CARE/Community Working Group/Thing group distinct from the Secretaries,
> or just giving that as background?  While I agree training in CoC handling
> can be useful, in practice FIG is small enough and low-bandwidth enough
> that I'm not sure the ROI of formalizing it is worth it at this point.  (If
> we got to that point, I'd consider that a "good problem to have" but right
> now it's not a problem I think we have.)
>

I do not intend to speak here on behalf of Michelle but I have some
thoughts on this ..

while I think the cost of a CoC training is not prohibitively high and
anyone doing such a training will benefit in many ways, I do understand
this line of reasoning. which is why I would like to see this
professionalized and offered as a service to the PHP community. but that is
likely beyond the scope of this first step.


> 4) Specific tooling to assist in the process I don't believe belongs in
> the bylaws.  Should the Secretaries/whoever find it useful, sure, that's
> fine by me, but at least as far as the bylaws are concerned "these are the
> people, this is their email" seems sufficient.
>

agreed. at most some general indication to remind them of the
responsibility to maintain the privacy of the accuser and accused as much
as possible while ensuring the stated goals for safety in the community to
be the highest priority.

-- 
regards,
Lukas

-- 
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/CAEFKHaEsmakZenLTd7GT3KyUtcnPyYGwRs59PVwxvSAR6Gg_6A%40mail.gmail.com.

Re: naming PSR

[Lukas Kahwe Smith]

On Wed, 15 Jul 2020 at 17:49, Lukas Kahwe Smith 
wrote:

> Aloha,
>
> First up Chris thank you for your input specifically.
>
> Happy to see so many voices of support as well.
>
> In general: Who would be motivated to work with me on shaping a proposal?
> Please contact me directly via slack, email, twitter (@lsmith) ..
>
> Note: For now I would put the scope on inclusive language only. However I
> think in parallel work could also be done on maybe looking at other sources
> for issues in naming like the Events example I mention.
>

Sorry for the long silence. I am still very much committed the the topic.

>From the feedback I got here, on FIG slack and other places there were
quite a few voices that feel like a PSR isn’t the right format. I therefore
decided to approach the topic more as “what would I as a
developer/documentor/etc need” to more easily be able to use inclusive
language?

Jenny Wong shared with me documentation they created at the company she
works at:
https://engineering.hmn.md/standards/naming-things/

This document tries to essentially cover the general considerations, some
concrete examples but then links to additional resources.

Most notably it links to the following guide by google which seems to be
the most complete and well structured document I found on the topic:
https://developers.google.com/style

My only criticism is that it might be a bit overwhelming. So I think it is
specifically something people that act as editors for documentation should
be fully aware of but as a general resource I fear it could lead to people
giving up as it feels too big an effort to make any difference.

So I think I like the approach of giving an overview, I also like giving
detailed examples but I would then add a bigger section which can be read
in 5-10mins with less details that should be enough to make a material
impact and then linking other more detailed resources at the bottom.

Now this approach indeed might not lend itself to a PSR which I guess is
the type of document that is more definitive and where compliance can be
determined in a more binary fashion.

I do however want a document that actively encourages PHP projects to adopt
it.

I also do want to also offer some sort of method to more easily validate
(or at list get a list of things to review in detail) both code and
documentation (
https://github.com/OskarStark/doctor-rst/blob/master/src/Rule/BeKindToNewcomers.php).
Maybe also discussions on their chat (https://github.com/keoghpe/alex-slack)
and in pull requests.

Especially for chat/PRs I realize that people will likely tend towards
becoming defensive and others might get annoyed by the disruption if the
comments are done inside the normal discussion. As such the best approach
might be a throttled (opt-in?) feedback via a separate channel (DM, email).
See also
https://github.com/keoghpe/alex-slack/pull/2

regards,
Lukas

>

-- 
regards,
Lukas

-- 
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/CAEFKHaEbyKOQnPQSykkPd60S9ZdbT0MFw4xC0qHC0AnioYYxOQ%40mail.gmail.com.

Re: FIG CoC - take 2

[Lukas Kahwe Smith]

Aloha,

thank you for bringing this up again.

there were already quite a few comments on the PR at the time, which
interested people should have a look at.

I also share the concern that this CoC lacks explicitness which is why I
also favor a covenant of code based CoC. this is what we created for
Symfony.
https://symfony.com/doc/current/contributing/code_of_conduct/code_of_conduct.html

Since then version 2.0 was released, which I have not studied in detail but
afaik it now contains enforcement guidelines
https://www.contributor-covenant.org/version/2/0/code_of_conduct/

for Symfony we have created our own (heavily inspired from Sunshine PHP,
who in turn were inspired by others):
https://symfony.com/doc/current/contributing/code_of_conduct/reporting_guidelines.html

Of course it is important that people receiving reports know what they are
doing. For Symfony we got a group of people trained by Sage Sharpe:
https://symfony.com/doc/current/contributing/code_of_conduct/care_team.html
https://otter.technology/code-of-conduct-training/

Semi related to this there is an initiative to create a tool for CoC
reporting. The key benefit I see is:
1) proper handling of records
2) ability for anonymous reporting
3) ability for report handlers to be excluded or to recuse
4) ability to collect statistics that could help identify cross community
"grey" behavior

Note the tool is not yet "production" available. Mostly because there are
3rd party evaluations missing.
But this could be an amazing service for the entire PHP community.

So to me the key things I would like to have changed:
1) more explicit
2) reporting guidelines
3) trained team to handle reports

However I do think this is a step forward, but I feel quite strongly that
without 2)/3) we might just offer a solution that will fail affected people
when push comes to shove.

regards,
Lukas



On Mon, Jul 20, 2020 at 2:50 AM Larry Garfield 
wrote:

> Hi folks.
>
> Last year I proposed a CoC for FIG, based on the Code Manifesto by Graham
> Daniels.  It was subsequently edited a bit by former FIG Secretary Margaret
> Staples.  I left it lie for a bit in the hopes that Margaret's changes
> would be merged back into the Code Manifesto proper, but that never
> happened and then I got distracted by other things and then the world
> turned upside down and... yeah.
>
> So, I'm finally back with take 2, which is really just continuing where
> the previous attempt left off.  Specifically, this PR:
>
> https://github.com/php-fig/fig-standards/pull/1143
>
> The only change I am still debating myself is whether to include
> "lifestyle choice" as one of the forms of discrimination that we're not on
> board with.  It is a distinction that is important to me (as many know),
> but I know that others fear it is too easy to hide jerkish behavior
> behind.  That said, I'm certain a dedicated jerk could hide behind
> absolutely any label if they put their mind to it.  Hence my hesitation.
>
> Since it's been so long I'll consider this a new discussion period of
> minimum 2 weeks, with the intent to bring it to a vote shortly thereafter.
>
> --
>   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/a6954973-11df-49cf-ad92-5d9c8fb195d1%40www.fastmail.com
> .
>


-- 
regards,
Lukas

-- 
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/CAEFKHaGofSXVPrMN1djpzLuD4tbaaZCXJAgi5f1VKN8ZEhh6Ag%40mail.gmail.com.

Re: naming PSR

[Lukas Kahwe Smith]

Aloha,

First up Chris thank you for your input specifically.

Happy to see so many voices of support as well.

In general: Who would be motivated to work with me on shaping a proposal?
Please contact me directly via slack, email, twitter (@lsmith) ..

Note: For now I would put the scope on inclusive language only. However I
think in parallel work could also be done on maybe looking at other sources
for issues in naming like the Events example I mention.

regards,
Lukas
-- 
regards,
Lukas

-- 
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/CAEFKHaGxRk0FmjCBvEhdn_x17SpCn-Zu-gCiF8qP%2B3htNGMuPQ%40mail.gmail.com.

naming PSR

[Lukas Kahwe Smith]

Aloha,

So the topic of naming things has become even more discussed as in the
previous years in part due to recent protests in the world.

I think most of us are familiar with the saying "There are only two hard
things in Computer Science: cache invalidation and naming things."

Many of us are also familiar with the concept of design patterns and the
value there is when discussing approaches to having commonly understood and
agreed upon words for these design patterns.

Let me also add this link here to explain that language in fact also shapes
how we think

https://www.ted.com/talks/lera_boroditsky_how_language_shapes_the_way_we_think

So I hope this video helps to understand that technical jargon isn't just
technical jargon. But I still often hear the argument that changing words
isn't really needed since it is not a big deal and there are bigger issues.
So I invite you to read this twitter thread

https://twitter.com/btanderson72/status/1279507428128718848?s=20

Now I do agree that there are bigger issues but those go beyond the scope
of this group. I do however think that offering inclusive terminology is
within the scope of this project, especially since it is very useful for us
all to agree on the same terminology.

More importantly we have come to accept a lot of very inaccurate terms for
technology that needlessly complicate things for new comers.

For example if you don't know the term "whitelist" or "blacklist" you don't
know what they mean. While black might refer to the absence of light, white
might also refer to the absence of color. As such "allowlist" or "denylist"
are simply more expressive ways to describe things. Similar master/slave
isn't as accurate as primary/replica to describe the relationship (though
of course depending on the specific context there might be even better
terms to use). So all I want to say is that if you don't agree that
technical jargon can be offensive, I hope you still agree that if we re-use
terms from non technical contexts, we should make sure that the analogy is
as self-descriptive as possible to prevent misunderstandings with new
comers or even just people we interact with as part of our work (product
owners, investors etc).

As part of the IETF there is a a document that addresses the above noted
terms:

https://tools.ietf.org/id/draft-knodel-terminology-00.html

Chromium project also has some more guidelines that cover also terms we
might commonly find in documentation or comments

https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md#racially-neutral

Now there has also been discussion about the git master branch (and yes it
is derived from master/slave
https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask?WT.mc_id=-blog-scottha#L231-L232,
though I don't think it matters much if it does or not, see above twitter
thread).

Here to it might make sense to actually recommend projects to not use
master as the default branch for “latest”

https://mikevanriel.com/2020/07/07/master-has-always-been-a-poor-branch-name/

Python has been a language and community that has already done steps in
this direction a long time ago

https://bugs.python.org/issue34605

https://github.com/django/django/pull/2692

Drupal as well https://www.drupal.org/node/2275877

Other PHP projects like PHPUnit and Doctrine, Symfony more recently

I have started a discussion about this on slack a while ago already but
would like to bring this to the list. Based on the discussion on slack
there were opinions that ranged from:

* do nothing

* agree to not use those terms in PSRs

* create a bylaw to clarify that those terms will not be used in PSRs

* create a PSR as a recommendation for a unified (and inclusive) language
used within Frameworks when it comes to naming things. (and then a bylaw to
also follow that PSR)

I believe the latter should be done. This is also a huge benefit (not only
about the currently hot debates) for PHP developers as they know how things
are named across libraries. We had a similar topic about PSR-14 "Events"
(what do people mean when they say "Events"). So the scope can be wider
than “just” inclusive language.

I also believe this topic is very much within the scope of FIG. We have
PSRs for PHPDoc naming. I once proposed a PSR for security disclosure which
got abandoned not due to a discussion about the scope but simply because
work was never pushed forward sufficiently.

We may or may not include other terms than those I mentioned above. If the
list needs to be expanded later we can always publish another PSR, just
like for PHPDoc etc.

>From what I have seen on the web, this topic tends to get incredibly
heated. As such I would ask everyone to spend a few extra minutes
formulating their replies to ensure maximum clarity. Also I would ask
readers to spend some additional time digesting responses and potentially
throttle your responses. I really hope we can have a productive discussion
here and not a shouting match.

Re: [VOTE] Core Committee Election

[Lukas Kahwe Smith]

Aloha,

Jackalope votes:

Larry Garfield
Matteo Beccati
Benni Mack
Beau Simensen
Woody Gilk
Matthew Weier O'Phinney
Adam Englander

regards,
Lukas

On Sun, May 5, 2019 at 11:48 PM Alessandro Lai
 wrote:
>
> Hello everyone,
> as specified in the previous thread 
> (https://groups.google.com/d/topic/php-fig/SSGn1VJtOJs/discussion), yesterday 
> at midnight the nominations ended, and since today it's possible to vote for 
> the renewal of the terms that are up for this elections.
>
> We have 5 spots on the Core Committee up for reelection, four with a full two 
> year term and a shorter one, that will end in August 2020, due to Lukas 
> stepping down; we also have one full-term spot for secretary.
> 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 
> seven nominations (listed in chronological order of nomination):
>
>  - Woody Gilk https://groups.google.com/d/topic/php-fig/DaoLQAiykpc/discussion
>  - Larry Garfield 
> https://groups.google.com/d/topic/php-fig/HqtrPuUI_YQ/discussion
>  - Adam Englander 
> https://groups.google.com/d/topic/php-fig/3TjKW8MmBks/discussion
>  - Matthew Weier O'Phinney 
> https://groups.google.com/d/topic/php-fig/PAnOZqE4QiQ/discussion
>  - Matteo Beccati 
> https://groups.google.com/d/topic/php-fig/Mahn59nAmbU/discussion
>  - Beau Simensen 
> https://groups.google.com/d/topic/php-fig/v1cPGmMT430/discussion
>  - Benni Mack https://groups.google.com/d/topic/php-fig/wVIhtZNVgmM/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 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 May 19th 23:59 UTC.
>
> How to vote
> The voting system used is STV[1][2], so basically, there is no tactical 
> voting possible (like with FPTP); vote for who you want, even if they are a 
> less popular candidates as your vote will move down to a different candidate 
> if you back an unpopular candidate who doesn't have enough votes; if a 
> candidate is elected, their surplus votes are also re-allocated so you are 
> not punished for backing popular candidates either. There is no quorum, you 
> are of course entitled to not vote and it will not count as a missed vote on 
> the voting sheet. Rank the candidates in order of preference for example:
>
> 1. Luke
> 2. Leia
> 3. Anakin
> 4. Rey
> 5. Padmé
> 6. Finn
>
> At the end of the voting phase I will be announcing the results, and all the 
> newly elected (both CC members and secretary), as announced before. Vote 
> ordering will be also used to assign the terms, so the last of the elected 
> will take the shorter one.
>
> Thanks!
>
> Alessandro Lai
> PHP-FIG Secretary
>
> [1]: STV User-friendly Explanation https://www.youtube.com/watch?v=l8XOZJkozfI
> [2]: https://en.wikipedia.org/wiki/Single_transferable_vote
>
> --
> You received this message because you are subscribed to the Google Groups 
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/9e1624fa-b968-43c6-923f-5d507774703e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
regards,
Lukas

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

Re: [ACCEPTANCE VOTE][CC] PSR-14 Event Dispatcher

[Lukas Kahwe Smith]

+1

On Sun, Mar 10, 2019 at 7:31 PM Cees-Jan Kiewiet  wrote:
>
> The REVIEW period for the proposed PSR-14, Event Dispatcher, hit its minimum 
> required length on 27 February 2019. We continued the period since then to 
> make sure nothing came up and some minor concerns where raised as PR, which 
> have all since been merged.
>
> At this time, I am opening an ACCEPTANCE VOTE. Per the by-laws, the  
> acceptance vote is limited to Core Committee members. The vote will close 
> either at 23:59:59 UTC on 24 March 2019, or when all CC members have cast 
> their vote, whichever comes first.
>
> The relevant materials are as follows:
>
> - Specification:  
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md
> - Metadocument:  
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md
>
> PLEASE DO NOT VOTE UNLESS YOU ARE A CC MEMBER.
> Current CC Members are as follows:
>
> Beau Simensen
> Larry Garfield
> Matthew Weier O’Phinney
> Sara Golemon
> Cees-Jan Kiewiet
> Lukas Kahwe Smith
> Samantha Quiñones
> Chris Tankersley
> Korvin Szanto
> Stefano Torresi
> Michael Cullum
> Chuck Burgess
>
>
> Cees-Jan Kiewiet, your friendly neighbourhood PSR-14 Sponsor
>
> --
> 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/b46fe9d1-0290-4b31-9629-03ffe109b709%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
regards,
Lukas

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

Re: Proposal: Adopt Code Manifesto

[Lukas Kahwe Smith]

and compassion unless they 
> abuse that trust. Make your discussions, criticisms and debates from a 
> position of respect for the humanity of all involved. Ask yourself, is it 
> true? Is it necessary? Is it constructive? Anything less is missing the mark.
> Reactions require grace. Angry responses are valid, but neither abusive 
> language nor harmful actions are acceptable. If something happens which 
> concerns you, address it directly or report it, but be respectful. Allow the 
> organizers time to discuss the incident with the offender and possibly 
> correct the issue.
> To err is human; always be iterating. You might not intend it, but mistakes 
> do happen and contribute to build experience. Tolerate honest mistakes, and 
> don't hesitate to apologize if you make one yourself. Remember, apologies are 
> hallow without also correcting the behavior.
>
>
>
> On Tue, Jan 29, 2019 at 9:06 AM Chuck Burgess  wrote:
>>
>> Looking over both the manifesto and the covenant, I didn't really notice 
>> anything that would conflict between the two, if we wanted to simply include 
>> *both*... doing so would just be presenting an intersection of their 
>> requirements.  Is that too much verbiage overall?  Maybe just link to both, 
>> since they are standalone entities (that seem to be versioned, or at least 
>> versionable)?  Stating that we want to abide by both, then delineating how 
>> those in FIG positions can act to enforce, ... maybe that would cover the 
>> concerns mentioned?
>> CRB
>> about.me/ashnazg
>>
>>
>> On Thu, Jan 24, 2019 at 7:54 AM Larry Garfield  
>> wrote:
>>>
>>> On Wed, Jan 23, 2019, at 1:58 PM, Lukas Kahwe Smith wrote:
>>> >
>>> > On Wed, 23 Jan 2019 at 20:42, Matthew Weier O'Phinney
>>> >  wrote:
>>> > >
>>> > >
>>> > > On Wed, Jan 23, 2019 at 2:49 AM Lukas Kahwe Smith 
>>> > >  wrote:
>>> > >> On Wed, Jan 23, 2019 at 1:17 AM Larry Garfield 
>>> > >>  wrote:
>>> > >>  >
>>> > >>  > Greetings, FIGians.
>>> > >>  >
>>> > >>  > This has been bounced around in back channels on and off for a 
>>> > >> while, so I think it's finally time to make it official. I propose 
>>> > >> that we officially adopt the Code Manifesto[1] as our official 
>>> > >> standard of behavior.
>>> > >>  >
>>> > >>  > Specifically, as follows:
>>> > >>  >
>>> > >>  > https://github.com/php-fig/fig-standards/pull/1143
>>> > >>  >
>>> > >>  > WHY?
>>> > >>  >
>>> > >>  > First off, I want to be clear that I am NOT making this 
>>> > >> recommendation in response to any current issue. I am not aware of any 
>>> > >> current issue that would require invoking or even discussing invoking 
>>> > >> the guidelines listed here. FIG has been delightfully boring in that 
>>> > >> regard for quite some time and, "good lord willin' and the creek don't 
>>> > >> rise", it will stay that way.
>>> > >>  >
>>> > >>  > That of course is the best time to discuss such matters, as they 
>>> > >> can be looked at from a reasonably objective and dispassionate 
>>> > >> perspective. The definition of expected behavior of current official 
>>> > >> FIG members is quite vague and wishy washy (by design), and having 
>>> > >> clearer up-front expectations is good should the need ever arise.
>>> > >>  >
>>> > >>  > WHY THE MANIFESTO?
>>> > >>  >
>>> > >>  > A number of organizations and projects have of late adopted the 
>>> > >> "Contributor Covenant" as their code of conduct. My concern with the 
>>> > >> Covenant is that it is a very negative document; in contrast, the 
>>> > >> Manifesto provides guidelines of good behavior rather than an 
>>> > >> enumeration of bad behavior. In my experience, a positive document 
>>> > >> tends to encourage the desired behavior better than a negative one.
>>> > >>
>>> > >>  We had a brief discussion on this point via IRC a few days ago. While
>>> > >>  such a document is a very small step forward, I personally think that
>>> > >>  the manifesto lack of naming probl

Re: Proposal: Adopt Code Manifesto

[Lukas Kahwe Smith]

On Wed, 23 Jan 2019 at 20:42, Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

>
>
> On Wed, Jan 23, 2019 at 2:49 AM Lukas Kahwe Smith 
> wrote:
>
>> On Wed, Jan 23, 2019 at 1:17 AM Larry Garfield 
>> wrote:
>> >
>> > Greetings, FIGians.
>> >
>> > This has been bounced around in back channels on and off for a while,
>> so I think it's finally time to make it official.  I propose that we
>> officially adopt the Code Manifesto[1] as our official standard of behavior.
>> >
>> > Specifically, as follows:
>> >
>> > https://github.com/php-fig/fig-standards/pull/1143
>> >
>> > WHY?
>> >
>> > First off, I want to be clear that I am NOT making this recommendation
>> in response to any current issue.  I am not aware of any current issue that
>> would require invoking or even discussing invoking the guidelines listed
>> here.  FIG has been delightfully boring in that regard for quite some time
>> and, "good lord willin' and the creek don't rise", it will stay that way.
>> >
>> > That of course is the best time to discuss such matters, as they can be
>> looked at from a reasonably objective and dispassionate perspective.  The
>> definition of expected behavior of current official FIG members is quite
>> vague and wishy washy (by design), and having clearer up-front expectations
>> is good should the need ever arise.
>> >
>> > WHY THE MANIFESTO?
>> >
>> > A number of organizations and projects have of late adopted the
>> "Contributor Covenant" as their code of conduct.  My concern with the
>> Covenant is that it is a very negative document; in contrast, the Manifesto
>> provides guidelines of good behavior rather than an enumeration of bad
>> behavior.  In my experience, a positive document tends to encourage the
>> desired behavior better than a negative one.
>>
>> We had a brief discussion on this point via IRC a few days ago. While
>> such a document is a very small step forward, I personally think that
>> the manifesto lack of naming problematic behavior is its biggest
>> weakness, since it does very little to assure people that you are
>> willing to name problematic behavior when it occurs, when you cannot
>> even do so in the rules you publish.
>>
>
> I tend to agree with Lukas here, and have a bit of background to share.
>
> A few years ago, Zend Framework adopted Code Manifesto to govern our
> projects, for many of the same reasons Larry has stated: we like the
> emphasis on positive guidelines of acceptable behaviour over an enumeration
> of punishments for bad behaviour.
>
> In practice, it's been problematic, for a number of reasons.
>
> When unacceptable behaviour is observed, there's no clear contact to
> report to. This leaves people either waiting and hoping somebody will step
> in, or leaving the conversation to avoid the person.
>
> Additionally, when somebody does step in (generally somebody with
> moderation rights in whichever community forum the interactions are
> occurring on), there's then questions:
>
> - What behaviour was observed? How is it against the code?
> - What direction should be provided to the user to prevent future issues?
> - Is banning necessary? If so, how long? Should it ever be permanent?
>
> Essentially, a code without an explicit process for calling out violations
> and dealing with them makes addressing problems entirely subjective and at
> the whim of those with moderation powers.
>
> In terms of reporting, reporting MUST be able to be done anonymously, to
> prevent retribution by the accused against the accuser; people who abuse
> the rules are simply more likely to retaliate. Without this, members of the
> community have no safe way to report that prevents further abuse.
>
> In sum: I love the Code Manifesto as a guideline for how people should
> interact within the community. However, it's not a code of conduct; a code
> of conduct needs to outline the specific behaviours that will trigger
> actions, how to report these safely, and what actions may be taken. These
> are required to ensure a safe and fair process.
>
for a reporting process we last year adopted this in the Symfony community
https://symfony.com/doc/current/contributing/code_of_conduct/reporting_guidelines.html

It is partially derived from the Sunshine PHP conference process, which in
turn derived it from others.

One key aspect here is also the CARE team, which also received training in
receiving reports. Now given the limited number of people that participate
with FIG, compared to the rather large number in the Symfony community, a
CARE t

Re: Proposal: Adopt Code Manifesto

[Lukas Kahwe Smith]

On Wed, Jan 23, 2019 at 1:17 AM Larry Garfield  wrote:
>
> Greetings, FIGians.
>
> This has been bounced around in back channels on and off for a while, so I 
> think it's finally time to make it official.  I propose that we officially 
> adopt the Code Manifesto[1] as our official standard of behavior.
>
> Specifically, as follows:
>
> https://github.com/php-fig/fig-standards/pull/1143
>
> WHY?
>
> First off, I want to be clear that I am NOT making this recommendation in 
> response to any current issue.  I am not aware of any current issue that 
> would require invoking or even discussing invoking the guidelines listed 
> here.  FIG has been delightfully boring in that regard for quite some time 
> and, "good lord willin' and the creek don't rise", it will stay that way.
>
> That of course is the best time to discuss such matters, as they can be 
> looked at from a reasonably objective and dispassionate perspective.  The 
> definition of expected behavior of current official FIG members is quite 
> vague and wishy washy (by design), and having clearer up-front expectations 
> is good should the need ever arise.
>
> WHY THE MANIFESTO?
>
> A number of organizations and projects have of late adopted the "Contributor 
> Covenant" as their code of conduct.  My concern with the Covenant is that it 
> is a very negative document; in contrast, the Manifesto provides guidelines 
> of good behavior rather than an enumeration of bad behavior.  In my 
> experience, a positive document tends to encourage the desired behavior 
> better than a negative one.

We had a brief discussion on this point via IRC a few days ago. While
such a document is a very small step forward, I personally think that
the manifesto lack of naming problematic behavior is its biggest
weakness, since it does very little to assure people that you are
willing to name problematic behavior when it occurs, when you cannot
even do so in the rules you publish.

regards,
Lukas

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

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

[Lukas Kahwe Smith]

+1 

regards,
Lukas

> On 21 Oct 2018, at 18:05, Larry Garfield  wrote:
> 
> +1
> 
> --Larry Garfield
> 
>> On Sunday, October 14, 2018 9:46:40 AM CDT Sara Golemon wrote:
>> The REVIEW period for the proposed PSR-18, HTTP Clients, hit its minimum
>> required length on 19 September 2018. We continued the period since then to
>> iron out additional clarifications to the specification, which have all
>> since been merged.
>> 
>> At this time, I am opening an ACCEPTANCE VOTE. Per the by-laws, the
>> acceptance vote is limited to Core Committee members. The vote will close
>> either at 23:59:59 UTC on 28 October 2018, or when all CC members have cast
>> their vote, whichever comes earlier.
>> 
>> The relevant materials are as follows:
>> 
>> - Specification:
>> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/ht
>> tp-client.md - Metadocument:
>> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/ht
>> tp-client-meta.md
>> 
>> PLEASE DO NOT VOTE UNLESS YOU ARE A CC MEMBER.
>> Current CC Members are as follows:
>> 
>> Beau Simensen
>> Larry Garfield
>> Matthew Weier O’Phinney
>> Sara Golemon
>> Cees-Jan Kiewiet
>> Lukas Kahwe Smith
>> Samantha Quiñones
>> Chris Tankersley
>> Korvin Szanto
>> Stefano Torresi
>> Michael Cullum
>> Chuck Burgess
>> 
>> -Sara
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/3316062.MSLtbGGoY2%40vulcan.
> 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/228D8791-42B2-44A0-9186-FA481071950D%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.

Re: [ENTRANCE] [VOTE] [CC] PHPDoc & PHPDoc Tags PSRs

[Lukas Kahwe Smith]

Vote 1 (PHPDoc PSR-5): Yes
Vote 2 (PHPDoc Tags PSR-19): Yes

> On 14 Sep 2018, at 19:40, Michael Cullum  wrote:
> 
> Hi all,
> 
> PSR-5 has been quiet for a long time and it's recently been revived. The next 
> step is having an entrance vote for the Core Committee. The purpose of an 
> entrance vote is to agree it's a spec the FIG agrees should be worked on and 
> start a working group, not to comment on any existing content of the 
> specifications.
> 
> The intention is to split what was PSR-5 into two separate PSRs, one for the 
> PHPDoc format, and another to define a tag catalog. There will therefore be 
> two votes. The rationale behind the splitting is to make it easier to add new 
> tag dictionary PSRs in the future and also make PHPDoc more generic so it can 
> be used for non-docblock standard such as Doctrine-style annotations.
> 
> Vote 1:
> PHPDoc (PSR-5) - 
> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-meta.md
> 
> Vote 2:
> PHPDoc Tags (would become PSR-19) - 
> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags-meta.md
> 
> Working group for both PSRs:
> Editor: Chuck Burgess - PEAR
> Sponsor: Michael Cullum - PHP-FIG
> Alexey Gopachenko - PhpStorm
> Matthew Brown - Psalm
> Ondrej Mirtes - PHPStan
> 
> 
> Please when voting specify votes for both for example:
> 
> Vote 1 (PHPDoc PSR-5): Yes
> Vote 2 (PHPDoc Tags PSR-19): Yes
> 
> 
> Please do not reply to this topic if you are not a CC member.
> 
> --
> 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 
> <mailto:php-fig+unsubscr...@googlegroups.com>.
> To post to this group, send email to php-fig@googlegroups.com 
> <mailto:php-fig@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/3cc1f7f8-97be-4c8d-9b29-353aa3365b35%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/php-fig/3cc1f7f8-97be-4c8d-9b29-353aa3365b35%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/4F7B1990-82CA-469B-9F34-25617F99984C%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Secretary Elections - Voting is Now!

[Lukas Kahwe Smith]

Jackalope votes

> On 4 Aug 2018, at 18:36, Dead Lugosi  wrote:
> 
> Alessandro Lai
> Daniyal Hamid

PS: Not sure if I am still/also eligible to vote as a CC member?

-- 
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/BAB6F26B-974A-40C5-9B4B-1158F49B3F1A%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.

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

[Lukas Kahwe Smith]

+1

> On 09 Apr 2018, at 06:01, Larry Garfield <la...@garfieldtech.com> wrote:
> 
> I  hereby call an Entrance Vote to restart PSR-14, Event Dispatcher.
> 
> The proposed working group is as follows:
> 
> Editor:  Larry Garfield
> 
> Sponsor: Cees-Jan Kiewiet
> 
> Other Group Members:
> 
> Elizabeth Smith
> Benjamin Mack
> Matthew Weier O'Phinney
> Ryan Weaver
> 
> The revised scope and charter is in this PR:
> 
> https://github.com/php-fig/fig-standards/pull/1016
> 
> This is an Entrance Vote only, so it's a vote to say "yes, we should have one"
> rather than a statement on any particular implementation detail.
> 
> This vote is open to Core Committee members only.  Everyone else, please hold
> your horses. :-)  Please give a +1/-1.  The vote is open until 23 April or
> until all 11 CC members have voted, whichever comes first.
> 
> --Larry Garfield
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/5365608.7dg2KeOeTa%40vulcan.
> For more options, visit https://groups.google.com/d/optout.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/EA9353F5-3AD5-4B4F-BD78-7ED3A44CAF13%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PSR-6][Errata][Vote]

[Lukas Kahwe Smith]

+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/010817de-0a4f-4039-a236-a4bcbb046eac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Lukas Kahwe Smith]

+1

assuming this is about 
https://github.com/php-fig/fig-standards/tree/master/proposed/http-factory

> On 05 Feb 2018, at 19:22, Matthew Weier O'Phinney <mweierophin...@gmail.com> 
> wrote:
> 
> Last year, in May, I opened a discussion period regarding the PSR-17
> working group, as the proposal pre-dated the latest by-laws... and
> then evidently forgot to open a vote for it.
> 
> So, I'm opening a vote as of today, 2018-02-05. Per the by-laws, this
> vote is for Core Committee members only, and will run until all
> members have voted, or 23:59:59 on 2018-02-19, whichever occurs
> soonest.
> 
> The proposed working group is as follows:
> 
> - Editor: Woody Gilk
> - Sponsor: myself
> - Members: Stefano Torresi, Matthieu Napoli, Korvin Szanto, Glenn
> Eggleton, Oscar Otero, and Tobias Nyholm.
> 
> --
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/CAJp_myWaxDJ9biQvWjiSVoZ%2Brga%3DLVt99jE20c0jbYvxBLBL0A%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/D7381430-1180-441C-A4A6-C1BD9EB9AD48%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Lukas Kahwe Smith]

+1 Lukas Kahwe Smith

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

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/2AAAC3FD-D46E-467A-8036-89EACD413B66%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New Secretaries

[Lukas Kahwe Smith]

> On 12 Nov 2017, at 17:45, Michael Cullum <m...@michaelcullum.com> wrote:
> 
> Hi all,
> 
> I can formally announce the two new secretary candidates are:
> Margret (Term until May 2019)
> Alessandro (Term until August 2018)
> The threshold was 7 votes, and they received 11 and 9 votes respectively.
> As they both met the threshold in the first round there were no surplus votes 
> to be re-distributed.
> 
> Thanks to all the candidates standing and I look forward to working with you 
> both Alessandro and Margret!

Indeed, looking forward to your terms Margret and Alessandro!
Furthermore thank you Mark for stepping up for the vote and hope you are not 
too disappointed.
There are plenty of other opportunities to support FIG and any work will be 
highly appreciated.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/13B4CB9E-6213-45C4-8F81-6B4D1F4A1609%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Should new PSRs support PHP5?

[Lukas Kahwe Smith]

> On 28 Oct 2017, at 20:23, Oscar Otero  wrote:
> 
> 
> Ok, I see.
> Could this be solved with php 7.2, that implements parameter type widening? 
> (https://wiki.php.net/rfc/parameter-no-type-variance)
> So we can keep releasing interfaces compatible with php5 and in a short 
> future release the v2.0 compatible with php ^7.2.
> I think that this feature was added specially for things like this.
> 
>> El 28 oct 2017, a las 19:54, Michael Cullum  
>> escribió:
>> 
>> Oscar,
>> 
>> This was discussed on Slack however those there agreed it didn't make sense 
>> to do releasing new version of the interface for each PHP version.
>> 
>> The reason being as then you have a client application that has one library 
>> requiring one version, and another library requiring another version which 
>> would be incompatible with each other.
>> 
>> Implementing libs also couldn't support both 1.x and 2.x if they support PHP 
>> 7 as you can't leave out the type declaration of extending an interface, and 
>> having it in PHP 5 will throw an error. So implementing libs would require 
>> 1.x or 2.x but never both causing the above issue in client applications.

I also brought this up, not because I am not aware that this can lead to messy 
situations but in order to give one less reason not to support return type 
hinting in new specs.

Finishing a PSR and getting it into libs and then integrated into frameworks in 
a stable release takes long enough. Lets not end up in a situation where PSR 
compliance means being 1-2 PHP versions behind in terms of features.

In this spirit I propose to always allow (maybe even mandate) using the latest 
PHP versions in PSRs. As well as encouraging updating existing PSRs (though 
maybe not necessarily for every PHP release with relevant new features ..). For 
the most part we are only affected by things that impact interfaces (ie. new 
type hinting, new classes etc), 

regards,
Lukas

-- 
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/B270E5FC-1646-4C9C-8B6F-2CF0928E15B4%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] Secretary Election

[Lukas Kahwe Smith]

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

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

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/04B21174-FD98-4B0A-9D3B-66B44BC8F30C%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Lukas Kahwe Smith]

+1 from Jackalope

> On 20 Oct 2017, at 11:06, Jan Schneider <j...@horde.org> wrote:
> 
> +1 from Horde
> 
> Zitat von Korvin Szanto <korvinsza...@gmail.com 
> <mailto:korvinsza...@gmail.com>>:
> 
>> Hi Everyone,
>> PSR-12 was already accepted and assigned the number 12 back in FIG 2.0[0], 
>> however, it turns out that my post on the 30th of June[1] was way too late 
>> to qualify as a grandfathered recommendation. So in order to make sure we 
>> follow the process properly, we're holding an entrance vote and asking 
>> kindly that the CC allows us to keep the number 12.
>> 
>> Our working group is as follows:
>> 
>> Editor:
>> Korvin Szanto
>> 
>> Sponsor:
>> Chris Tankersley
>> 
>> Working Group Members:
>> Alexander Makarov
>> Michael Cullum
>> Robert Deutz
>> 
>> 
>> If you'd like to read more about PSR-12, check out the completed draft[2] 
>> and the meta document[3] but please keep in mind that we are not voting on 
>> the content of this draft.
>> 
>> Thank you for your time!
>> Korvin Szanto
>> 
>> [0]: https://groups.google.com/d/msg/php-fig/P9atZLOcUBM/_jwkvlYKEAAJ
>> [1]: https://groups.google.com/d/msg/php-fig/iqLzVvj6C2c/2hEOAQFbAAAJ
>> [2]: 
>> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md
>> [3]: 
>> https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to php-fig+unsubscr...@googlegroups.com 
>> <mailto:php-fig+unsubscr...@googlegroups.com>.
>> To post to this group, send email to php-fig@googlegroups.com 
>> <mailto:php-fig@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/09e35685-1488-45f7-96ee-14b5265cdfd1%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/php-fig/09e35685-1488-45f7-96ee-14b5265cdfd1%40googlegroups.com?utm_medium=email_source=footer>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
>> 
> 
> 
> Jan Schneider
> The Horde Project
> https://www.horde.org/ <https://www.horde.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 
> <mailto:php-fig+unsubscr...@googlegroups.com>.
> To post to this group, send email to php-fig@googlegroups.com 
> <mailto:php-fig@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/20171020090646.Horde.MlcHA8GiOPhUbwYKnHwCy3a%40neo.fritz.box
>  
> <https://groups.google.com/d/msgid/php-fig/20171020090646.Horde.MlcHA8GiOPhUbwYKnHwCy3a%40neo.fritz.box?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/18CE72EC-CB7C-4925-B619-4776983E720E%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE][CC] Entrance vote for HTTP Client

[Lukas Kahwe Smith]

+1

> On 03 Aug 2017, at 17:03, Sara Golemon <p...@golemon.com> wrote:
> 
> Per http://www.php-fig.org/bylaws/psr-workflow/ This is the entrance vote for 
> the HTTP Client PSR Discussion
> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
> 
> Sponsor: Sara Golemon
> Editor: Tobias Nyholm
> 
> Thanks to PSR-7 we know how HTTP requests and responses ideally look like, 
> but nothing defines how a request should be sent and a response received. A 
> common interface for HTTP client will allow libraries to be decoupled from an 
> implementation such as Guzzle.
> 
> Voting opens 2017 Aug 3 at 16:00 UTC
> Voting Closes 2017 Aug 17 at 16:00 UTC
> 
> Per http://www.php-fig.org/bylaws/voting-protocol/#entrance-vote this vote is 
> for Core Committee members to approve or reject the discussion phase of this 
> proposed PSR.
> 
> -Sara
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to php-fig+unsubscr...@googlegroups.com 
> <mailto:php-fig+unsubscr...@googlegroups.com>.
> To post to this group, send email to php-fig@googlegroups.com 
> <mailto:php-fig@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/bc288330-b520-4248-b8fb-588e6fd5de09%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/php-fig/bc288330-b520-4248-b8fb-588e6fd5de09%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/310F2EAB-AAE8-4D91-9173-171D0FBB8CBA%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Lukas Kahwe Smith]

+1 from Jackalope

> On 06 Feb 2017, at 17:54, Chris Tankersley <ch...@ctankersley.com> wrote:
> 
> It's been well past 2 weeks while having a discussion period on allowing 
> Phergie as a member project, and here is the voting thread for Core Committee.
> 
> Please vote with a -1/0/+1, like normal.
> 
> Discussion Thread: 
> https://groups.google.com/forum/?!topic%2Fphp-fig%2Fbz9sr8q8yHI#!topic/php-fig/bz9sr8q8yHI
>  
> <https://groups.google.com/forum/?!topic%2Fphp-fig%2Fbz9sr8q8yHI#!topic/php-fig/bz9sr8q8yHI>
> 
> There is a separate thread for the Member Projects
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to php-fig+unsubscr...@googlegroups.com 
> <mailto:php-fig+unsubscr...@googlegroups.com>.
> To post to this group, send email to php-fig@googlegroups.com 
> <mailto:php-fig@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/6c57f47b-bca3-47e8-bff8-922ab22dd4b5%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/php-fig/6c57f47b-bca3-47e8-bff8-922ab22dd4b5%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/24CFB849-1BE8-4D78-BFF5-20134BDC4CEB%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Lukas Kahwe Smith]

+1 from Jackalope

regards,
Lukas

> On 23 Dec 2016, at 21:24, Fabien Potencier  wrote:
> 
> +1 Symfony
> 
>> On 12/23/16 20:42, Cees-Jan Kiewiet wrote:
>> +1 from ReactPHP
>> 
>> On Fri, Dec 23, 2016 at 4:38 PM, Leo Feyer > > wrote:
>> 
>>+1 from Contao
>> 
>>--
>>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/494056BF-4687-4BF6-9BEE-DD0812221284%40contao.org
>>
>> .
>>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/CAPY1sU-C9qfFcbu%3DmNZ5_0YzuVLPomc9Q2Q-7Lj%3DgXAL3wsXxw%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/66a68821-61f9-80c9-c2cd-f2ed33f97130%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/63E59600-8D41-45A1-8CA2-A904B7427A64%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] First Core Committee Elections

[Lukas Kahwe Smith]

>From Jackalope:

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

regards,
Lukas

PS: Thank you for assembling the nomination topics link!

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

[CC][About Candidate] Lukas Kahwe Smith

[Lukas Kahwe Smith]

Aloha,

History:
I become involved actively in the Open Source world and more specifically PHP 
world when I attended the PHP Conference in Frankfurt in 2001 (or maybe 2002?) 
to meet with Manuel Lemos to discuss some improvements to Metabase. Shortly 
thereafter he suggested that I work with the PEAR group to merge PEAR DB with 
Metabase, which became MDB .. this was later then forked as the basis of 
Doctrine DBAL. With joining PEAR I become quite involved with the organization 
and was part of the initial people on the PEAR Group.

This in turn got me closer to PHP internals, where I started to maintain a list 
of “planned tasks” for the next PHP release on my personal wiki. I also was 
part of a group of people that was exploring how to best go about bringing DB 
abstraction features to PHP core, which has some influence on PDO. I was later 
proposed to join Johannes Schlüter as co-RM for PHP 5.3. In this capacity, I 
documented the PHP release process, initiated the RFC process, setup 
wiki.php.net.

I then moved on to focus more on userland code. Specifically getting involved 
in Doctrine and Symfony as well as the PHPCR initiative to bring an 
implementation independent API for managing semi-structured content for CMS to 
the PHP world. As a result I maintain close relationships with many developers 
in various CMS communities (like Drupal, ezPublish, NeoCMS, TypoCMS, Contao etc 
..). Furthermore I even have commit access on Zend Framework as I merged code 
from the LiipMonitor into ZF Diagnostics.

For a while I was one of the more actively people in the community (f.e. I was 
in the top 50 of github users for an extended period) but I have slowed down my 
activity quite a bit recently. Partly also because I have become increasingly 
interested in “softer” topics like self organization. I still however maintain 
quite a few projects and since Liip, the company I work at, is now self 
management I am increasing my coding activities again.

I have been involved with PHP-FIG since many years. I initiated PSR-9 and 
PSR-10 (related to security vulnerability standards for PHP projects) though I 
didn’t bring either of them to a final state mostly due to lack of time. In 
fact in the past 1 year I have probably mostly only done the occasional post to 
try and calm tensions within the group and less so on technical topics. That 
being said, I did take my voting responsibility seriously as representative of 
Jackalope (the reference implementation of PHPCR) and spend time reading the 
relevant proposals before voting.

My stance on PHP-FIG:
In general I would say when in doubt I prefer collaboration over separate 
implementations though I very much agree that alternative implementations do 
make sense at times, which is why I very much appreciate PHP-FIGs focus on 
interfaces and other high level standards that aid in making it easy to use and 
replace code rather than forcing island solutions and separation of the PHP 
community.

What I intend to do on the CC:
I will likely remain not being one of the most active contributors but I will 
also make sure that I always fulfill by duties to vote based on due diligence 
research. I believe I have built quite a bit of trust in the PHP community as a 
person that is able to remain “objective” even in a heated debate and is able 
to build bridges (*). I also believe that I have quite a bit of experience in 
the historical context of PHP as well as in how to design interfaces. More over 
I think I am quite good at seeing the positive potential of new ideas and 
constructively working towards resolving potential issues.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

(*) Disclaimers:
I did have a pretty hard falling out with Matthew on an argument related to 
Apigility which afaik let to him blocking me on Twitter, which is unfortunate 
but I hold no hard feelings towards ZF as a result (as stated above I even have 
contributed to ZF, even after this happened). My relationship to Matthew is 
however as a result I would say our personal relationship is “strained” but I 
believe I (and I also think he) can work effectively together within PHP-FIG 
without issues and have done so in the past.

Further disclaimers: I am part of the Symfony core team and I am co-founder of 
Symfony CMF. I also have commit access to wide parts of Doctrine (last I 
checked at least).

-- 
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/809C6EDF-0A4F-49F6-9ADB-E78F15140A48%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CC][Nomination] Lukas Kahwe Smith

[Lukas Kahwe Smith]

> On 10 Nov 2016, at 01:13, Fabien Potencier <fabien.potenc...@gmail.com> wrote:
> 
> I hereby nominate Lukas Smith for the Core Committee. Lukas has a great 
> experience talking to different communities, and he was key to some great 
> collaborations between PHP projects. He was also one of the people who helped 
> change the PHP development process a few years back.
> 
> I'm sure he would do a wonderful job as a member of the Core Committee.

Thank you for the nomination. I accept

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

PS: I am going on vacation starting today until November 22nd. I will likely 
read my emails off and on.

-- 
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/21E99BB1-E38F-40FA-8E60-48A593C00B46%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE][Accept] PSR-13: Link Definition Interfaces

[Lukas Kahwe Smith]

+1 from Jackalope

> On 31 Oct 2016, at 22:15, Matthew Weier O'Phinney <mweierophin...@gmail.com> 
> wrote:
> 
> Per the by-laws, the required review period has passed for the
> proposed standard PSR-13 (Link Definition Interfaces). No changes have
> been made in the past two weeks since re-opening the review period.
> 
> The specification is here:
> 
> - 
> https://github.com/php-fig/fig-standards/blob/a47c644f9d0f914bb0a9777eeaec157f2d51dbff/proposed/links.md
> 
> And the meta document is here:
> 
> - 
> https://github.com/php-fig/fig-standards/blob/a47c644f9d0f914bb0a9777eeaec157f2d51dbff/proposed/links-meta.md
> 
> As coordinator, as of 21:20 UTC, I hereby open voting to accept the
> proposed standard.
> 
> There are currently 37 voting member projects, which means we must
> have 13 votes to pass quorum, with half or more of all votes cast in
> favor, in order to approve acceptance of PSR-13.
> 
> --
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/CAJp_myXK4gb9b4%2Bph4Oac979bW0RpCDy5HbC4e70ght5xeeFcQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/DC6E2549-DF68-4420-BCD8-2A153AF965CF%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Lukas Kahwe Smith]

Jackalope remains

> On 03 Oct 2016, at 01:43, Michael Cullum <m...@michaelcullum.com> 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 
> <mailto:php-fig+unsubscr...@googlegroups.com>.
> To post to this group, send email to php-fig@googlegroups.com 
> <mailto:php-fig@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/CAAqcDMhL7F2PGfKoASNUDAFuLe3LcRUYYOyp7T-UfqVdQWoFpA%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/php-fig/CAAqcDMhL7F2PGfKoASNUDAFuLe3LcRUYYOyp7T-UfqVdQWoFpA%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/AB0E000C-EF32-4C59-8198-ECDD8DC07C48%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Lukas Kahwe Smith]

-1 from Jackalope

regards,
Lukas

> On 04 Sep 2016, at 18:26, 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.ly/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/CAAqcDMh4JSN1Opsiam8GgjXc1vsTfSuFJ7fEJvtoRoxBxRv_xQ%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/31A59149-B2EC-43F3-86E2-36FC5842DAB4%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.

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

[Lukas Kahwe Smith]

tl;dr

the bulk of the community doesn’t care about our by-laws, they are about PSRs, 
so to the community “disbanding” FIG will just be confusion about why suddenly 
PSRs would live on another site/github repo ..

> A clean slate. Green fields. Adopt the the work that FIG has completed and 
> start fresh with fresh and old faces with a new mission statement. FIG 3.0 is 
> a major refactor where the points I've tried to make in this thread are 1: 
> Maybe it's time to call FIG complete and 2: FIG is still active, but the work 
> it's doing doesn't really seem to fit the "Framework" portion of the mission. 
> 3: A new organization solves many problems.


"it's time to call FIG complete"

actually I very much disagree. saying this would imply that there isn’t 
anything that could sensibly be done based on the old mission statement, let 
alone any new mission statement.

also from the “community” perspective the difference between FIG 1.0, 2.0 and 
3.0 don’t matter much. the evolution away from "just” framework to more was one 
driven by the community more so than by us I would say. as such arguing that 
3.0 is for some reason a too big a change seems entirely arbitrary and will 
lead to confusion in the community which will affect thousands of developers.

the issues regarding the definition of who we are and how to proceed are, if 
they are even so fundamental, only on this mailing list and maybe some reddit 
threads. but the general community isn’t pondering our mission statements, they 
are looking at the PSRs that come out and not how they were crafted.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/C3C4EED8-3109-4FE8-819D-B868D3C66B83%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] PSR-6 Errata

[Lukas Kahwe Smith]

-1 from Jackalope

not sure here what to do .. feels a bit like a precedent .. its a clear 
omission, yet any fix is a BC break (classic bug fix is kinda always a BC 
break). so if we do a BC break, then rather the exception .. if we don’t want 
to break BC, we release a new PSR with this fix (since just versioning the PSR 
to 6.1 isn’t’ semver for a BC break)?

> On 19 Aug 2016, at 20:43, Larry Garfield <la...@garfieldtech.com> wrote:
> 
> I hereby open a vote for the following Errata for PSR-6:
> 
> https://github.com/php-fig/fig-standards/pull/787
> 
> Basically, it's a vote to merge that PR.
> 
> The vote will be open for 2 weeks, closing on 2 September 2016 @ 23:59 UTC.
> 
> As usual, the vote is open to voting representatives only and is a simple 
> +1/-1 vote.
> 
> I definitely appreciate the point that an InvalidArgumentException would have 
> been better, and had this issue been brought up during the Review phase I'd 
> probably have gone that direction.  However, adding an exception does count 
> as an API change, albeit a small one, so I am not comfortable with that 
> direction in an Errata. (Obviously if you feel that this is a bad decision, 
> vote -1.)
> 
> --Larry Garfield
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/e9508662-70c7-e91a-05ff-82c8dfb59884%40garfieldtech.com.
> For more options, visit https://groups.google.com/d/optout.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/C95AF2E1-97F8-4697-86CE-C076FF6467C8%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

[Lukas Kahwe Smith]

> On 21 Aug 2016, at 22:28, Matthieu Napoli <matth...@mnapoli.fr> wrote:
> 
> I agree in so far that we need to acknowledge that there will be PSRs 
> superseding previous PSRs and there will be PSRs that are incompatible to 
> previous PSRs.
> 
> Hi Lukas, could you explain what incompatibilities you see?
> 
> Just to be clear there is no plan to change any existing PSR. And there is no 
> plan to replace them with new PSRs that adopt the new convention.
> And if a new PSR depends on another currently existing PSR, it will use the 
> existing names, not new (non-existing) ones. Example: PSR-15 should use 
> `RequestInterface`, it shouldn't use `Request` just because of the new 
> convention (because obviously it will not work: the interface does not exist 
> under that name).
> The goal is not to break anything, if you see such a scenario let's discuss 
> it.

it was a general comment in reply to your general comment that past decision 
should not prevent is from doing something different in the future.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/4780D36D-7FA1-4ED6-B367-C78F65E63F05%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

[Lukas Kahwe Smith]

> On 21 Aug 2016, at 22:07, Matthieu Napoli <matth...@mnapoli.fr> wrote:
> 
> The question of consistency with existing PSRs has been raised a lot. I don't 
> see that as a problem.
> It's OK to move forward and change a convention if we want to, each PSR is 
> independent from the rest. Consistency for this is a very small detail 
> compared to developer experience, we shouldn't limit improvements for no 
> tangible reason.

I agree in so far that we need to acknowledge that there will be PSRs 
superseding previous PSRs and there will be PSRs that are incompatible to 
previous PSRs.
But overall I have not seen any significant arguments from either side that 
would sway me in either direction and as such I would stick with the status quo.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/B32229E2-A372-4ED9-9596-727E61A2881B%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: A message from the Zend Framework CR team

[Lukas Kahwe Smith]

> On 02 Aug 2016, at 13:10, Matteo Beccati <mat...@beccati.com> wrote:
> 
> Hi Gary,
> 
> On 01/08/2016 17:50, GeeH wrote:
>> It was agreed as a group, that voting +1 for the replacement of Paul was
>> inherently pointless, as removing Paul as the voting representative is a
>> moot action resulting in no perceptible change to the situation. As
>> Matthew was one of the public complainants, it should be obvious that as
>> a team we still feel that there was a problem with Paul's behaviour. In
>> effect, we disagree with Paul's expulsion as a voting representative,
>> but still feel there is a problematic situation on the mailing list. We
>> also believe that expelling someone should be a last resort when
>> mediation has failed and that while mediation was attempted, it was not
>> done in a meaningful way with clear goals.
> 
> I was planning to write an email to explain the reasons behind my vote, but I 
> couldn't have found better words to express my own feelings about it.

I also agree with this post.

To me its important that anyone on this list does not see the -1 from Jackalope 
on the expulsion vote is considered an endorsement with Paul’s discussion 
style. I have already contacted him before when I wanted to give him concrete 
feedback. At this point I have not gotten the feeling that Paul is 
acknowledging that there is a problem. I do think that in the end it will 
require all sides making a step towards each other building trust and building 
at least a base line in etiquette. At the same time I feel like its on Paul to 
clearly communicate that he even cares. I think the “other side” has made it 
clear that they would prefer mediation over expulsion and I think Paul has so 
far not shown any willingness to adjust his behavior regardless of offlist or 
onlist discussions on this topic, so I understand the frustration that led to 
expulsion vote. There Paul imho rather than mend fences favored to fuel the 
fire once again. If this was done intentionally or not I cannot tell.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/E76F7D3F-D0C7-4D8F-A3C8-4AF0E17BE3C4%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Internal] [Discussion] Paul M Jones

[Lukas Kahwe Smith]

> On 21 Jul 2016, at 08:07, 'scott molinari' via PHP Framework Interoperability 
> Group <php-fig@googlegroups.com> wrote:
> 
> > No, I made an objective observation about a group but in the interest of 
> > being productive I will reword:
> 
> The comment about ineptness isn't objective. It is subjective, because it is 
> based on an opinion.
> 
> >"The leadership, whom appears to be the secretaries and or voting members of 
> >this community appear to be inept."
> 
> This is still an insult. How about just removing the insulting stuff from 
> your post? It simply isn't needed. Without it, your post is actually quite 
> good.

In this spirit a golden rule of criticism:
Critique the action, not the person.

ie. don’t call a group of people inept, focus on a specific action that they 
did which you feel is worthy of critique.

These are the types of things I would write into a netiquette but probably is 
too fuzzy for a CoC.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/E678A60B-0DD5-4388-93DC-E6AE6E3FE3C5%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Membership Application: pimcore

[Lukas Kahwe Smith]

+1 from Jackalope (I am not sure if I am allowed to vote as the sponsor for the 
application)

> On 18 Jul 2016, at 16:02, Michiel Rook <michiel.r...@gmail.com> wrote:
> 
> +1 from Phing
> 
> On 18-07-16 16:00, Lukas Kahwe Smith wrote:
>> Aloha,
>> 
>> So given that there didn’t see to be any opposition (then again also no 
>> support by-side me) for the adoption of pimcore in the original thread 
>> requesting for addition to the member list, I am not calling for a formal 
>> vote on the matter. The intended representative is Bernhard Rusch who is 
>> part of the core team.
>> 
>> Voting members only, just +1/-1/abstain please.
>> 
>> For reference here is the link to said original thread:
>> https://groups.google.com/d/msg/php-fig/7qcqblUe2hk/Gtl_0gG1EgAJ
>> 
>> regards,
>> Lukas Kahwe Smith
>> sm...@pooteeweet.org
>> 
>> PS: Here for quick reference the initial email:
>> 
>> Hi,
>> 
>> I would like to submit my application for membership on behalf of Pimcore.
>> Pimcore is an open source CMF for building highly customized websites and 
>> applications.
>> 
>> Link: http://pimcore.org/
>> On Github: https://github.com/pimcore/pimcore
>> 
>> A little bit about myself: My name is Bernhard Rusch, I'm working with PHP 
>> since 14 years and worked with many different products and frameworks during 
>> that time, mainly in the area of content management and ecommerce.
>> We started pimcore 6 years ago with the mission to make enterprise web 
>> content management easier for developers and editors.
>> 
>> Thank you for your consideration.
>> 
>> Bernhard Rusch
>> https://github.com/brusch
>> 
>> 
>> 
> 
> 
> --
> 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/578CE163.4080001%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/A10CF071-1BD5-454A-BEFB-1D8F0F48747D%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Internal] [Discussion] Paul M Jones

[Lukas Kahwe Smith]

regards,
Lukas
> On 09 Jul 2016, at 09:52, 'scott molinari' via PHP Framework Interoperability 
> Group  wrote:
> 
> On Saturday, July 9, 2016 at 1:30:03 AM UTC+2, Christopher Pitt wrote:
>> 
>>> Finally, to the complainants: you wanted to hang me, so start tying the 
>>> noose and call the vote. 
>> That is uncalled for. Asking for something to be addressed/discussed is in 
>> no way a desire to hang you. This statement does nothing but appear to 
>> vilify folks obviously seeking some kind of mediation with you.
> 
> That seems to be a perfect example of the problem. It is a personal comment 
> and unnecessary. 

Indeed you are right. Paul's choice of "courtroom wording", leading up to the 
lynch mob "hang me" phrase versus the statements at the start of the thread 
stated they will vote yes to an expulsion vote. 

> I hate to say it, but this thread, in effect, is a lynch mob. So Paul's "tie 
> the noose" comment is actually in line with the situation. This activity is 
> basically wrong from a civil standpoint. Unless the "law" says what Paul has 
> done is wrong, it is only dissatisfaction in Paul's person and nothing else 
> and people should actually either make the necessary changes to show, rule on 
> and punish the incivility, or live with it.  

Quite honestly, I have not seen a CoC that would cover what is currently being 
discussed to a degree of certainty sufficient to have a clear guide line how to 
react. In the end this boils down to being able and willing to compromise, 
adapt on both sides. But as stated before expulsion imho is not a solution, 
especially for a standards body (I would maybe have a different POV for an 
library/framework/application open source project).

regards,
Lukas

-- 
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/78FB52BA-52A1-458C-8772-7D03762E6BFF%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.

Re: [Internal] [Discussion] Paul M Jones

[Lukas Kahwe Smith]

> On 06 Jul 2016, at 20:35, Glenn Eggleton <geggl...@gmail.com> wrote:
> 
> On Wednesday, July 6, 2016 at 1:25:40 PM UTC-4, Larry Garfield wrote:
> On 07/05/2016 12:57 PM, Paul Jones wrote:
> > Dear Voting Representatives,
> 
> *snip*
> 
> > As such, you can see that the complaint appeals to only one portion of "the 
> > PHP Community" -- perhaps a portion with which the complainants themselves 
> > identify. But there is another substantial portion, maybe as much as half, 
> > to whom the complaint does not appeal. This, along with the comments of 
> > those who see little-to-nothing objectionable revealed by the evidence 
> > raised against me, should give you reason enough to vote *against* my 
> > removal.
> 
> *snip*
> 
> > With that, I leave the fate of my status as a Voting Representative in your 
> > hands. Regardless of the result, I thank you for your time and attention.
> 
> Paul, while I am glad you finally responded I find your response
> extremely disappointing.
> 
> Let's take your own numbers at face value: 70-ish people expressing an
> opinion, split roughly half and half on whether your behavior is
> problematic and detrimental to FIG.
> 
> Your response to that is to say "well, only 50% of people hate me and
> they're probably all of a kind, so you shouldn't vote for my removal."
> 
> Can you elaborate on this. Not once did I see that in his post. I believe 
> this might be what you are interpreting and not actually what was said.
> What I saw was Paul reiterating what he believes are the facts presented 
> against him and some really bad napkin math.

I also did not see anywhere in Paul’s post any consideration given that any 
behavior change would be considered by him. So I agree with Larry’s summary 
though I think the word “hate” is misplaced. I surely hope that nobody takes 
any of this seriously enough that they would get to a point where they would 
“hate” someone.

> I would love for the secretaries to explain their process and how they came 
> to the decision to make these complaints public was made.
> I did not see any section as to where they attempted to resolve this directly 
> with Paul [I hope that some attempt was made?]
> 
> If an attempt was made to reach out to Paul and he ignored it then this seems 
> like an adequate escalation step... but otherwise it was a really poor choice.
> 
> I apologize for making some assumptions, but there has been a lack of 
> information about the process of how things were done, and I am really only 
> interested in the facts.
> 
> The facts as I see it currently:
> 
> 1) Secretaries have received complains about Paul
> 2) Secretaries have decided to call for a vote regarding Paul to address the 
> complaints.
> 
> It seems quite inadequate, and likely incorrect. I would appreciate it if 
> someone with more knowledge can fill in the blanks.

I confirmed with Michael before I did the first post in this thread that 
according to him offlist attempts at resolving this was in fact made. I stated 
this with the first post in this thread. I repeated this once more when someone 
else wondered about the same thing and Angie mentioned it again in our post 
today that this has been confirmed by me via Michael (though it was not 
confirmed by Paul who might have a different point of view).

I saw several posts that either assumed no such attempt was made or were unsure 
if it was done. Short of creating an FAQ for this thread I am unsure how we can 
ensure that such vital information is known to every one engaging in this 
thread.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/45F9CFDD-C7F8-4E70-AE3A-5C4479333109%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: I resign

[Lukas Kahwe Smith]

> On 27 Jun 2016, at 16:01, Michiel Rook <michiel.r...@gmail.com> wrote:
> 
>> If this situation is not resolved appropriately, I worry that FIG will
> be lose the respect of the PHP community at large.
> 
> Assuming that hasn't happened already, all this drama definitely will do
> just that.

Well, of course FIG is already known for its drama. But so is php-src. its not 
good but so it goes.

But just as php-src, FIG has continued to release PSR’s which have been adopted 
quickly by many projects.
So yes there could be less politics talk, less drama, more productivity to be 
able to release PSR’s quicker .. but lets also not make this group smaller than 
it is ..

for all its faults, FIG is very important for PHP!

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/7EE63F5D-4B0D-4297-8C32-F87EF7BD91EA%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Internal] [Discussion] Paul M Jones

[Lukas Kahwe Smith]

Hello,

First up I am not in favor of expulsion because even if you agree that Paul is 
“toxic”, I doubt that a standards committee will really remain relevant if it 
cannot deal with supposedly “toxic” people, ie. we would need to find other 
solutions for this. Also even if he is no longer a member of FIG, would he then 
get banned from all list?

Now I do agree that Paul’s communication style is collides with the discussion 
style with the vast majority of the rest of the members and observers. Which in 
turn leads to frustration and as stated people leaving FIG. And this is clearly 
not good.

I would urge (and have done so already in the past) that Paul (and anyone else) 
attempt to deal with “politics” or “administrative” concerns in a bilateral 
fashion first before launching a discussion thread here. As such the first 
thing I did when I read the original post was the ask Michael if there were 
off-list attempts as resolving or at least improving the situation. it seems 
there has been, which I appreciate quite a lot.

Now I of course do not mean that we need to play shadow politics by lots of 
off-list lobbying but minor issues (like the not counting of the vote) imho 
could have probably be solved by a direct message to one of the secretaries, 
they could have then posted a single message apologizing (potentially noting 
who informed them) and we would have saved all of us 30+ increasingly 
aggressive messages.

I would also urge Paul to invest a bit of time in reviewing his messages for 
simple courtesy and more actively self-throttle (it is sad that the secretaries 
need to threaten with temporary bans when people do not follow this, but I fear 
its necessary as a way to train proper behavior). I know this is a technical 
committee, we are not here to become best friends. But we are also humans who 
do not get paid to be here that are motivated to make the PHP world a better 
place but also have lots of other places we could invest our energy into. I 
have given Paul examples of this in a previous off-list exchange already. In 
the same way I also urge people to work towards accepting Paul as someone that 
communicates on a very technical and abstract level. he is driven by 
technology, not by making other people lives miserable.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.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/54601395-79A9-4247-94F7-7D1B6F6F80CA%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail