Potential changes to Event Loop PSR line-up

121 views
Skip to first unread message

Christopher Pitt

unread,
Nov 23, 2015, 2:35:07 PM11/23/15
to PHP Framework Interoperability Group
Hello,

Following Icicle joining FIG, I would like Aaron to replace me as coordinator of the event loop PSR. I can move to sponsor of the same PSR. 

Aaron: do you think this is a good idea?

Kind regards
Chris

Woody Gilk

unread,
Nov 23, 2015, 3:24:02 PM11/23/15
to php...@googlegroups.com
As a community member, I support this decision. I expect that Guzzle
and React would also have valuable input.
--
Woody Gilk
http://about.me/shadowhand
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/c5791e41-3fe5-4789-bd42-14000f2a3b84%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Cees-Jan Kiewiet

unread,
Nov 23, 2015, 3:38:11 PM11/23/15
to php...@googlegroups.com
Can't speak for Guzzle but I know ReactPHP has input for the PSR. Looking forward to help shape the event loop PSR and already reading up on the different eventloops/reactors out there.

Andrew Carter

unread,
Dec 11, 2015, 10:07:52 AM12/11/15
to PHP Framework Interoperability Group
Just bumping this thread.

I'm getting to the point where I'd like extra input on the proposal documents before an entrance vote.

Here's where I am at currently:

https://github.com/event-loop-proposal/fig-standards/blob/master/proposed/event-loop-meta.md
https://github.com/event-loop-proposal/fig-standards/blob/master/proposed/event-loop.md

I've given Cees-Jan admin access to the GitHub organisation and I've invited Christopher and Aaron. If you could both accept and submit pull requests for any changes that you think are appropriate that would be great.

I propose the rule that from now on all changes are via pull requests and that nobody can merge their own pull request.

As I'm aware, I believe Guzzle expressed an interest in working on the PSR for promises but not event loops (feel free to correct me).

Currently we have Aaron, Cees-Jan and Christopher for the two positions of co-ordinator and sponsor.

This could be solved if one if you wishes to co-edit the proposal with me. This is permitted, but discouraged, by the bylaws. I'm not sure the reasoning for this, but I'm sure that as reasonable adults we can work together and I would have no objections personally. I would volunteer to step aside, but I am confident that I can keep the ball rolling and work with this group to produce a high quality proposal that will stand the test of time - so I'd rather not vacate official involvement with the proposal.


Interested to hear your thoughts,

Andrew

Cees-Jan Kiewiet

unread,
Dec 11, 2015, 10:18:55 AM12/11/15
to php...@googlegroups.com
To be honest I wouldn't mind co-editing this proposal with you.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
Message has been deleted

Andrew Carter

unread,
Dec 11, 2015, 10:40:30 AM12/11/15
to PHP Framework Interoperability Group
That would leave us with this: https://github.com/event-loop-proposal/fig-standards/pull/2/files

I believe the container proposal currently has two editors.

Also, the bylaws state that a sponsor can replace an editor if they wish. Thus, if it does become an issue - it will only be a temporary one. Regardless, I strongly believe that we can move forward without such measures!

Aaron Piotrowski

unread,
Dec 11, 2015, 10:44:54 AM12/11/15
to PHP Framework Interoperability Group
I would be happy to act as coordinator for the proposal. I'd also like to contribute to the editing duties as I have a lot I'd like to contribute to this proposal, though that doesn't mean I have to have any official editor role.

Andrew Carter

unread,
Dec 11, 2015, 10:49:58 AM12/11/15
to PHP Framework Interoperability Group
Fantastic, I believe you can be a sponsor that is listed as a contributor too.

I'll update the pull request now.

Andrew Carter

unread,
Dec 11, 2015, 10:53:38 AM12/11/15
to PHP Framework Interoperability Group
Correction, the bylaws prohibit listing as a contributor.

"A Sponsor may not be the Editor or be listed as a Contributor, but there is of course nothing stopping a Sponsor from contributing."

Aaron Piotrowski

unread,
Dec 11, 2015, 10:57:34 AM12/11/15
to PHP Framework Interoperability Group
I think that it's almost implied as a sponsor that you contributed to the proposal. Being listed as a contributor appears to be reserved for those that fill neither of the other roles.

Cees-Jan Kiewiet

unread,
Dec 11, 2015, 11:35:38 AM12/11/15
to php...@googlegroups.com
That is exactly as it states in the bylaws and tbh it makes sense that sponsors, coordinator, and editor are heavily involved contributors: http://www.php-fig.org/bylaws/psr-workflow/#1-roles 

Larry Garfield

unread,
Dec 12, 2015, 2:29:22 PM12/12/15
to php...@googlegroups.com
Background:

The goal of having 2 Sponsors, who must be FIG reps, is to act as a filter. A proposal needs to have at least two members who think it's a good idea before the rest of FIG even considers it.

The goal of one of them being the Coordinator is so that there is a single buck-stops-here point of contact for administrative questions, voting, and other such paperwork.

The goal of having a preferably-single Editor is to have a single buck-stops-here point of authority.  Before that was established we had no clear picture on who "owned" a proposal, and thus who had final up-or-down decision making ability on proposed changes to it.  In extreme cases we had discussions about "Person A's version does this thing, Person B's does this other thing, but they overlap on this thing, and now I don't even know what we'd even be voting on."  When there's disagreement on what should/shouldn't be in the spec, final decision rests with the Editor, and that's why there is one.  That does not mean the Editor needs to be the one actively writing all of, most of, or even much of the spec.  Just that they decide what gets INTO the spec.

Please don't forget the Contributors list, though!  Just because there's only those 3 working group "officers" doesn't mean lots of other people can't "officially" work on it.  PSR-7, for instance, had a whole bunch of listed contributors beyond the 3 officers, and was a better spec for it.  Don't assume that being a Contributor is a "mere Contributor".  People can absolutely help write a spec, and be instrumental to it, without being one of the 3 named officers.  Please, let's not encourage the idea that someone only counts if they're the Editor/Coordinator.

Which is the long winded way of saying, "just pick an Editor and bring something to an entrance vote already!" :-)  You don't need 2 editors to get more people involved; you only need 2 editors if you need 2 people to handle decisions regarding pull requests.

--Larry Garfield

Cees-Jan Kiewiet

unread,
Dec 12, 2015, 3:00:42 PM12/12/15
to php...@googlegroups.com
Imho contributors are the most important people helping a project, whether it is a PSR, OSS package. I would never forget about them :). Thank you for the background behind the roles, much appreciated.

Regarding the entrance vote, had a chat with Andrew earlier this week on IRC and his goal is to have it ready and submit the entrance vote by end of next week.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages