FIG 3.0 (Including a TL;DR Summary)

[Michael Cullum]

Hi all,

A vote for FIG 3.0 is [potentially/hopefully] getting closer and one big thing people had been asking for is a TL;DR of FIG 3.0 to give an overview of the new structure and processes.

The last couple of days I've been working with Larry on compressing it into 3 graphics and a post that, according to medium, takes 3 minutes or less to read. I'd invite to you all to have a read of that version, and if that wets your appetite for more, then of course I'd suggest you take a read of the full bylaws (after all, that is what will actually be being voted upon).

I'd love to see some active discussion (or if you are just in general agreement about it, some +1s) about this over the next couple of weeks as discussion has been quite quiet on it over the last few weeks on the mailing list; however what I've heard from people at conferences and elsewhere has been a good positive reception. Assuming there are no major objections and we don't end up making major changes we'd like to see this going to a vote on the 17th August, to end on the 31st August. The CC elections would then be able to take place in September.

Without further comment, the TL;DR of FIG 3.0: http://bit.ly/fig-3-0

Many thanks,

Michael & Larry

(Note: I am not posting this as a secretary but as a co-author of FIG 3.0 in line with my declared conflict of interest)

[Larry Garfield]

For the record, I wasn't sure it would even be possible to do a graphical representation of FIG 3.  Fortunately, Michael proved me wrong. :-)  Nice work, Michael!

--Larry Garfield

[Paul Jones]

> On Aug 5, 2016, at 14:01, Michael Cullum <m...@michaelcullum.com> wrote:
>
> Hi all,
>
> A vote for FIG 3.0 is [potentially/hopefully] getting closer and one big thing people had been asking for is a TL;DR of FIG 3.0 to give an overview of the new structure and processes.
>
> The last couple of days I've been working with Larry on compressing it into 3 graphics and a post that, according to medium, takes 3 minutes or less to read. I'd invite to you all to have a read of that version, and if that wets your appetite for more, then of course I'd suggest you take a read of the full bylaws (after all, that is what will actually be being voted upon).
>
> I'd love to see some active discussion (or if you are just in general agreement about it, some +1s)

Of course we don't ask for -1s, do we.

For the record, again: the FIG 3.0 proposal is a fine idea *for a new and different* organization under a *new and different* name. Let it be free of the history and accomplishments (and baggage) of the FIG, and build a following of its own through its own new accomplishments.


--

Paul M. Jones
http://paul-m-jones.com

[Michael Cullum]

On 5 August 2016 at 20:24, Paul Jones <pmjo...@gmail.com> wrote:

> On Aug 5, 2016, at 14:01, Michael Cullum <m...@michaelcullum.com> wrote:
>
> Hi all,
>
> A vote for FIG 3.0 is [potentially/hopefully] getting closer and one big thing people had been asking for is a TL;DR of FIG 3.0 to give an overview of the new structure and processes.
>
> The last couple of days I've been working with Larry on compressing it into 3 graphics and a post that, according to medium, takes 3 minutes or less to read. I'd invite to you all to have a read of that version, and if that wets your appetite for more, then of course I'd suggest you take a read of the full bylaws (after all, that is what will actually be being voted upon).
>
> I'd love to see some active discussion (or if you are just in general agreement about it, some +1s)

Of course we don't ask for -1s, do we.

No I don't ask for -1s; if you're opinion is best represented by '-1' then of course we'd much rather see some feedback as to why so we can improve things or discuss things rather than just leaving it there, otherwise there is no point in having the discussion periods you advocate for.

 

For the record, again: the FIG 3.0 proposal is a fine idea *for a new and different* organization under a *new and different* name. Let it be free of the history and accomplishments (and baggage) of the FIG, and build a following of its own through its own new accomplishments.

 

This is a very understandable view, and I know a few people share it so I'll try address it briefly here:

My personal 2 cents on this is that if that were to happen, a new organisation would end up (accidentally or intentionally) replacing the FIG; if this happens then it could cause logistical issues with the looking after old PSRs, and I imagine maintenance of them would eventually end up under the new organisation, and then we've essentially had exactly the same outcome as a transition within the FIG, but without the name, reputation (which is, after many years, now actually a very strong brand across the php ecosystem, far wider than reddit or our twitterspheres which unrepresentatively discuss drama), background in our current 7 PSRs and 11 current draft PSRs being worked on (only 2 of which are inactive) and without the 'grandfathering' over of existing member projects. Furthermore, the initial CC/Secretary elections of a new organisation would be very un-democratic without that initial base of contributors and projects.

Alternatively, if both standards organisations exist and continue with new development of standards, ultimately, at some point in the future, they will end up competing, and creating competing standards (which is kind of the opposite of standardisation). Furthermore I'd add that it would either split projects, where some projects are part of one group whereas others are part of another (splitting the php ecosystem into two mini-ecosystems that are interoperable within themselves but not with each other); or they would end up sharing the same member base, in which case it would add even further complexity as to when there are competing standards.

Many thanks

Michael C

[Paul Jones]

> On Aug 5, 2016, at 15:19, Michael Cullum <m...@michaelcullum.com> wrote:
>
>> On 5 August 2016 at 20:24, Paul Jones <pmjo...@gmail.com> wrote:
>>
>> Of course we don't ask for -1s, do we.
>
> No I don't ask for -1s; if you're opinion is best represented by '-1' then of course we'd much rather see some feedback as to why so we can improve things or discuss things rather than just leaving it there, otherwise there is no point in having the discussion periods you advocate for.

If one is happy with non-verbal positive feedback, one should be happy with non-verbal negative feedback as well.

I'll have more to say about the remainder at a later time.

[Woody Gilk]

On Friday, August 5, 2016 at 2:01:09 PM UTC-5, Michael Cullum wrote:
>
> Without further comment, the TL;DR of FIG 3.0: http://bit.ly/fig-3-0

If I am reading this correctly, the Editor and Sponsor of a PSR would
both have to be members of FIG? And then also find 3 other "random"
people to form a 5 person working group? Doesn't that imply that
non-members would be at a distinct disadvantage to create and propose
ideas to FIG? PSR-15 and PSR-17 would be nowhere if FIG 3.0 had been
in place when they were initiated.

On Fri, Aug 5, 2016 at 2:24 PM, Paul Jones <pmjo...@gmail.com> wrote:
>
> Let it be free of the history and accomplishments (and baggage) of the FIG, and build a following of its own through its own new accomplishments.

I have no idea what this is supposed to mean.
--
Woody Gilk
http://about.me/shadowhand

[Michael Cullum]

On 5 August 2016 at 20:32, Woody Gilk <woody...@gmail.com> wrote:

On Friday, August 5, 2016 at 2:01:09 PM UTC-5, Michael Cullum wrote:
>
> Without further comment, the TL;DR of FIG 3.0: http://bit.ly/fig-3-0

If I am reading this correctly, the Editor and Sponsor of a PSR would
both have to be members of FIG? And then also find 3 other "random"
people to form a 5 person working group? Doesn't that imply that
non-members would be at a distinct disadvantage to create and propose
ideas to FIG? PSR-15 and PSR-17 would be nowhere if FIG 3.0 had been
in place when they were initiated.

Not sure which part of the article implied this (if you could point it out I'd be happy to rectify it) as the Editor can be anyone (except a Secretary), just like now. I've added a clarification to this in the section detailing the Working Groups.

The sponsor must be a CC member and would be the equivalent of the sponsor/coordinator now, so actually now we only require one instead of two. The 3+ other people involved could be CC members, community members, secretaries or project representatives.

 

--
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+unsubscribe@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/CAGOJM6Je1QymL-hFR%3DMb%3Dh%2Bv-8kDXKtbr6yr47DtrjcizZ1K%2BQ%40mail.gmail.com.

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

[Alessandro Lai]

Paul, this is completely false.

If your response is a +1, you completely agree with the proposal and don't have anything to add.

If your response is a -1, some additional feedback is required, because you should at least point out what you don't like in the new proposal; better, you could propose changes.

Please, be constructive.

Returning in topic: I like this a lot!! The only question that I have is: who evaluates and decides the stakes or the competence on a PSR of the 3 other members? If he's a project representative, it's easy... What about community members?

[Adam Culp]

Thank you for doing this Michael, it clarified a few questions I had while highlighting a new concern:

Based on what I see the Member Projects of the FIG do not get to vote, though they can share their comments via the group. However, Member Projects are encouraged to implement these interoperability "standards" without said vote. (imposed "tax") Dramatic I know, but valid.

I foresee a future full of squabbling and rejection to use PSRs because, "I didn't vote for it!" There would be no "ownership" of these new PSRs.

I fully understand the working group would be composed of individuals that are best in a given field as subject experts, and who may have a more active role in the given technology. But again...ownership is key to ensure these interoperability recommendations are accepted by more projects.

As such, I would suggest the addition of a "Member Projects Vote" after the "Review stage" but before the "Core Committee: Acceptance Vote". Make it a standard 2 week combined voting/feedback period to air out any unforeseen comments/concerns, where simple majority passes the motion. Then when the Core Committee accepts the PSR there will be much wider adoption and acceptance.

Thoughts?

Regards,

Adam Culp

IBMiToolkit

[Alessandro Lai]

I would only add to Adam's suggestion that the vote could be in parallel to the core committee's, to save time.

[Lukas Kahwe Smith]

On 06 Aug 2016, at 02:06, Adam Culp <thege...@gmail.com> wrote:

Thank you for doing this Michael, it clarified a few questions I had while highlighting a new concern:

Based on what I see the Member Projects of the FIG do not get to vote, though they can share their comments via the group. However, Member Projects are encouraged to implement these interoperability "standards" without said vote. (imposed "tax") Dramatic I know, but valid.

I foresee a future full of squabbling and rejection to use PSRs because, "I didn't vote for it!" There would be no "ownership" of these new PSRs.

I fully understand the working group would be composed of individuals that are best in a given field as subject experts, and who may have a more active role in the given technology. But again...ownership is key to ensure these interoperability recommendations are accepted by more projects.

As such, I would suggest the addition of a "Member Projects Vote" after the "Review stage" but before the "Core Committee: Acceptance Vote". Make it a standard 2 week combined voting/feedback period to air out any unforeseen comments/concerns, where simple majority passes the motion. Then when the Core Committee accepts the PSR there will be much wider adoption and acceptance.

Thoughts?

Without suggesting a specific mechanic, I also agree that at some stage a PSR should get voted on by all members. In practice this should be more or less an “easy vote” but its important in order to get the buy-in from the member projects and to ensure that working groups do not over engineer.

regards,

Lukas Kahwe Smith

sm...@pooteeweet.org

[Woody Gilk]

On Fri, Aug 5, 2016 at 4:10 PM, Michael Cullum <m...@michaelcullum.com> wrote:
> Not sure which part of the article implied this (if you could point it out
> I'd be happy to rectify it) as the Editor can be anyone (except a
> Secretary), just like now. I've added a clarification to this in the section
> detailing the Working Groups.

Attached file is what I was referring to. The wording in the graphic
seems to imply that the editor and sponsor must both be from the CC. I
see your updated wording has clarified that point.

[Michael Cullum]

Ah thanks, yeah, the from CC was just referring there to the sponsor. I've now clarified this elsewhere in the text though to be absolutely clear. 

On 5 August 2016 at 23:35, Alessandro Lai <alessand...@gmail.com> wrote:

Returning in topic: I like this a lot!! The only question that I have is: who evaluates and decides the stakes or the competence on a PSR of the 3 other members? If he's a project representative, it's easy... What about community members?

So in an ideal world, we'll never have an issue where people disagree as to whether or not a project is relevant. Irrelevant projects won't claim to be relevant etc. However, in reality, there might be disagreements. The Editor and Sponsor have the initial call with regards to this, and Secretaries can advise, but should an individual/project disagree with their call then it can be escalated to the Core Committee who can make a final decision.

On 6 August 2016 at 01:06, Adam Culp <thege...@gmail.com> wrote:

Thank you for doing this Michael, it clarified a few questions I had while highlighting a new concern:

Based on what I see the Member Projects of the FIG do not get to vote, though they can share their comments via the group. However, Member Projects are encouraged to implement these interoperability "standards" without said vote. (imposed "tax") Dramatic I know, but valid.

I foresee a future full of squabbling and rejection to use PSRs because, "I didn't vote for it!" There would be no "ownership" of these new PSRs.

I fully understand the working group would be composed of individuals that are best in a given field as subject experts, and who may have a more active role in the given technology. But again...ownership is key to ensure these interoperability recommendations are accepted by more projects.

As such, I would suggest the addition of a "Member Projects Vote" after the "Review stage" but before the "Core Committee: Acceptance Vote". Make it a standard 2 week combined voting/feedback period to air out any unforeseen comments/concerns, where simple majority passes the motion. Then when the Core Committee accepts the PSR there will be much wider adoption and acceptance.

You're correct in that commenting on the development of specifications will remain open to everyone, just as is the case now. Whilst we are formalising the composition of working groups, this is more about who will get a vote on the spec than who will be 'allowed to comment'.

I understand your concern, and I think the main issue here is the confusion of the working group vote. Essentially, the 'Readiness' vote, done by the Working Group, should contain all relevant projects. The idea of the Working Group structure is moving towards a place where projects that have no relevance (will neither implement, nor call) will not have a vote in a specification as right now there are lots of member projects who vote on specifications without understanding them, having relevance to them, or sometimes without even reading them.

However, there are some instances in which this is impractical, for example, PSR-1 & PSR-2 which of course would affect every single PHP project. In which case, the working group, whilst not containing every single member project, would be obligated to do an informal vote of member projects before entering the review phase. Without it, and without it passing, the Core Committee would assess that the specification hadn't considered all stakeholders and therefore not pass a final acceptance vote.

Lukas, in terms of over-engineering, this would also partly fall to the CC as part of their responsibility of ensuring the specs are of a good quality, are implementable, are consistent within the FIG, meet the aims of the FIG and follow the general technical direction of the FIG.

To summarise:

(1) Generally, working groups should contain all relevant projects as well as subject experts, all should remain reasonably active, but others will obviously tend to be more active than others

(2) An exception to (1) is where all (or a very large number of) projects could be considered affected

(3) One of the core parts of the CC's role is to ensure all stakeholders are heard by the WG

(4) Therefore it would be expected that in a case where a large number of non-WG projects would be affected by a specification, an informal vote of member projects should be taken

(5) Should that vote fail, the CC would consider that not all stakeholders views to have been heard by the WG, and reject the spec until it can pass member projects.

(6) But in instances where most WGs are irrelevant to the problem-space (e.g. async?) they wouldn't have a vote

To clarify, I'm just explaining how the current system works and I'd be interested to hear if you think that solves the problem you've identified; I'm not against the idea of introduction of a slightly more formal soft member projects vote at some stage, I'd just like to see some rationale as to why that's an improvement over (or what is wrong with) the system described above now I've fully explained it (after all, in a TL;DR this kind of thing isn't covered in such depth).

Many thanks,

Michael C

[Paul Jones]

> On Aug 5, 2016, at 17:35, Alessandro Lai <alessand...@gmail.com> wrote:
>
> Paul, this is completely false.

I think you've got that wrong. I'll explain:

> If your response is a +1, you completely agree with the proposal and don't have anything to add.

So if your response is a -1, you completely *dis*agree with the proposal and don't have anything to add. (Pretty straightforward, really.)

Also, I *did* give additional feedback. I'll restate it in case you missed it earlier.

The FIG 3.0 proposal is perfectly fine for a *new* group with a *new* name, one that can then earn its own reputation by producing new work under the new rules. It should not be applied to *this* group.

Let me know if I can clarify that further for you.

[Matthieu Napoli]

> If your response is a +1, you completely agree with the proposal and don't have anything to add.

So if your response is a -1, you completely *dis*agree with the proposal and don't have anything to add.  (Pretty straightforward, really.) 

Also, I *did* give additional feedback. I'll restate it in case you missed it earlier.

Please take that off-topic discussion into another thread. To anyone wanting to answer to Paul: please answer in a new thread. Let's try to keep the discussion on track.

---

I like that project (FIG 3.0) a lot, however I'm also concerned that only 12 people will vote on PSRs. What if there's a PSR being written that has nothing to do with those 12 people?

For example what if there's an "async" PSR but none of those 12 people work with async libraries: why would they vote YES? And also important: why would they be "qualified" enough to vote correctly on topics they may not work with? -> both technically and in terms of seeing/understanding the need behind the PSR (hope I'm not offending anyone in saying that, that's not the goal at all)

[Daniel Hunsaker]

On Saturday, August 6, 2016 at 11:43:51 AM UTC-6, Matthieu Napoli wrote:

I like that project (FIG 3.0) a lot, however I'm also concerned that only 12 people will vote on PSRs. What if there's a PSR being written that has nothing to do with those 12 people?

For example what if there's an "async" PSR but none of those 12 people work with async libraries: why would they vote YES? And also important: why would they be "qualified" enough to vote correctly on topics they may not work with? -> both technically and in terms of seeing/understanding the need behind the PSR (hope I'm not offending anyone in saying that, that's not the goal at all)

This seems to be an incorrect - though common - interpretation of the WG and CC implementation proposed above.  As I understand it, from reading the TL;DR, the comments on the ML, and the actual FIG 3.0 bylaws themselves, the 12-member CC doesn't actually vote on the content of the PSR.  Instead, the Working Groups vote on the technical content of a PSR, while the Core Committee votes on whether the PSR went through the correct processes completely, and can therefore be considered finalized.  The CC's understanding of the spec itself isn't strictly relevant to their vote, because they aren't voting on the content, beyond a high-level quality-assurance evaluation.  Instead, they're voting on whether the WG properly considered input from all interested parties, whether the spec is properly presented in accordance with FIG conventions, whether the required number of implementations exist, and similar.  This is all done *after* the technical considerations have been voted on by the WG (and if the WG doesn't already contain all interested/affected parties in its own right, the FIG Member Projects at large, as described earlier by Michael), and that vote has passed.  So by the time the CC sees it, the technical content should already have been vetted.

Said another way, the WG is responsible for the technical vote; the CC is responsible for the process vote.  Or as an analogy, the WG is the developers, while the CC is quality assurance.  I'm not really seeing a conflict, here, in having the WG/CC voting process be set up the way it is.

----

Regarding the "ownership" concern brought up by others in this thread, I think formalizing the "informal vote of member projects" that Michael mentioned above *into* the process (by which I mean, adding it to the FIG 3.0 bylaws, in writing) would probably address this concern, by making clear that such a vote is expected in these cases?  Is that a valid conclusion?

I imagine the WG would be responsible for taking this step, as described above, and if it isn't completed before the CC vote, they would be obligated to reject the PSR until that vote has been cast and considered.  At which point, the WG could resubmit the PSR for further evaluation and approval.  (I imagine the vote results, along with major concerns expressed therein, and so forth, would be included in the meta document?)  I could see a case or two crop up where the WG doesn't realize their PSR covers other member projects in the first place, and only discovering that fact after sending the PSR to the CC for approval.  But I also expect the CC would point this out during the initial acceptance vote on whether a PSR should even be created, if the WG didn't already note such scope in their proposal.

- Daniel Hunsaker

[Ryan Thompson]

I feel like the changes in structure are fantastic, definitely filling some gaps that we've discovered. It's solid a step in maturing the organization.

I would, however, love to see the addition of core principles make their way into FIG 3.0. Include a set of changeless principles (a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning.) that the organization can operate on from a communication perspective. 

Similar to what we have done with FIG voting and technical operations.

I think this is important because the organization as a whole, in order to be healthy and effective with the PHP community in it's mission statement, needs to cultivate a healthy and synergistic environment around it. For both our internal members and in our community relationships.

We've seen this break down more and more recently. Often times it comes from outside of our boundaries of influence (Twitter / Redit). But when poor behavior and negative communication makes it's way into the FIG's direct ring of influence we have no principles to stand on to uphold a standard of communication. A standard of expectations from our members who represent FIG. So instead, peoples feelings get hurt, time is wasted and energy is wasted between us with no resolve or forward movement. In fact we have seen negative movement. People get frustrated and leave or discredit the FIG.

If we had a set of principles to abide by in terms of communicating within our ring of influence (within areas we are directly responsible for) we can cut that cancerous energy and which will promote more effectiveness.

We've seen the consequences of not having a core set of principles. It's kinda like not having a conscience as a whole. What can we do to fix that?

And to those who might say this is none of our responsibility. I would argue this: Is it not our mission to produce quality PSRs for the community as a whole? And does it not hinder our ability, our effectiveness in doing just that by not withholding a core set of principles on how we communicate both internally but also with that community as a whole?

I hope this get's some thought from others. It's an important part of an effective organization and it's currently missing in FIG I think. 

I would be happy to head such an effort if there is any perceived need for it.

- Ryan

On Friday, August 5, 2016 at 2:01:09 PM UTC-5, Michael Cullum wrote:

[Larry Garfield]

On 08/06/2016 12:43 PM, Matthieu Napoli wrote:
>
> I like that project (FIG 3.0) a lot, however I'm also concerned that
> only 12 people will vote on PSRs. What if there's a PSR being written
> that has nothing to do with those 12 people?
>
> For example what if there's an "async" PSR but none of those 12 people
> work with async libraries: why would they vote YES? And also
> important: why would they be "qualified" enough to vote correctly on
> topics they may not work with? -> both technically and in terms of
> seeing/understanding the need behind the PSR (hope I'm not offending
> anyone in saying that, that's not the goal at all)

Hi Matthieu. No offense taken.

The CC isn't expected to be domain experts in all subjects. That would
be unreasonable, and in practice impossible.

The issue you identify is exactly the issue we have today: Of the 39
member projects we have now, how many of them have any experience with
async? Of the representatives of those projects, how many have written
async code? Very very few, so an async spec in FIG today would be voted
on by 39 people/projects that for the most part don't have any
experience or expertise to offer, most of whom do not have the time or
inclination to become domain experts just to vote on it. That's bad. :-)

When we started talking about async PSRs last year, we said
(collectively) "we should get some more async projects in FIG, so we
know what we're doing." That is, of course, a totally backwards way to
go about it because it doesn't at all help the other projects and their
reps know what they're doing, but it does then give those few async
projects equal vote on, say, middlewares, or caching, areas where they
may not have any expertise to offer either.

The solution to that is the CC/WG split: The Working Group is designed
to be composed of those people -- whether project-affiliated or not,
whether CC members or not -- who do have relevant domain knowledge
and/or "skin in the game" because they are from a project (whether a FIG
member or not) that does have directly relevant experience. It then
gives them more say, because as a WG member they get a vote on the spec
before it's passed up to the Core Committee. In that sense, this model
gives even more authority to those who would be most affected by a given
spec.

To Adam's "taxation without representation" point, it means that those
who may be affected by a given spec would have more representation then
they do today; they do not need to first be a member project, and their
vote is not diluted by all of those projects that, frankly, have nothing
to add.

For example, let's be honest, Drupal has little if anything to add to an
async spec. We might make use of it in the future sometime, but at this
point Drupal the project is of no real value, at least no more than any
other random PHP user in the world. The input of people like Aaron
Piotrowski of Icicle, however, is absolutely crucial, and far more
important than anything I have to add. But that shouldn't require
giving Icicle (which is still a small and experimental project) an equal
say in Middleware design as Michael O'Phinney. Similarly, it may be
valuable to actively include Sara Golemon (from HHVM, which has async
support) even though she's not affiliated with any project at all.

The Core Committee, then, is not intended to deal with the nitpicky
minutua of the spec. It's intended to look at the broader picture,
ensure that specs are consistent with each other to the extent relevant
(eg, PSR-13 favors immutability in order to be compatible with PSR-7)
and don't do anything grossly stupid (let's do everything with
subclasses and public properties!), ensure that Igor Wiedler (of React
PHP) wasn't actively excluded, and so on. That does likely mean that CC
members will be required to become at least passingly familiar with any
topic that warrants a spec. They'll need to know what promises are and
why they are, for instance, even if they've never written a promises
library themselves. Asking 12 people (who volunteered for the job) to
become at least passingly familiar with various topics is much more
reasonable, and achievable, than asking 40-odd people to do so just
because they want to have input in one specific spec that relates to
their project.

So yes, CC members will need to become minimally competent in various
topics, but not experts. That's a much easier task than we have today,
and is complemented by explicitly putting the domain experts in a given
area directly in charge of the technical nitty gritty that they're
trying to solve.

--Larry Garfield

[Matthieu Napoli]

Thank you Larry and Daniel for your answers, it's now much clearer. And now I see how it's going to solve the current problem were everyone votes on everything.

My last concern would then be: are we confident that the scope of the Core Committee vote is well defined and cannot be abused even a little? Here is an extreme scenario: could a Core Committee member vote -1 on a standard because that member has an implementation in their framework that is different, and the new standard could threaten somehow their de-facto existing standard in the community? Do those vote need to be justified somehow, and is their a recourse if their's a doubt or flagrant abuse?

Sorry for bringing such a "dark" question up :)

In any case all of this is a very good improvement, thanks to those working on that.

[Michael Cullum]

On 6 August 2016 at 20:37, Ryan Thompson <ser...@aiwebsystems.com> wrote:

I feel like the changes in structure are fantastic, definitely filling some gaps that we've discovered. It's solid a step in maturing the organization.

I would, however, love to see the addition of core principles make their way into FIG 3.0. Include a set of changeless principles (a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning.) that the organization can operate on from a communication perspective. 

Similar to what we have done with FIG voting and technical operations.

I think this is important because the organization as a whole, in order to be healthy and effective with the PHP community in it's mission statement, needs to cultivate a healthy and synergistic environment around it. For both our internal members and in our community relationships.

We've seen this break down more and more recently. Often times it comes from outside of our boundaries of influence (Twitter / Redit). But when poor behavior and negative communication makes it's way into the FIG's direct ring of influence we have no principles to stand on to uphold a standard of communication. A standard of expectations from our members who represent FIG. So instead, peoples feelings get hurt, time is wasted and energy is wasted between us with no resolve or forward movement. In fact we have seen negative movement. People get frustrated and leave or discredit the FIG.

If we had a set of principles to abide by in terms of communicating within our ring of influence (within areas we are directly responsible for) we can cut that cancerous energy and which will promote more effectiveness.

We've seen the consequences of not having a core set of principles. It's kinda like not having a conscience as a whole. What can we do to fix that?

And to those who might say this is none of our responsibility. I would argue this: Is it not our mission to produce quality PSRs for the community as a whole? And does it not hinder our ability, our effectiveness in doing just that by not withholding a core set of principles on how we communicate both internally but also with that community as a whole?

I hope this get's some thought from others. It's an important part of an effective organization and it's currently missing in FIG I think. 

I would be happy to head such an effort if there is any perceived need for it.

- Ryan

Ryan,

Thank you for your kind words on the proposed changes.

A large part of these changes, although not accurately reflected in terms of the percentage of the bylaw text changes, but in terms of weight, is the new mission statement for the FIG. This aims to serve as a core changeless principle to the purpose of the FIG, and a statement by which all elements of the new structure can look to for determining what the FIG is. I do not wish the importance of the mission statement to be under-estimated, and I know there are many who believe this to be the most important change in FIG 3.0. If you had any suggestions on expansion of the mission statement, we would be more than open to receiving those ideas.

What it does not cover, is how the FIG conducts itself to meet that purpose. Larry and I discussed whether or not a set of principles as to how the FIG conducts itself in something akin to the Code Manifesto or a Code of Conduct should be integrated into FIG 3.0. Ultimately, we decided against this as, whether we supported its inclusion in FIG bylaws or not, it would be better to separate the two issues as people might have varying views on the two, and it would be odd to see a vote fail on two matters if both have over 50% support, but 50% or more do not support both of them. In breaking things down we can give voting members a choice in individual issues, instead of having to take things as a take it all or leave it package; I'd liken, perhaps with a tiny amount of exaggeration, combining the FIG 3.0 and conduct principles votes to having a combined vote for PSR-6 and PSR-7.

I'll be careful to avoid commenting on my personal views on this as it ventures outside the waters of what is currently FIG 3.0 and I don't want to compromise my neutrality as Secretary however on an administrative note if anyone did wish to work on something of such like then they would of course be welcome to; if FIG 3.0 passes then it would be subject to a vote of the Core Committee and Member Projects. I'd also suggest [I'm not posting as a Secretary as this topic concerns FIG 3.0, so this is not a moderator instruction] any further discussion of this is taken into a new separate topic, and perhaps now might not be the best time for that topic in that it might be best left until there is some foundation for a proposal or some suggestions on implementation to avoid outright opinions (acceptance or dismissal) on the concept without considering implementation.

Many thanks,

Michael C

[Michael Cullum]

I apologise for the double post, I had not seen Matthieu's last post, after this post I will self-throttle as I have been previously and not reply for the rest of the day. I'm also about to go away for a few days so I will be responding less but Larry is of course still around.

On 7 August 2016 at 09:31, Matthieu Napoli <matt...@mnapoli.fr> wrote:

My last concern would then be: are we confident that the scope of the Core Committee vote is well defined and cannot be abused even a little? Here is an extreme scenario: could a Core Committee member vote -1 on a standard because that member has an implementation in their framework that is different, and the new standard could threaten somehow their de-facto existing standard in the community? Do those vote need to be justified somehow, and is their a recourse if their's a doubt or flagrant abuse?

Sorry for bringing such a "dark" question up :)

In any case all of this is a very good improvement, thanks to those working on that. 

Thank you also for your kind words and raising such important points for addressing.

You bring up an entirely valid point, people in any position of responsibility are subject to abusing that power and responsibility they hold, whether they are Secretaries or Core Committee Members. There are mechanisms in place for calling for what is essentially a removal vote/vote of no confidence (Recall Vote) in Core Committee Members and Secretaries, and of course they will be subject to forced re-election once their terms end, a good time to elect people who will be voting within their remit and taking the FIG in the desired direction of the wider FIG community and structure. I'd also note that with 12 of them, 4 of them would need to vote -1 for a motion to fail. I'd imagine that the Secretaries and Core Committee would all work closely together to ensure that everyone is fulfilling their role properly. I would also imagine that whilst it is not required in the bylaws, those electing the Core Committee would expect any -1 votes to be appropriately justified to the rest of the Core Committee and the wider FIG community; similarly to how judges in a supreme court might publish a dissent.

Many thanks,

Michael C

[Adam Culp]

Michael,

Please self-throttle a bit. It seems you are over-communicating/defending rather than allowing members to flesh this out.

Perhaps a topic for a different thread, but I'm becoming increasingly concerned about the direction I see things going. Not to be alarmist, but I feel I should speak up. I am seeing more and more posts where Secretaries (namely Michael) are increasingly playing a much more active role in decisions and direction through their communication. Additionally, in the TL;DR (topic of this thread) it states the Secretaries will be doing "exactly same as present", which by it's definition is vague. I think current activity, as well as these posts, by secretaries, is already bordering on being "too much". Please be cautious of "cheering" versus aiding members understanding of issues at hand.

Regards,

Adam Culp, IBMiToolkit

[Matthieu Napoli]

Michael,

Please self-throttle a bit. It seems you are over-communicating/defending rather than allowing members to flesh this out.

It says right there in his previous email that he realizes he sent 2 emails in this thread today and that he will self-throttle. Additionally the self-throttle "rule" is 2 posts per topic per day so technically he's doing nothing wrong here (unless maybe when looking at it from another timezone…) This kind of remark only derails the conversation for no reason.

 

Perhaps a topic for a different thread, but …

If you think this is a different thread then a new thread should be created?

[Adam Culp]

I would also argue that self throttling would extended to secretaries taking an active role in a discussion threads, versus aiding members in understanding content. Michael has posted many times in this thread defending 3.0 versus allowing members to contribute to making it work for all.

Regards,
Adam Culp, IBMiToolkit

[Christopher Pitt]

secretaries taking an active role in a discussion threads, versus aiding members in understanding content

I don't understand the difference. Unless by "aiding members in understanding" you mean not speaking. Then I understand the difference. :)

[Adam Culp]

Chris,

Your condescending post was not a help. :) However, since you addressed me I will respond. I was referring to the Secretaries description of duties where I see no mention of the sort of lobbing Michael is doing for FIG 3.0.

I know this is a bit of a tricky area because Michael has played such an active role in 3.0, for which I am grateful. However, as I said in private communication with Michael, if he desires to continue playing such an active role perhaps he should step down as Secretary to help usher in this new era, then pick up being Secretary again at the next opportunity...pending nomination and voting.

Regards,

Adam Culp, IBMiToolkit

[Christopher Pitt]

Hi Adam,

I apologise, that was not meant condescendingly at all! I sincerely do not understand what you meant.

Kind regards

Chris

[Adam Culp]

Thanks Chris. Taking this topic to a new thread. Sorry for diverting from the original thread topic, it was not my intent.

Regards,

Adam Culp, IBMiToolkit

[Larry Garfield]

On Aug 7, 2016 5:28 PM, Christopher Pitt <cgp...@gmail.com> wrote:
>>
>> secretaries taking an active role in a discussion threads, versus aiding members in understanding content
>
>
> I don't understand the difference. Unless by "aiding members in understanding" you mean not speaking. Then I understand the difference. :)

Michael has stated a few times that on FIG 3, he's speaking as the co-author, not Secretary, just as I'm speaking as co-author, not Drupal rep. Taking an advocacy position is therefore entirely appropriate and to be expected.

Adam, did my earlier message address your concerns?

--Larry Garfield

[Chad Windnagle]

Hi All

I have only some minor feedback to give regarding the PSR development cycle:

Annotation for reference:

https://www.evernote.com/l/ACqT4gmzrU5DKLq8iYZC70kGULwQbv26lfs

A more details explanation:  the new cycle has a verification check to ensure the PSR working group members had the correct stakeholders involved. I assume that this verification probably actually takes place during the formation of the working group and the entrance vote discussions. Meaning the relevant voices for major implementers will make themselves known. But since in the workflow diagram it is cited as happening at the acceptance vote stage, I felt it was worth bringing up. 

I believe it would be more appropriate to move this sort of verification to the entrance vote stage. My thought process is that after a lot of commitment in time and energy has gone into developing the PSR draft, it would be a shame to come to the end of that process only to discover that a stakeholder was excluded or someone's expertise in the working group was misrepresented, and therefore the work is seen as unfit for even an acceptance vote. 

Regards,

[Adam Culp]

Thanks Larry, but as stated I will be taking the the Secretary topic to a new thread. It should not be here.

As for your post answering my concerns, it did not. Your post assumes that a given PSR would only affect a limited number of member projects, and therefore they would all likely be a part of the process. While this scenario may apply to some of the current PSR's on the deck now, it will likely not always be the case.

Again, I was not saying that a member vote would carry HUGE amounts of weight on a given PSR vote. I would envision that a member vote would help alert member projects about the completion of PSRs that may affect them, and allow them to have some limited input prior to it going final. Isn't that a portion of why we are all members of the group to begin with?

Otherwise we could easily enter a situation where member projects would not be aware of something they should be concerned about until it is too late. However, as a member of the interoperability group it would be somewhat expected for them to comply by the outside community.

Regards,

Adam Culp, IBMiToolkit

[Samantha Quiñones]

Hi, all,

I was not monitoring the ML yesterday (getting some family Q.T. after a trip) but I'll be keeping an eye on it today. I think we are all adults and can abide by throttling rules in good faith. In the future, if you have any concerns about the content or velocity of this (or any other FIG 3.0 threads) please reach out directly. You can email info [at] php-fig.org or DM the secreaties directly (for me, twitter @ieatkillerbees is the best route, I will get that basically as long as I have working cell service). 

As Michael is participating in the FIG discussions as a co-author (and therefore as an advocate), I will be handling all moderation of these threads. Throttling rules aside, I don't think anyone is keen on getting any number of emails that appear to be squabbling and I remind the members that I (and any other current or future secretary when acting in that role) am here precisely to assure the orderly execution of our organization's process. Please use us! 

We do ourselves a favor by not allowing these kinds of conflicts to escalate unnecessarily. They are essentially off-topic and not a productive use the ML.

Thanks,

Samantha

[Paul Dragoonis]

On Sun, Aug 7, 2016 at 9:39 PM, Adam Culp <thege...@gmail.com> wrote:

Michael,

Please self-throttle a bit. It seems you are over-communicating/defending rather than allowing members to flesh this out.

Perhaps a topic for a different thread, but I'm becoming increasingly concerned about the direction I see things going. Not to be alarmist, but I feel I should speak up. I am seeing more and more posts where Secretaries (namely Michael) are increasingly playing a much more active role in decisions and direction through their communication. Additionally, in the TL;DR (topic of this thread) it states the Secretaries will be doing "exactly same as present", which by it's definition is vague. I think current activity, as well as these posts, by secretaries, is already bordering on being "too much". Please be cautious of "cheering" versus aiding members understanding of issues at hand.

I will second this point, and add I am seeing the secretaries roles becoming more Authoritative instead of Assistive. I want us, as a group, to make sure that it's always the latter case.

I also want to say thank you to Michael for putting together the TLDR and the diagrams that I requested for FIG 3.0

 

Regards,

Adam Culp, IBMiToolkit

On Sunday, August 7, 2016 at 12:28:18 PM UTC-4, Michael Cullum wrote:

I apologise for the double post, I had not seen Matthieu's last post, after this post I will self-throttle as I have been previously and not reply for the rest of the day. I'm also about to go away for a few days so I will be responding less but Larry is of course still around.

On 7 August 2016 at 09:31, Matthieu Napoli <matt...@mnapoli.fr> wrote:

My last concern would then be: are we confident that the scope of the Core Committee vote is well defined and cannot be abused even a little? Here is an extreme scenario: could a Core Committee member vote -1 on a standard because that member has an implementation in their framework that is different, and the new standard could threaten somehow their de-facto existing standard in the community? Do those vote need to be justified somehow, and is their a recourse if their's a doubt or flagrant abuse?

Sorry for bringing such a "dark" question up :)

In any case all of this is a very good improvement, thanks to those working on that. 

Thank you also for your kind words and raising such important points for addressing.

You bring up an entirely valid point, people in any position of responsibility are subject to abusing that power and responsibility they hold, whether they are Secretaries or Core Committee Members. There are mechanisms in place for calling for what is essentially a removal vote/vote of no confidence (Recall Vote) in Core Committee Members and Secretaries, and of course they will be subject to forced re-election once their terms end, a good time to elect people who will be voting within their remit and taking the FIG in the desired direction of the wider FIG community and structure. I'd also note that with 12 of them, 4 of them would need to vote -1 for a motion to fail. I'd imagine that the Secretaries and Core Committee would all work closely together to ensure that everyone is fulfilling their role properly. I would also imagine that whilst it is not required in the bylaws, those electing the Core Committee would expect any -1 votes to be appropriately justified to the rest of the Core Committee and the wider FIG community; similarly to how judges in a supreme court might publish a dissent.

Many thanks,

Michael C

--
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+unsubscribe@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/fe83afcf-c6fe-4a83-9d3e-6b89b568f7aa%40googlegroups.com.

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

[Jan Schneider]

Zitat von Michael Cullum <m...@michaelcullum.com>:

Hi all,

 

A vote for FIG 3.0 is [potentially/hopefully] getting closer and one big thing people had been asking for is a TL;DR of FIG 3.0 to give an overview of the new structure and processes.

 

The last couple of days I've been working with Larry on compressing it into 3 graphics and a post that, according to medium, takes 3 minutes or less to read. I'd invite to you all to have a read of that version, and if that wets your appetite for more, then of course I'd suggest you take a read of the full bylaws (after all, that is what will actually be being voted upon).

 

I'd love to see some active discussion (or if you are just in general agreement about it, some +1s) about this over the next couple of weeks as discussion has been quite quiet on it over the last few weeks on the mailing list; however what I've heard from people at conferences and elsewhere has been a good positive reception. Assuming there are no major objections and we don't end up making major changes we'd like to see this going to a vote on the 17th August, to end on the 31st August. The CC elections would then be able to take place in September.

 

Without further comment, the TL;DR of FIG 3.0: http://bit.ly/fig-3-0

 

Many thanks,

Michael & Larry

(Note: I am not posting this as a secretary but as a co-author of FIG 3.0 in line with my declared conflict of interest)

I like this direction a lot, especially the vote "burden" being delegated to WGs that actually know what they talk and vote about. I don't think it would still be required to have the whole FIG resp. all member projects having a final vote. This is similar to the RFC process where WGs are formed to work on a specific Draft, sometimes being a subset of a larger interest group herding related RFCs of a certain technical area.

Jan

---

Jan Schneider
The Horde Project
http://www.horde.org/

[Larry Garfield]

Hi Adam.  There seems to be two different threads in your comment, so I am going to try and separate them.

One is ensuring influence of projects on a spec.  The other is ensuring awareness by projects of a spec.

The second one is much easier: That's why specs are discussed on list (or equivalent if we ever were to move to a forum or similar), and why an Entrance Vote (to form a WG) should happen earlier, rather than later.  A project rep's job is to at least monitor the list so that they're aware of what's going on.  If they see there's a discussion about a spec that would be relevant to their project, they can decide what if anything their project wants to do about it (which could well include ignoring it, which is totally fine).

That's actually one reason why having WGs form early, rather than some informal -interop group elsewhere that only comes to FIG at the end, is a good thing.  It provides *visibility* into the conversation if it is here, where we have an explicit gathering of projects that may have a stake in the outcomes.  In other words, the awareness point you raise is precisely why formal working groups is better than "please do something elsewhere before talking to us".

That does of course presume that a project rep is bothering to read the list and keep abreast of what's going on.  If someone doesn't even have the capacity to do that much, then the project needs to pick a new rep.  Waiting until a spec is done and polished and just waiting on a final vote to make sure projects know what is going on is completely and utterly backward.

The other point is ensuring (appropriate) influence on a spec (for some definition of appropriate).  In this case, the formation of a Working Group is the initial trigger of "hey, this is happening, if you want to get involved this is the time".  Projects can then, if they choose, get involved either as members of the Working Group or as just people commenting.

Just as now, there is absolutely no requirement that someone be part of a Working Group to contribute.  Everyone is welcome to participate in the discussion of a spec today, even if they're not the Editor, Sponsor, or Coordinator.  That wouldn't change.  The WG members are those actively building the spec, probably making trial implementations, etc.  But that doesn't mean others are excluded, and their time spent reviewing and commenting is absolutely valid.

And, importantly, projects can say "we want to be actively involved here, not just passively involved", and they are by-default accepted as part of the WG; and not just the project rep.  If, say, Drupal wanted an "active seat" on a rebooted PSR-5 (documentation), I would not take that myself.  I would invite our documentation lead, Jen Hodgdon, to do so, and she would then have a vote as part of the WG provided she remained actively involved.

Certainly it's possible for the WG to blow off someone who is not on the group explicitly.  Humans are humans.  That's one of the reasons the CC is there.  The CC is in a position to call it out if a WG conspicuously ignored input from some circle, and reject a spec if that's the case.

Let me use PSR-15 (HTTP Middlewares) as an example.  There are a minority of current member projects that use PSR-7; there are a minority of current projects that use a middleware design of some variety or another; there are many current projects that do HTTP handling of some variety; There's a lot of overlap in those groups, and the union of them is probably a majority of projects but far short of "everyone".  (Off hand I count ~11, or about one quarter, that I'm fairly certain don't touch HTTP anywhere.)

Today, the official WG is just 3 people (Woody Gilk, Paul Jones, Jason Coward), and, strictly speaking, they could bring a draft all the way to a final vote without ever talking to anyone else but the 3 of them.  (Not that I expect them to do so, but it is on paper possible.)

In the current (FIG 2) model:
* Every project knows that middlewares are being worked on.
* Only two of those people (Editor and Coordinator) technically need to agree on anything, until it's brought to a vote.
* Any individual that wants to can give input, if they know where to do so, but the Editor/Coordinator are under no obligation to listen.
* When the final vote happens, if, for instance, Matthew feels that Zend Framework's needs were totally ignored then he has no recourse other than to yell a lot and try to convince people to vote -1 because of that.  He's unlikely to be successful, as that's one vote among ~40 and weighted equally with those 11 projects that have nothing to do with HTTP, so don't really care.  It's also a 50% vote, which is not a high bar.

With the FIG 3 model:
* Every project would know that middlewares are being worked on.
* Any individual that wants to can give input.
* Any project that wants to be actively involved in its development can get a seat on the WG if they're willing to be actively engaged.
* If Matthew feels ZF has a major role to play in the spec, he or a designate can be part of the WG.  That gives that rep, worst case scenario, one vote among 5-12, I'd estimate.  It's also a 2/3 vote, so it's easier for a WG member who feels the spec is totally off the rails to force the issue.
* The CC can also push back if a spec passes a Readiness Vote but clearly ignored Zend Framework's input.  They're also a 2/3 vote, so again, higher bar needed to verify that the spec took all relevant input into consideration.

That is, under FIG 3 projects have more direct influence, and more checks to avoid being ignored or railroaded, than under FIG 2... *if* they wish to exercise it.  Projects that aren't relevant, or don't want to bother, don't dilute the influence of those that are and do.


I should note that this model also resolves the "people vs projects" question.  Under FIG 2 currently, we are all projects, unquestionably, not people.  At least on paper.  As some keep pointing out, however, that's not entirely true in practice; many to most of us act as people, not projects, much to all of the time.  FIG 3 accepts and acknowledges this, and shifts the emphasis from projects to relevant-domain-experts, which often comes from project involvement.  In that sense it's much more honest.

For instance, Jackalope as a project likely has quite little to add to HTTP Middlewares.  Lukas Smith may.  As may someone else not affiliated with any project, but who nonetheless has more value to add to the spec than say, Phing does as a project.

It's not perfect or bulletproof, certainly.  But it is closer to it, and harder to railroad a spec through, than the current setup.  Note that I am making an implicit assumption here:

Most adult professionals will act like responsible adult professionals most of the time, given a structure that encourages doing so.  The challenge is ensuring the right structure and organization in which to do so.

If we cannot make that assumption, then FIG is totally doomed as is our industry and we should just all go become farmers. :-)

Adam, I hope that addresses your concerns.

(Note: The examples above are for demonstration purposes only and should not be interpreted as casting aspersions on any of those mentioned or implied as examples. )

--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+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/58a05207-101f-4da0-9055-2b7cccc392a0%40googlegroups.com.

[Adam Culp]

Thank you for that LOOOOOOONG explanation Larry, it did carry value once I had time to read it. While the -interop approach you wrote about was not something I was concerned with, the other portions were useful. Thanks for the time spent.

In regards to:

That does of course presume that a project rep is bothering to read the list and keep abreast of what's going on.  If someone doesn't even have the capacity to do that much, then the project needs to pick a new rep.  Waiting until a spec is done and polished and just waiting on a final vote to make sure projects know what is going on is completely and utterly backward.

I would caution that we are all busy, and switching a rep because FIG is not our life with every breath may be extreme. In your description, and others' posts, I'm hearing, "Members who can't keep up should go away." To those who are able to keep up 100% I commend you, but I feel that would be nobody. We all strive to fit FIG into our day-to-day the best we can, because we want to contribute. Therefore I still have my initial concern where things could progress without everybody knowing. However, I'm not sure how we tackle that. I proposed a member project vote because it was the easiest to implement and carry out.

While I'm still not sold that FIG 3.0 is ready without including a member vote as stated, I'm convinced there will never be a "one size fits all" solution...and maybe that's OK. I do feel that overall it is a step in the right direction.

Regards,

Adam Culp

[Larry Garfield]

On 08/11/2016 08:11 AM, Adam Culp wrote:

Thank you for that LOOOOOOONG explanation Larry, it did carry value once I had time to read it. While the -interop approach you wrote about was not something I was concerned with, the other portions were useful. Thanks for the time spent.

In regards to:

That does of course presume that a project rep is bothering to read the list and keep abreast of what's going on.  If someone doesn't even have the capacity to do that much, then the project needs to pick a new rep.  Waiting until a spec is done and polished and just waiting on a final vote to make sure projects know what is going on is completely and utterly backward.

I would caution that we are all busy, and switching a rep because FIG is not our life with every breath may be extreme. In your description, and others' posts, I'm hearing, "Members who can't keep up should go away." To those who are able to keep up 100% I commend you, but I feel that would be nobody. We all strive to fit FIG into our day-to-day the best we can, because we want to contribute. Therefore I still have my initial concern where things could progress without everybody knowing. However, I'm not sure how we tackle that. I proposed a member project vote because it was the easiest to implement and carry out.

I think we've already determined experimentally that asking 40 people to read every message on the list is a losing battle. :-)  Especially when you layer on top of that the discussions that happen elsewhere than here.  That's part of the impetus for the CC/WG split.

Asking 40 people to at least read any email that is tagged "[Proposal]" (or whatever) to indicate a possible new PSR is a much lower barrier, and I think an achievable one.  If they see that and go "Oh, they're talking about a Queue PSR, I don't care about that *wanders off*", that's fine. That's what people seem to be doing now anyway.  I'm suggesting we embrace that fact and not make their lack of time/interest an impediment.

If someone can't keep up with at least those initial proposal threads to know what's been proposed, then yes, that project needs a different representative.  But that's a much lower bar than we have today.

The CC I would expect to be reading everything and staying on top of it; that's a higher expectation than project reps have, and that's OK.  That's what the CC is signing up for, and they know it.

--Larry Garfield

[Larry Garfield]

On 08/11/2016 08:11 AM, Adam Culp wrote:

Thank you for that LOOOOOOONG explanation Larry, it did carry value once I had time to read it. While the -interop approach you wrote about was not something I was concerned with, the other portions were useful. Thanks for the time spent.

In regards to:

That does of course presume that a project rep is bothering to read the list and keep abreast of what's going on.  If someone doesn't even have the capacity to do that much, then the project needs to pick a new rep.  Waiting until a spec is done and polished and just waiting on a final vote to make sure projects know what is going on is completely and utterly backward.

I would caution that we are all busy, and switching a rep because FIG is not our life with every breath may be extreme. In your description, and others' posts, I'm hearing, "Members who can't keep up should go away." To those who are able to keep up 100% I commend you, but I feel that would be nobody. We all strive to fit FIG into our day-to-day the best we can, because we want to contribute. Therefore I still have my initial concern where things could progress without everybody knowing. However, I'm not sure how we tackle that. I proposed a member project vote because it was the easiest to implement and carry out.

While I'm still not sold that FIG 3.0 is ready without including a member vote as stated, I'm convinced there will never be a "one size fits all" solution...and maybe that's OK. I do feel that overall it is a step in the right direction.

Regards,

Adam Culp

Hi all,
In response to earlier discussion, we've added a short section on "Project Referenda" to FIG 3 as more formal way to get feedback from projects on a PSR without them needing to all be part of the Working Group at all times.  This is mainly aimed at very-broad PSRs like PSR-12.

Diff here:

https://github.com/php-fig/fig-standards/pull/752/commits/3fd06bbd924a0a07fb3fe81ab8651511aa07caca

This doesn't affect anything we've previously said about Working Group participation, just adds another feedback loop in cases where it would be useful.

--Larry Garfield