[Review][Discuss] FIG 3.0 Upcoming Vote

1,252 views
Skip to first unread message

Michael Cullum

unread,
Aug 24, 2016, 1:14:17 AM8/24/16
to FIG, PHP
Hi all,

I pulled the vote for FIG 3.0 in order to give people a chance to provide more feedback as people expressed a wish to give it a bit more time. The vote will open on the 10th September.

To quote from my previous post:

Ultimately, if FIG 3.0 is to go through, it's going to be a huge change for the operation of the FIG and the proposal should be just right before putting it to a vote, with no open issues on the proposal itself. Especially now with an alternative option (a new organisation) being prominently discussed (suggested by Joe and Paul), members deserve a fair vote on the future of the FIG with a vote untainted by votes on process issues or resolvable unresolved content issues and with a proposal that is solid with any issues and feedback addressed. The vote will then essentially become a case of do you want the FIG group to transition to the new structure (dubbed FIG 3.0), or should other options be followed (e.g. Shutting down FIG in favor of a new organization following FIG 3, changing nothing etc.).
 
I'd stress that feedback is really important to the proposal and it's still of course open for changes based on feedback such as when referenda was added to the proposal.

The TL;DR of FIG 3.0 can be found here.

The specs diff can be found in the PR, or you can just read through the new bylaws here or you can just view the bylaws as is (without viewing as a diff) here.

If you have any questions about the spec or wish to discuss points further, feel free to post here or create a new topic prefixed [FIG 3.0].

--
Michael C

Paul Jones

unread,
Aug 28, 2016, 4:07:54 PM8/28/16
to php...@googlegroups.com

> On Aug 24, 2016, at 00:13, Michael Cullum <m...@michaelcullum.com> wrote:
>
> Hi all,
>
> I pulled the vote for FIG 3.0 in order to give people a chance to provide more feedback as people expressed a wish to give it a bit more time. The vote will open on the 10th September.

I'll say it again: this proposal is effectively a re-constitution of the FIG, and is better suited to an entirely new organization.

Further, this vote leads in only one direction: more contention. Whether it passes or fails, the different sets of vision holders will continue to champion their opposing causes.

If the vote fails, the "grand" vision holders will continue to try to pass it in other ways. If it passes, the "founding" vision holders will try to roll it back. (Indeed, I am interested in rolling back some of the more recent changes, such as the over-empowering of secretaries, if not the position itself.)

One way out of this contention is for one of visions is explicitly and permanently retract itself. But neither do I expect to retract the "founding" vision, nor do I expect Larry & Michael (et al.) to retract the "grand" vision. (If they do, so much the better for the group and its way-of-working.)

The only other way out is for the group to dissolve, its mission being largely accomplished, and now experiencing scope-creep. Disband the group; let there be an archivist appointed to safeguard the FIG name and the finished PSRs; encourage *-interop projects to form in the FIG's place; and if Larry & Michael (et al.) wish to start a new group based on FIG 3.0, they can do so without a pre-existing FIG as competition.


--

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

Michael Cullum

unread,
Aug 29, 2016, 4:57:10 AM8/29/16
to FIG, PHP
Paul,

The intention of the vote is that it will resolve contention, not create it; and this should be the case so long as people don't intend to create drama as a result of the vote. Right now there is contention of ideas as to what the FIG is about and FIG 3.0 is a proposal to resolve that, as are other proposals. It is up to the member projects to decide if they wish the FIG to transition into FIG 3.0 or not. If the vote fails, then voting members will have spoken they do not wish the FIG to transition into FIG 3.0 and would prefer other options (dropping the idea of any change all together, FIG 3.0 in it's own organisation in a similar or different manner to that which you suggest). On the other hand, if it passes, then member projects will have decided that they would prefer the FIG to transition.

It is not up to you, Larry, myself or any other single individual to define what the FIG 'is' or 'should be' or 'is not'. It is up to the member projects to decide by majority vote, as is our way.

--
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/569E1E9F-C321-4F55-B063-9BE28F6628FE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

GeeH

unread,
Aug 29, 2016, 11:50:28 AM8/29/16
to PHP Framework Interoperability Group
I have a few points I'd like to raise here - thanks to all involved in pull vote this time around. Obviously, all of the below comments are my opinions, and should be taken as such.


## Mission Statement


I really dislike it. I would prefer something short and catchy than this statement which I think is woolly and doesn't really tell anyone anything. I would prefer something like "Promoting good standards in PHP", something short that immediately tells people what this new FIG is about, rather than I don't think the mission statement needs to worry about how the mission is achieved (others will disagree here, and that's fine). This is the kind of overwritten statement I've come to hate.


## Secretaries


- Acting throughout their term essentially as Developer Advocates for the PHP FIG
I believe the this is out of the scope of a secretary of the FIG, and should be removed, I see no need for a competent secretary to submit talks on the FIG, blog about it, or promote it in any way.

I would also like to see some accountability added into the secretaries role so that phrases like "we have been dealing with this behind the scenes" become a thing of the past. I'd like to see publically visible records of email chains sent by the secretaries on behalf of the FIG, and records of other conversations. While this may seem like we are not trusting the secretaries, it's certainly not a matter of trust for me. It's a case of everyone being able to see exactly what is going on, so efforts are not duplicated, and surprises are never seen when discussions are raised on this list. If secretaries are having discussions on the interpretation of a bylaw, for example, that discussion should be visible to the members they represent in my opinon.


## Working Groups
### Sponsors
"A PSR must be sponsored by a member of the Core Committee."
Why? Only 12 people can be sponsors of PSRs? Why can't member projects sponsor PSRs anymore? I don't understand what this brings to the table apart from shrinking the pool of people who may sponsor a PSR.

## Votes
"A secretary may trigger any type of vote if appropriate and necessary."
I disagree, only Core Committee members and Project Representatives should be able to call a vote after the mandatory discussion period. I would like to see all votes have a mandatory two week minimum discussion period marked with a set titled thread such as [Discussion].


Overall
I'm undecided, this still doesn't feel like a great idea to me, but I have nothing better to offer and accept that something needs to change. I'm particularly worried about the Core Committee, basically, the 12 most popular people will be voted into a position of power in the FIG, and under the current implementation, only those 12 will be able to sponsor a PSR. This feels confusing to me. It also feels that the member projects take a big back-seat role then, only able to vote in secretaries and core committee members. Of course, this doesn't preclude them from being involved in working groups at all, but really their job is only to decide who staffs the various roles if I'm reading this right (on second reading, that might be a good thing). I also think that two years seems like a hell of a long period for someone to be voted onto the core committee - I would prefer to see this reduced to a maximum of one year. 

I may have missed it, but there doesn't appear to be anywhere that regulates the location that working groups should have discussions. I'm all for letting the working groups have their own communication methods, but it should be public and have a historical record somewhere for everyone to read. It should also be made clear where discussions take place on the website (or in the README of the PSR) so finding these places are easy, and anyone can later read what discussion happened. Let's take this opportunity to get more transparency all around.

Kudos to Larry and Michael for all the hard work you both did in getting this to the table.

Dracony

unread,
Aug 30, 2016, 5:06:21 AM8/30/16
to PHP Framework Interoperability Group
I wholeheartedly agree with Garry. 

It seems like the main idea behind FIG 3.0 is just shaving off the member projects to leave the 12 most popular people  ( yes, people, not projects). When voting for the core commitee people will be thinking primarily about which people they trust the most to run it, not which projects should be there. This obviously puts the whole "it's projects that are members" idea on a back seat. The point of the proposal is simple, getting rid of the "cruft". It would be way less PR-friendly to just outright try to kick away all the small members from the FIG, so instead this "restructuring" is proposed. Just like big companies call huge layoffs "reorganization".

I took the time to read the FIG 3 proposal again, and ultimately it is a "secretary-cracy". The core commitee pretty much becomes the all-powerful secretary. 


Overall I also start to feel that secretaries are getting more power with the new approach, which is weird really.

Alessandro Lai

unread,
Aug 30, 2016, 9:59:49 AM8/30/16
to PHP Framework Interoperability Group
I agree that maybe not restricting sponsorship to the core committee can be a good idea, at least to release them from an other burden: it's a heavy duty role as it is.

I don't agree about the "secretaries" gettin more powers. The TLDR and the bylaw changes indicates more than once that the secretaries will have the same duties and powers that they have now, and more than once it stresses that they ultimately serve the FIG, and they have to respond to them.

Larry Garfield

unread,
Aug 31, 2016, 11:26:15 AM8/31/16
to php...@googlegroups.com
On 08/29/2016 10:50 AM, GeeH wrote:
> I have a few points I'd like to raise here - thanks to all involved in
> pull vote this time around. Obviously, all of the below comments are
> my opinions, and should be taken as such.
>
>
> ## Mission Statement
>
>
> I really dislike it. I would prefer something short and catchy than
> this statement which I think is woolly and doesn't really tell anyone
> anything. I would prefer something like "Promoting good standards in
> PHP", something short that immediately tells people what this new FIG
> is about, rather than I don't think the mission statement needs to
> worry about how the mission is achieved (others will disagree here,
> and that's fine). This is the kind of overwritten statement I've come
> to hate.

A mission statement should be concise, I agree, but not so short that it
is meaningless. It defines scope, and a metric by which we can judge
whether our actions are "in scope". "Promote good standards" doesn't
really help define scope. The proposed mission is 3 sentences, which is
shorter than many I've seen. :-)

How would you suggest shortening it, while still keeping the essence
intact? (promote good standards, collaborate, publish PSRs, based on a
combination of old and new.)

> ## Secretaries
>
>
> - Acting throughout their term essentially as Developer Advocates for
> the PHP FIG
> I believe the this is out of the scope of a secretary of the FIG, and
> should be removed, I see no need for a competent secretary to submit
> talks on the FIG, blog about it, or promote it in any way.

This is included in the bylaws around the Secretary role now. We left
that essentially intact as changing the secretary role we considered
mostly out of scope.

That said, I could see that role as less relevant with the CC, who could
easily serve the same role. With a more focused set of people involved
the need for specific dev advocates is smaller, as (presumably) many CC
members would also be submitting sessions and talking up FIG and
advocating for collaboration and such.

I'm open to removing that clause if others are.

> I would also like to see some accountability added into the
> secretaries role so that phrases like "we have been dealing with this
> behind the scenes" become a thing of the past. I'd like to see
> publically visible records of email chains sent by the secretaries on
> behalf of the FIG, and records of other conversations. While this may
> seem like we are not trusting the secretaries, it's certainly not a
> matter of trust for me. It's a case of everyone being able to see
> exactly what is going on, so efforts are not duplicated, and surprises
> are never seen when discussions are raised on this list. If
> secretaries are having discussions on the interpretation of a bylaw,
> for example, that discussion should be visible to the members they
> represent in my opinon.

While I can appreciate the spirit here, I am very skeptical about
forbidding non-public conversation. It's often extremely useful for
people to talk privately to diffuse a situation, or handle something
that is mundane and boring. I would hate to see regular IRC chat logs
dumped onto the list; that's just meaningless noise. And if I knew I
couldn't talk to a Secretary without the conversation becoming part of
the public record, well... I would never talk to a Secretary, which is a
pretty terrible situation to be in.

And what of CC members? Should they be disallowed from having private
conversations, too? Once again, that's an excellent way to ensure the
job can't be done correctly.

I've found, repeatedly, that having an "audience" is the best way to
ensure that people are NOT reasonable. When people have an audience,
they feel the need to "stand their ground" more, defend their position,
and in a sense "perform". Forced-public logs also encourages shaming,
or discouraging people from discussing sensitive matters if they fear
public embarrassment (rightly or wrongly).

Basically, forbidding private conversation castrates the ability of
someone to do their job.

So what level of "reporting" by the Secretaries would be needed, while
still respecting the very real need to allow humans to have private
conversations when appropriate?

> ## Working Groups
> ### Sponsors
> "A PSR must be sponsored by a member of the Core Committee."
> Why? Only 12 people can be sponsors of PSRs? Why can't member projects
> sponsor PSRs anymore? I don't understand what this brings to the table
> apart from shrinking the pool of people who may sponsor a PSR.

One of the goals of FIG 3 is to shift the workload from 40-ish people
who are by and large not paying attention to a dozen people we can
require to pay attention because that's explicitly their job. Yes, this
does reduce the importance of projects in favor of the elected Core
Committee, who is chosen by those active in FIG matters generally, not
just project leads. That's deliberate and by design, because the
correlation between "is the owner of a project on GitHub that someone is
using" and "has the time, energy, skill, and temperament to design,
review, and coordinate standards" is, as we've seen, extremely weak.

As we have only 8 Coordinators now (as the current Sponsor and
Coordinator basically fold together into a single role in FIG 3), I
don't think that's really a problem in terms of availability.

> ## Votes
> "A secretary may trigger any type of vote if appropriate and necessary."
> I disagree, only Core Committee members and Project Representatives
> should be able to call a vote after the mandatory discussion period. I
> would like to see all votes have a mandatory two week minimum
> discussion period marked with a set titled thread such as [Discussion].

We deliberately avoided specifying the mechanics of specific list
subject lines, and in fact removed a few. With the active discussion of
splitting the list into multiple lists (which I personally support) or
switching to a forum (which I do not support) and so on, it seemed wise
to leave those mechanics to be defined by the secretaries as needed.

That said, I'm totally open to adding a requirement that most votes
should have a 2 week notice before they start. (I don't think a
Referendum needs one, for instance.) The caveat there being that,
basically, *nothing* gets done in less than a month. (2 week
discussion, 2 week vote.) Are we OK with that implication?

Michael felt strongly about Secretaries being able to call a vote on
FIG's behalf, so I will let him respond to that point. (Although he's
traveling at the moment so may not be quick about it.)

>
> Overall
> I'm undecided, this still doesn't feel like a great idea to me, but I
> have nothing better to offer and accept that something needs to
> change. I'm particularly worried about the Core Committee, basically,
> the 12 most popular people will be voted into a position of power in
> the FIG, and under the current implementation, only those 12 will be
> able to sponsor a PSR. This feels confusing to me. It also feels that
> the member projects take a big back-seat role then, only able to vote
> in secretaries and core committee members. Of course, this doesn't
> preclude them from being involved in working groups at all, but really
> their job is only to decide who staffs the various roles if I'm
> reading this right (on second reading, that might be a good thing). I
> also think that two years seems like a hell of a long period for
> someone to be voted onto the core committee - I would prefer to see
> this reduced to a maximum of one year.

As noted above, yes, the intent is to shift the focus from projects to
the CC and Working Groups. In a sense, we're putting the emphasis on 12
"Community Reps" (Cal's old job) rather than project reps in particular.

The tension between "people and projects" is still unresolved in
practice, despite the bylaws having resolved it years ago. Project reps
today are *supposed* to be just a representative of their project, but
as PMJ likes to point out at every opportunity that doesn't stop most
people from voting on the applying person, not the applying project.

And to be fair, as noted earlier, the skill-set of "represent the
interests of my project" and "ensure a high level of quality and
consistency across a variety of specs" are not always the same. In fact
they're frequently different, and someone being good at one doesn't mean
they'd be any good at the other, or vice versa. And there are plenty of
people who would be excellent for the CC that are not affiliated with a
particular project. The current effective filter that "you're only cool
enough if you're a project lead, and if you're a project lead you must
be cool enough" is in practice a very bad one. :-)

The result is that it's already effectively a popularity contest, just
with a project flag waving behind it. That's the status quo.

FIG 3 decouples "project lead or their proxy" from "qualified and
trusted to pay attention to and reviewing every spec in detail". That
resolves the "people vs project" question by splitting it in half;
project reps can genuinely be about the project, and CC members can
genuinely be about the person.

I will also note project reps are explicitly allowed to also be on the
CC. That's deliberate. If someone is up to the task of both, and is
comfortable wearing both hats, so be it. In practice, I expect
somewhere around half of the CC will also be project reps. I am
entirely OK with that.

As for the length of the term, we wanted to have a stagged term like
secretaries do and for the same continuity reasons. We also didn't want
too short a term, as then we'd spent all our time having elections.
(Remember, elections are a month long process.) One election every 8
months seems about as frequent as I think we can stomach, which gives a
2 year term. The logic is the same as for secretaries. I don't know
how to shorten it without making CC members spend all their time
thinking about the next election, even in the most benevolent way.
(Think Senate vs House of Representatives, for the United Statesians in
the audience.)

> I may have missed it, but there doesn't appear to be anywhere that
> regulates the location that working groups should have discussions.
> I'm all for letting the working groups have their own communication
> methods, but it should be public and have a historical record
> somewhere for everyone to read. It should also be made clear where
> discussions take place on the website (or in the README of the PSR) so
> finding these places are easy, and anyone can later read what
> discussion happened. Let's take this opportunity to get more
> transparency all around.

You didn't miss it; we didn't address that part directly. The closest
there is would be this clause:

" The Secretaries will ensure that the Working Group is provided with
necessary resources to work on the specification, such as a dedicated
GitHub repository, mailing list, forum section, and similar such tools."

The intent of which is to explicitly allow Git repos in the FIG GitHub
organization, extra mailing lists, etc. Something to keep it under the
FIG umbrella, where there is (hopefully) more visibility.
Micro-specifying how WGs work internally didn't seem wise at this point,
although I fully agree that we should be nudging them toward more
discoverable mechanisms. (A list per PSR, or cluster of related PSRs
like 15 and 17, would be my preference but I know others disagree.)

Further refining the WG workflow seems like something we should
follow-up on later, once the dust has settled a bit.

> Kudos to Larry and Michael for all the hard work you both did in
> getting this to the table.

Thanks!

--Larry Garfield

Paul Jones

unread,
Sep 5, 2016, 12:37:21 PM9/5/16
to php...@googlegroups.com
Michael,

> On Aug 29, 2016, at 03:56, Michael Cullum <m...@michaelcullum.com> wrote:
>
> The intention of the vote is that it will resolve contention, not create it; and this should be the case so long as people don't intend to create drama as a result of the vote.

The proposal, and the vote, themselves create "drama." I assert there can be nothing *but* "drama" as the result of this proposal, and the ensuing vote. Of course, if avoiding drama is a key point, the proposal can be withdrawn at any time.


> Right now there is contention of ideas as to what the FIG is about and FIG 3.0 is a proposal to resolve that, as are other proposals.

The contention arises from you and Larry (and perhaps others) who want to re-constitute the FIG *in toto* and *in situ*, to conform to a new vision of your own, rather than to incrementally perfect an expression of the existing founding vision. Without the proposal, there is no contention. You and Larry are the ones who have brought the contention here.


> It is up to the member projects to decide if they wish the FIG to transition into FIG 3.0 or not.

You, and Larry, and any member projects that agree with you, can "transition into FIG 3.0" right now, by resigning and starting a new group with a new name. Doing so will leave here all those who support the founding vision, to pursue that vision unperturbed. You all, for your part, can pursue your new-and-different vision in your new-and-different group in any way you like.

Michael Cullum

unread,
Sep 8, 2016, 4:34:56 PM9/8/16
to FIG, PHP

As I was directly addressed and asked to respond to some points, I'll respond here but as noted previously, I'm not speaking in a secretarial capacity.


N.B When I refer to ‘FIG Member’ I mean people with voting rights essentially, so depending on the context either core committee members and member projects (FIG 3.0 context) or just member projects (FIG 2.0/status quo context).


On the note of giving secretaries more powers, I'd note the only real change at all was we restricted the previously much too open "Clarifying any interpretation of bylaw text" to what it is now (See https://github.com/php-fig/fig-standards/pull/752/files#diff-b58538881047f8ede6b65a2ca2e01261R58 and https://github.com/php-fig/fig-standards/pull/752/files#diff-b58538881047f8ede6b65a2ca2e01261R64). There was no addition of 'powers', just a restriction on them added.


Larry has touched on this note briefly but I'll reiterate, with regards to working group discussions, as Secretaries we'd be working to ensure that discussions took place on *a medium* that is well publicised and we're working towards this already with the current PSRs but we didn't want to micromanage this in the bylaws.


Regarding secretaries being able to start any vote, this isn't a change from the status quo. Larry and I discussed this and ultimately, just because the secretaries have an ability, it doesn't mean they should always be using it, but it's possibly better for them to be able to than have to face potential bureaucratic tanglement later on (this was my rationale for not removing the current blanket statement). In addition to just being an ability in case it is needed, there are also a number of times when it makes sense for secretaries to be able to open votes as standard, for example:

  • If a bylaw clarification needs doing and we ascertain it's beyond the remit of secretaries

  • For clearing up misc. items such as the vote about 11 months ago to remove translations

  • When a bylaw amendment vote that affects the contents of PSRs is requested by a PSR Editor who cannot open a vote (Interface suffix)


It's important here to note that a Secretary opening a vote doesn't mean they are advocating for the change either, it just means they want members to make a decision on something through a vote, and the ability to be able to defer things to members is important as secretaries - it's like passing a decision up to your boss at work because you know it's not your call. I think this ultimately comes down to do you trust Secretaries to not do stupid things (or if they do, realise this, apologise and reverse it), and if you don't, then recall votes should be used or you shouldn't elect them in the first place.


On 5 September 2016 at 17:37, Paul Jones <pmjo...@gmail.com> wrote:

Michael, 

The proposal, and the vote, themselves create "drama." I assert there can be nothing *but* "drama" as the result of this proposal, and the ensuing vote. Of course, if avoiding drama is a key point, the proposal can be withdrawn at any time. 
The contention arises from you and Larry (and perhaps others) who want to re-constitute the FIG *in toto* and *in situ*, to conform to a new vision of your own, rather than to incrementally perfect an expression of the existing founding vision. Without the proposal, there is no contention. You and Larry are the ones who have brought the contention here. 
You, and Larry, and any member projects that agree with you, can "transition into FIG 3.0" right now, by resigning and starting a new group with a new name. Doing so will leave here all those who support the founding vision, to pursue that vision unperturbed. You all, for your part, can pursue your new-and-different vision in your new-and-different group in any way you like.

The contention exists from the general utterances about what a number of people have identified as general problems in the FIG. FIG 3.0 aims to fix a number of those 'problems' and it was neither me nor Larry that started these discussions back in January (or before; these discussions have circulated for years as we all know) about changes to FIG structure nor initially raised many of these comments. We just researched PEP, IETF etc. (as others had suggested) and helped put those suggestions into the text of a series of bylaw changes.


Contention does not have to mean drama though and it will only be made so if people insist on making it so; contention and disagreement can be healthy for a standards body (as you've regularly pointed out), so long as it is not done in a detrimental fashion. FIG 3.0 will go to a vote, as the decision for what to happen to the FIG is neither Larry's nor yours as no one person controls the FIG; the entire body of member projects do. I'd ask you have respect for that sovereignty; after all, you wrote the voting protocol that essentially defines that sovereignty. If member projects wish it to be a separate organisation, that's entirely fine, but they deserve a chance to vote on it, as I think these topics on the mailing clearly show that some or many people disagree with you. It’s not democratic in the slightest to prevent a vote from even taking place, and nobody has the power to do so, so lets stop beating the same bush and just proceed. People can make their relevant cases and people can discuss what they think is best, a vote can take place [as is our way], and then move on from there.


--

Many thanks,

Michael C


N.B. I do not post this message as a secretary but as a co-author of a spec and the person who compiled the secretary job description initially in the bylaws to explain why things were written as they were, but not to advocate for them. I do this in line with my declared conflicts of interest.


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

Larry Garfield

unread,
Sep 9, 2016, 10:01:21 PM9/9/16
to php...@googlegroups.com
Notice: Based on Gary's feedback, we've made a few small-ish changes to the FIG 3 PR:

1) Tightened up the language of the mission statement.  It still says essentially the same thing but with fewer words.  (Largely based on input from Gary off list.)

https://github.com/michaelcullum/fig-standards/compare/3fd06bbd924a0a07fb3fe81ab8651511aa07caca...c28f8dbf7bd908c01fa3012eb6c98c5144f9002c

2) Added a recommended 2 week discussion period for "non-trivial" votes.  It's not a hard requirement, but it formalizes the "unwritten rule that we should usually have one" into a written rule that we should usually have one. :-)

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

I don't expect either of these to be controversial, but just to be safe I will let it sit a few more days before calling the vote.  Constructive feedback still welcome.

--Larry Garfield


On 09/08/2016 03:30 PM, Michael Cullum wrote:

Alessandro Lai

unread,
Sep 10, 2016, 6:07:23 PM9/10/16
to PHP Framework Interoperability Group
Good job! I really like the edits on the opening statement, it's more short while retaining its meaning.

GeeH

unread,
Sep 12, 2016, 10:40:35 AM9/12/16
to PHP Framework Interoperability Group
Thanks Larry, we had a good discussion off the list, I'd like to quickly summarise here for the rest of the list.

1. Mission Statement - I proposed alternate and that PR has been merged by MC - thank you, I think it's a good improvement.
2. Secretaries as Developer Advocates - you make a good point but it doesn't change the fact I think this requirement for the role is not important and should be removed.
3. Secretary Transparency - I agree, you make a very good argument and I realise I was guilty of trying to make something that is completely unrealistic. I would still like to see more transparency for secretaries, but I conceded that what I said there was great in theory, but complete nonsense in practice.
3. CC Only Can Sponsor - I'm still not convinced but as this is the crux of the entire FIG 3.0 proposal and I don't have anything better, I'm all for giving it a go.
4. Secretaries Calling Votes - I'm definitely against this, but it's not important enough to delay a vote or sway me to pushing ZF for a -1. It's a minor point at best. I really don't want to cause more drama but it still feels weird that a secretary was all for secretaries being able to call votes. This is why I find it odd that a serving secretary has such a high hand in outlining the role that person will have should this vote pass.

It leaves me to say once again thank you to LG and MC for all their hard work. I want to re-iterate what I said to Larry in private, my comments were meant to be nothing but constructive, it's difficult to ask questions and make negative comments on the list at the moment because you risk being tarred with the same brush that other people are, but I hope that criticism will always be welcome on the list and will be discussed in a polite and professional way (the way Larry did when replying to me).

Paul Jones

unread,
Sep 12, 2016, 11:52:09 AM9/12/16
to php...@googlegroups.com
Hi all,

Larry & Michael, is the "Secretary" role intended primarily as that of "assistant", subordinate to the Voting Members, or is it intended more along the lines of "Secretary-General" or "Secretary of (Parliament|State|etc)" ? Since they are very different things, the title should reflect the intent appropriately, and currently it does not.

Michael Cullum

unread,
Sep 12, 2016, 11:56:59 AM9/12/16
to PHP FIG

The Secretary role is not changing in FIG 3.0 as previously stated.

--
Michael


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

Paul Jones

unread,
Sep 12, 2016, 12:22:28 PM9/12/16
to php...@googlegroups.com

> On Sep 12, 2016, at 10:56, Michael Cullum <m...@michaelcullum.com> wrote:
>
> The Secretary role is not changing in FIG 3.0 as previously stated.

And what role is that, exactly? Assistive, or more along the lines of "Secretary-General" or "Secretary of (Parliament|State|etc)" ?

Pedro Cordeiro

unread,
Sep 12, 2016, 12:32:40 PM9/12/16
to PHP Framework Interoperability Group
Paul, the role of a secretary is well described here, as I'm sure you are aware: http://www.php-fig.org/bylaws/membership/#fig-secretary.

Paul Jones

unread,
Sep 13, 2016, 10:38:55 AM9/13/16
to php...@googlegroups.com

> On Sep 12, 2016, at 11:32, Pedro Cordeiro <pedro...@gmail.com> wrote:
>
> Paul, the role of a secretary is well described here, as I'm sure you are aware: http://www.php-fig.org/bylaws/membership/#fig-secretary.

Yes, it's *described* there, but nobody seems to be able to say what *kind* of secretary is described. Based on the ZendCon meeting summary (the meeting at which the idea for the role was first raised), it was originally more "assistive" and "record-keeper" in nature:

https://groups.google.com/d/msg/php-fig/pxezV88Uk1I/eW3GvtPRCgAJ


> ### New FIG Role: Secretary
>
> The secretary role would serve several functions:
>
> - Keeping the website up-to-date, including merging pull requests.
> - GitHub organization administration (assigning people to teams, removing people
> from teams, etc.). Specifically, this would involve providing editors and
> coordinators of proposals commit access prior to a proposal being accepted or
> rejected, and removing commit access once a proposal is complete (unless a
> member is also involved in other active proposals).
> - Tallying votes.
> - Tracking member project activity, and marking projects as inactive.
>
> The role will be filled by 3 people, to ensure that at least one person is
> always available in a timely manner. Additionaly, to remove partiality, the role
> would be restricted to:
>
> - non-voting members of FIG;
> - members not actively involved in a current proposal (i.e., you cannot be an
> editor of a proposal AND fulfill the role of secretary).
>
> Not discussed:
>
> - duration of service. (i.e., does service terminate after a fixed duration?)
> - eligility (are secretaries proposed? or do they volunteer?)
> - election (is an entrance vote required?)
>
> Joe Ferguson, who was present, volunteered for the role of Secretary.

But referring to it now as "assistive" and or "record-keeping" role seems to meet with resistance and defensiveness.

Since the word "secretary" has multiple meanings, that makes the title rather ambiguous. In the interest of reducing ambiguity, and making sure the powers of the role fit an unambiguous title, I would love some clarification on exactly what *kind* of secretary we have. Is it really the "assistive/record-keeping" secretary, or is it more like something else? If so, exactly what "something else" is it like?

When asking this question to Michael Cullum over the weekend, in an on-the-record conversation, he replied as follows (in his typical lengthy fashion):

> Secretary does not just mean assistant.
>
> The Secretary-General of the UN, or a Secretary of State are leadership positions; a Parliamentary Secretary is a civil service position which runs the day-to-day of a government department and is responsible to government, but is politically impartial; a Parliamentary Private Secretary is an MP (Member of Parliament, our congressmen) who works with a minister as a liaison between the minister and backbenchers (MPs who are not part of the government but are in the majority/government party); a Parliamentary Under Secretary of State is subordinate to the Secretary of State but is an MP with a smaller brief that they can focus on, reporting to their SoS; a Secretary of a club or society is a mix of a leadership position (they are a club officer and normally considered a very senior one, and the person legally responsible for the actions of the club or society) but also administrative duties as you describe; and of course, the way you describe it, as a PA type role.
>
> The point I'm trying to make is that is is a simple fact that the title Secretary can mean a huge variety of things, some considerably more authoritative than that which the role of FIG Secretaries is, some are more solely administrative (I'd note the term 'Administrator' has very similar variance in meaning also). You seem to put a lot of value in the naming of the role; in fact, your last email indicates this is the *most important* thing to you. Might I ask why?
>
> So I do name the role, and I name it Secretary. If you wish to add other titles onto this such as Developer Advocate, PR *, Administrative *, Moderator, Administrator, Social Media *, with * indicating that manager or assistant could be used interchangeably, then you may if that makes you feel like you better understand the role. Just like the startup industry, where titles mean relatively little because they are a small number of people filling a large number of roles, so everyone in the company calls themselves a 'Director of XYZ', the same is applicable here. It is not the title that is necessarily important, but the actions, role and responsibilities.
>
> https://en.wikipedia.org/wiki/United_States_Secretary_of_State
> https://en.wikipedia.org/wiki/Secretary_of_State_(United_Kingdom)
> https://en.wikipedia.org/wiki/Permanent_Secretary
> https://en.wikipedia.org/wiki/Secretary-General_of_the_United_Nations
> https://en.wikipedia.org/wiki/Parliamentary_Private_Secretary
> https://en.wikipedia.org/wiki/Parliamentary_Under-Secretary_of_State
> https://en.wikipedia.org/wiki/Private_Secretary_to_the_Sovereign
> https://en.wikipedia.org/wiki/Private_Secretary
> https://en.wikipedia.org/wiki/Company_secretary
> https://en.wikipedia.org/wiki/Secretary_(title)
> https://github.com/php-fig/fig-standards/blob/master/bylaws/003-membership.md#overarching-role

I admit I am unsettled by the idea that somehow the secretaries are seen by Michael, who wrote the role description that has been voted in, as anything even remotely resembling a Secretary-General or a Director. Certainly that was not the impression I had when I voted +0 on the role; if I'd had that impression, I'd have voted -1 and raised objections.

So again, I ask: of those many kinds of secretaries, exactly which one(s) describe the secretarial role here in FIG?

Chris Tankersley

unread,
Sep 13, 2016, 10:59:50 AM9/13/16
to php...@googlegroups.com
And that was used as a basis for the current form of the Secretary:


The duties of the secretary are clearly laid out, regardless of "what type" of secretary they are. This was a vote that you participated in by a +0 vote. 
 

But referring to it now as "assistive" and or "record-keeping" role seems to meet with resistance and defensiveness.

Since the word "secretary" has multiple meanings, that makes the title rather ambiguous. In the interest of reducing ambiguity, and making sure the powers of the role fit an unambiguous title, I would love some clarification on exactly what *kind* of secretary we have. Is it really the "assistive/record-keeping" secretary, or is it more like something else? If so, exactly what "something else" is it like?

When asking this question to Michael Cullum over the weekend, in an on-the-record conversation, he replied as follows (in his typical lengthy fashion):

> Secretary does not just mean assistant.
>
> The Secretary-General of the UN, or a Secretary of State are leadership positions; a Parliamentary Secretary is a civil service position which runs the day-to-day of a government department and is responsible to government, but is politically impartial; a Parliamentary Private Secretary is an MP (Member of Parliament, our congressmen) who works with a minister as a liaison between the minister and backbenchers (MPs who are not part of the government but are in the majority/government party); a Parliamentary Under Secretary of State is subordinate to the Secretary of State but is an MP with a smaller brief that they can focus on, reporting to their SoS; a Secretary of a club or society is a mix of a leadership position (they are a club officer and normally considered a very senior one, and the person legally responsible for the actions of the club or society) but also administrative duties as you describe; and of course, the way you describe it, as a PA type role.
>
> The point I'm trying to make is that is is a simple fact that the title Secretary can mean a huge variety of things, some considerably more authoritative than that which the role of FIG Secretaries is, some are more solely administrative (I'd note the term 'Administrator' has very similar variance in meaning also). You seem to put a lot of value in the naming of the role; in fact, your last email indicates this is the *most important* thing to you. Might I ask why?
>
> So I do name the role, and I name it Secretary. If you wish to add other titles onto this such as Developer Advocate, PR *, Administrative *, Moderator, Administrator, Social Media *, with * indicating that manager or assistant could be used interchangeably, then you may if that makes you feel like you better understand the role. Just like the startup industry, where titles mean relatively little because they are a small number of people filling a large number of roles, so everyone in the company calls themselves a 'Director of XYZ', the same is applicable here. It is not the title that is necessarily important, but the actions, role and responsibilities.
>
> https://en.wikipedia.org/wiki/United_States_Secretary_of_State
> https://en.wikipedia.org/wiki/Secretary_of_State_(United_Kingdom)
> https://en.wikipedia.org/wiki/Permanent_Secretary
> https://en.wikipedia.org/wiki/Secretary-General_of_the_United_Nations
> https://en.wikipedia.org/wiki/Parliamentary_Private_Secretary
> https://en.wikipedia.org/wiki/Parliamentary_Under-Secretary_of_State
> https://en.wikipedia.org/wiki/Private_Secretary_to_the_Sovereign
> https://en.wikipedia.org/wiki/Private_Secretary
> https://en.wikipedia.org/wiki/Company_secretary
> https://en.wikipedia.org/wiki/Secretary_(title)
> https://github.com/php-fig/fig-standards/blob/master/bylaws/003-membership.md#overarching-role

I admit I am unsettled by the idea that somehow the secretaries are seen by Michael, who wrote the role description that has been voted in, as anything even remotely resembling a Secretary-General or a Director. Certainly that was not the impression I had when I voted +0 on the role; if I'd had that impression, I'd have voted -1 and raised objections.

So again, I ask: of those many kinds of secretaries, exactly which one(s) describe the secretarial role here in FIG?



--

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



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

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



--
Chris Tankersley
http://ctankersley.com

Gary Hockin

unread,
Sep 13, 2016, 11:08:58 AM9/13/16
to php...@googlegroups.com
Paul,

I hope I speak for many when I say that your constant nitpicking is becoming increasingly tiresome. I understand that you feel that the secretaries are working outside of the boundaries of the tasks and duties that they were voting in to fulfil. Other voting members on this list disagree with you -- this is fine, discussion and disagreement is important and is the cornerstone of how this group achieved the many standards that are now in wide use in the industry. It's becoming frustrating to me to continuously read in various mediums your questioning of the secretaries roles, so might I suggest you propose an amendment to the bylaws that clarifies the role of a secretary in a manner you think is correct, and then open a discussion and then a vote on those amendments? This will allow this matter to be finally put to rest and let the group move on to pastures new.

Gary

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.



--
Chris Tankersley
http://ctankersley.com

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/mW3CDX_rIuw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

Tom Etzel

unread,
Sep 13, 2016, 10:38:07 PM9/13/16
to PHP Framework Interoperability Group
Paul keeps asking the same question over and over again. Why are you all so reluctant to just answer his question? Seriously... Just explicitly answer his question. The secretary is an "assistive/record-keeping" or the secretary is fill_in_the_blank. You want the guy to stop asking, but nobody will just flat out answer him. Instead you all post links to crap, or ask him to remember discussions from past events. It shouldn't matter if you think he is trolling or not. Just answer the question. Then he can choose to accept the answer or not. If he doesn't accept your CLEAR answer to the question, then that is on him. At least you can then point him to where you clearly answered his question instead of continually dodging the question and complaining about his continued asking.

I really don't understand the resistance to actually answering the question. It seems like there is something to hide, or something certain people don't want getting out on the list. 

"A secretary is what a secretary has always been." Is not a sufficient answer to the question IMO. That's like saying "An apple is an apple." When someone asks you what an apple is.

Not picking on you Gary, I just hit reply to the last post on the thread. I respect your suggestion that Paul should propose an amendment to the current bylaws, and I think he should totally do that IF he receives a clear answer to his question that does not jive with his thoughts on what type of secretary the FIG should have. 

Peter Huynh

unread,
Sep 14, 2016, 12:16:04 AM9/14/16
to PHP Framework Interoperability Group
A secretary is ... what defined in: http://www.php-fig.org/bylaws/membership/#fig-secretary.

Asking again and again and again will not solve anything. Each person's point of view of the bylaw is subjective. It's not a matter of beating around the bush, it's a matter of giving a "correct subjective answer" to the question to Paul.

If Paul feels the bylaw are not up to scratch and there are areas that he can improve/contribute to, then why not doing the thing FIG has been doing since its inception, putting in a PR and request a vote?

All the answers has already been laid bare. Nothing more will be gained from asking the same question again.

My 2c.

Pedro Cordeiro

unread,
Sep 14, 2016, 6:43:51 AM9/14/16
to PHP Framework Interoperability Group
> Paul keeps asking the same question over and over again. Why are you all so reluctant to just answer his question?

Because he has created a very false dichotomy and is insisting that people have to choose one side. People either have to be right (agree with him) or wrong.

A secretary's duty, as described, is "to serve as an impartial administrator of the FIG". This is verbatim taken from the bylaws, not my subjective interpretation of what the secretaries should or should not be doing. Had anyone read that first sentence, it would be clear that an administrator is not a mere assistant. Further clarifications in the same bylaws, that limit the scope in which the secretaries can act, their responsibilities and prerogatives, also make it very clear that a secretary is not in the same sense as a "Secretary of State", as Paul implies is the current view from Michael.

As everyone can read, Michael was only clarifying Paul's view that secretary is a synonym for "assistant". It's not, and Michael posted examples of roles where people are called secretaries with responsibilities greater than that of a simple assistant. He did not say FIG's secretaries are akin to these roles. Much on the contrary, he explicitly said: "[...] the title Secretary can mean a huge variety of things, some considerably more authoritative than that which the role of FIG Secretaries is", saying very clearly that FIG's secretaries do not have the same prerogatives as these other secretaries.

For someone who is so literal about everything, this dichotomy you present seems like a very intentional manipulation to misrepresent Michael's words, Paul. 

Also, let me paraphrase you¹: If you're going to accuse Michael of something, you'll need to quote the specific language he used, to back up your accusation.

This is a pointless discussion. I'm only replying because it seems that Paul's fanclub always finds a way to interpret silence as confirmation that he is right. He is not right. People are just fed up with Paul's incessant nitpicking over every little thing and have better things to do than explain the obvious over and over again, specially when the obvious is so very explicitly stated in the bylaws Paul has helped write himself.

This over here is exactly why some people want Paul out. He hijacked the FIG 3.0 discussion over this minor non-issue (that he will reply in a few hours saying he does not agree is a non-issue, because if secretaries are overstepping their roles it is a very serious issue and blablabla), over something someone he dislikes said that could be easily clarified had he not chosen to misrepresent the context. And then, he'll go on his blog to rant about how we're all a part of a cue that want to push a political agenda.

Pick your fights, man.

In summary: Secretaries overstepping their boundaries is a serious issue. However, it has not happened to this day and will not happen on FIG 3.0 because FIG 3.0 does not alter the secretaries' roles. Michael did not say their powers were akin to those of a secretary of state. Paul insisting on having people choose if a secretary is merely and assistant of a "secretary of state" is a false dichotomy, and secretaries' roles are not subjective and are very clearly stated on the bylaws.

¹: https://groups.google.com/d/msg/php-fig/YvHARo5G1w4/GqIq0C7xAQAJ

Dracony

unread,
Sep 14, 2016, 6:54:20 AM9/14/16
to PHP Framework Interoperability Group
Can't you guys like "agree to disagree" and let the vote decide? Obviously nobody is getting convinced on either side, that's ok, compromises don't always happen, that's cool, then the majority wins. 
But why keep kicking a dead horse, it just brings strife and makes the group look ridiculous? FFS, even the google groups said there is spamming going on.

It's the same thing as the prevote debate on kicking out Paul. After the vote the topic was dropped, so let's have the same thing. Just calm down, wait for the vote and see what the majority wants.

On Wednesday, August 24, 2016 at 7:14:17 AM UTC+2, Michael Cullum wrote:

Pedro Cordeiro

unread,
Sep 14, 2016, 12:48:23 PM9/14/16
to PHP Framework Interoperability Group
> But why keep kicking a dead horse, it just brings strife and makes the group look ridiculous?

Because then, this vote fails due to "people deliberately avoiding answering crucial questions, like 'what is the role of a secretary' on FIG 3.0". This is why everything apparently needs to be explained to exhaustion.

There are people in this list whose modus operandi is to question every little thing so, when some minor non-issue goes unnoticed, they can claim things weren't properly explained, thus creating the appearance that there are still a lot of unresolved issues and unanswered questions, when in reality these things are mostly obvious, were already explained or have no effect on the group whatsoever.

The fact that someone is not satisfied with an answer (which is already very clearly answered in the current and proposed bylaws) doesn't mean it's not clear enough. In this particular case, it is clear enough. And, in the end, it doesn't really matter what Michael's opinions on a secretary's role is, Paul is not voting if he wants Michael to be a secretary or not, he is voting on bylaw changes. The only things that matters is if the bylaw is clear enough, and this has not been questioned even once. The only thing I can see here is Paul making veiled accusations towards Michael (in the form of questions, of course, because one needs plausible deniability... he only wants things to be clear) in order to hijack this discussion. If you want my opinion, this is exactly what "acting in detriment of PHP-FIG's ability to meet its objectives" is.

Bill Condo

unread,
Sep 14, 2016, 10:23:32 PM9/14/16
to PHP Framework Interoperability Group
The duties are well defined and provide more context than any word that could be added to the secretary title. There is zero benefit in trying to match apples and oranges for what this role would be titled at another organization. FIG picked the title of secretary and gave it a list of responsibilities. That's what a FIG secretary is, no more, no less.

Glenn Eggleton

unread,
Sep 15, 2016, 9:40:10 AM9/15/16
to PHP Framework Interoperability Group

> Acting throughout their term essentially as Developer Advocates for the PHP FIG

I have never heard the term "Developer Advocate"...

Why exactly do we need "Advocates" as secretaries. That does not make any sense at all. Having a core-committee member being an advocate ... okay, but not a secretary.

Defintion of "Advocate" (for those whom might not have english as their first language) : a person who publicly supports or recommends a particular cause or policy.


As it currently reads, a secretary can publicly support say a different implementation of a problem. 

Is this a problem?

I think so.  A secretary's role is NOT to be recommending solutions but to facilitate finding a solutions.

Alessandro Lai

unread,
Sep 15, 2016, 10:07:22 AM9/15/16
to PHP Framework Interoperability Group
I think that it's meant to advocate the whole of FIG, not a single PSR or a solution to some issue.

Paul Jones

unread,
Sep 15, 2016, 10:11:52 AM9/15/16
to php...@googlegroups.com
Hi all,

> On Sep 14, 2016, at 21:23, Bill Condo <bi...@billcondo.com> wrote:
>
> The duties are well defined and provide more context than any word that could be added to the secretary title. There is zero benefit in trying to match apples and oranges for what this role would be titled at another organization. FIG picked the title of secretary and gave it a list of responsibilities. That's what a FIG secretary is, no more, no less.

Several people have made that argument; it reminds me of Lewis Carroll:

“When I use a word,’ Humpty Dumpty said in rather
a scornful tone, ‘it means just what I choose it
to mean — neither more nor less.’

’The question is,’ said Alice, ‘whether you can
make words mean so many different things.’

’The question is,’ said Humpty Dumpty, ‘which is
to be master — that’s all.”

"Which is to be master," indeed.

So I still have no idea if the secretary role is intended as an "assistant" type of secretary, or some other type of secretary. Again, this should be a straightforward thing to answer.

If the role diverges so greatly from any kind of secretary anywhere else, perhaps it is a case of calling an "apple" an "orange." That is, perhaps they are not "secretaries" after all. In which case, what are they?

I remain eager to hear a simple, clear answer on this issue, especially from the authors of the role. Giving it on this list rather than some other venue would be preferable.

Alessandro Pellizzari

unread,
Sep 15, 2016, 10:39:46 AM9/15/16
to php...@googlegroups.com
On 15/09/2016 15:11, Paul Jones wrote:

> So I still have no idea if the secretary role is intended as an "assistant" type of secretary, or some other type of secretary. Again, this should be a straightforward thing to answer.
>
> If the role diverges so greatly from any kind of secretary anywhere else, perhaps it is a case of calling an "apple" an "orange." That is, perhaps they are not "secretaries" after all. In which case, what are they?

Both an orange and an apple are fruits.
Both the "Secretary of State" and "one's personal secretary assistant"
are a type of "Secretary".

And there are many types of fruits. Some of them not yet known and named.

So, I would say, the word you are looking for is "of FIG".

"Secretary of FIG".

And what that means is defined in the role description.

Bye.

Magnus Nordlander

unread,
Sep 15, 2016, 10:55:25 AM9/15/16
to php...@googlegroups.com
Regardless of whether this is a problem or not, the entire section on "Secretaries" remains unchanged from the current bylaws (cf. http://www.php-fig.org/bylaws/membership/#fig-secretary).

I think it would behove the FIG to primarily focus this thread on what changes would be introduced with FIG 3.0, instead of what is already in the bylaws. Changing the duties of the secretaries can (and most likely should) be a separate discussion.

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

Matthew Weier O'Phinney

unread,
Sep 15, 2016, 2:37:44 PM9/15/16
to php...@googlegroups.com
On Thu, Sep 15, 2016 at 9:11 AM, Paul Jones <pmjo...@gmail.com> wrote:
> So I still have no idea if the secretary role is intended as an "assistant" type of secretary, or some other type of secretary. Again, this should be a straightforward thing to answer.

You're creating a false dichotomy, Paul.

The by-laws clearly define the role of the secretary within PHP-FIG. That role
fits into multiple definitions of the term secretary, not the specific extremes
you're suggesting. ("Secretary" roles diverge greatly based on the organization,
as you yourself have pointed out. And, I might add, the term "assistant" itself
has many connotations which can range from menial to executive tasks.)

May I redirect, and ask: Why is this alleged clarification necessary?

*You*, and you alone, are clamoring to define the role in narrower terms than
are currently present in the by-laws.

Moreover, you're putting the onus on *others* to define it, without declaring
what exactly is insufficient about the definition presented in the by-laws. This
gives you a perfect "out" when somebody does provide a definition: "that's not
what I meant", or "that's still unclear".

Frankly, if you are unhappy with the way the role is currently defined, then the
onus is on *you* to present a by-law amendment detailing changes that will
define the role in a way that you find acceptable, and then call for a review
and a vote. Don't try and manipulate others into doing your work for you.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

Paul Jones

unread,
Sep 17, 2016, 11:06:38 AM9/17/16
to php...@googlegroups.com

> On Sep 15, 2016, at 13:37, Matthew Weier O'Phinney <mweiero...@gmail.com> wrote:
>
> On Thu, Sep 15, 2016 at 9:11 AM, Paul Jones <pmjo...@gmail.com> wrote:
>> So I still have no idea if the secretary role is intended as an "assistant" type of secretary, or some other type of secretary. Again, this should be a straightforward thing to answer.
>
> You're creating a false dichotomy, Paul.

Not at all. It might be part assistant, part something else (or perhaps multiple something elses).

Regardless, I seem to have gotten an answer from Larry's SitePoint article on the FIG at <https://www.sitepoint.com/the-past-present-and-future-of-the-php-fig/> :

> In late 2015, FIG added a 3-person Secretary position, elected by project reps, to handle managerial tasks but stay out of technical tasks. I personally feel that change has been a resounding success, as managerial tasks are actually getting done now ...

Based on that, it seems the Voting Members are the workers in FIG, and the secretaries are the managers in FIG.

Is that what everyone who voted +1 on the secretary role understood the case to be?

Korvin Szanto

unread,
Sep 17, 2016, 11:14:12 AM9/17/16
to php...@googlegroups.com
Great job guys, I'm excited to see where this takes us and the php community at large.

I will say that it's too bad this discussion period was wasted, it would've been nice to have an opportunity to talk about fig 3.0 at all.

Thanks,
Korvin
--
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.

Christopher Pitt

unread,
Sep 17, 2016, 3:05:48 PM9/17/16
to PHP Framework Interoperability Group
Performing managerial tasks doesn't make someone a manager of people. I suggest we ask ourselves the question - does FIG 3.0's definition of the secretaries differ from the current bylaws definition of the secretaries? Does the current definition of secretaries (or someone's disagreement of the existing bylaws) make this a discussion about them or the content of the 3.0 proposal that is actually different?

This is a thread to discuss the content of 3.0 that differs from the current FIG. Unless the secretary bylaws differ significantly (in 3.0) from what is currently defined, it would seem that discussions about them are a straw man:

straw man is a common form of argument and is an informal fallacy based on giving the impression of refuting an opponent's argument, while actually refuting an argument that was not advanced by that opponent.[1]

Pedro Cordeiro

unread,
Sep 19, 2016, 9:55:48 AM9/19/16
to PHP Framework Interoperability Group
> I will say that it's too bad this discussion period was wasted

It wasn't wasted as much as it was hijacked by Paul.

> Is that what everyone who voted +1 on the secretary role understood the case to be? 

It doesn't matter, because FIG 3.0 doesn't change the bylaws regarding a secretary's role. This is a FIG 3.0 proposal thread. You are deliberately hindering the discussion. Like everyone else already said, if you're unhappy with the current state of affairs, propose bylaw changes regarding the secretaries' role in FIG and put that to a vote.

Now, we can spend the rest of our lives here in this back-and-forth. You keep saying there is a problem, I keep responding that IF there is one, it's not FIG 3.0 related.

Matthew Weier O'Phinney

unread,
Sep 19, 2016, 11:24:08 AM9/19/16
to php...@googlegroups.com
On Sat, Sep 17, 2016 at 10:06 AM, Paul Jones <pmjo...@gmail.com> wrote:
>
> On Sep 15, 2016, at 13:37, Matthew Weier O'Phinney <mweiero...@gmail.com> wrote:
> > You're creating a false dichotomy, Paul.
>
> Not at all. It might be part assistant, part something else (or perhaps
> multiple something else

And now you're moving the goalposts, because *before* you were asking if it was
one or the other.

> > In late 2015, FIG added a 3-person Secretary position, elected by project
> > reps, to handle managerial tasks but stay out of technical tasks. I
> > personally feel that change has been a resounding success, as managerial
> > tasks are actually getting done now ...
>
> Based on that, it seems the Voting Members are the workers in FIG, and the
> secretaries are the managers in FIG.
>
> Is that what everyone who voted +1 on the secretary role understood the case
> to be?

And this is a false equivalency. Managerial !== authority. Managerial tasks
often involve only coordination of efforts, which, in terms of FIG, means
ensuring the lights stay on for the website, ensuring repositories are setup
with appropriate permissions, etc.

Put in another light: this is similar to the CIO office of an organization.
Another group, the board of directors (voting members in FIG parlance) lays out
strategy and direction, and the CIO office ensures that resources are available
and allocated to make that happen.

As I and others have noted previously in this thread: state your objectives in
the form of a by-law change proposal. Otherwise, please stop hijacking the
discussions with the constant conspiracy theorization. There is none.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

Paul Jones

unread,
Sep 19, 2016, 11:47:05 AM9/19/16
to php...@googlegroups.com

> On Sep 19, 2016, at 10:24, Matthew Weier O'Phinney <mweiero...@gmail.com> wrote:
>
> On Sat, Sep 17, 2016 at 10:06 AM, Paul Jones <pmjo...@gmail.com> wrote:
>>
>> On Sep 15, 2016, at 13:37, Matthew Weier O'Phinney <mweiero...@gmail.com> wrote:
>>> You're creating a false dichotomy, Paul.
>>
>> Not at all. It might be part assistant, part something else (or perhaps
>> multiple something else
>
> And now you're moving the goalposts, because *before* you were asking if it was
> one or the other.

Again, not at all. I pointed out the same possibility in my original conversations with Michael (to which you were not privy, and since they were on the record, I can publish them here if you like as proof). The goalposts are just where they were when I started.

I continue to find it remarkable the amount of evasion going on here.

If the FIG secretarial role is something truly new-and-different, that cannot be related to any other kind (or kinds) of secretary anywhere at any time ever, then the title is poorly chosen.

On the other hand, if it *does* fit a particular kind(s) of secretary, then the authors should say what it is.

At this point I don't expect the evasiveness to stop, but I will keep pointing it out as it happens.

Korvin Szanto

unread,
Sep 19, 2016, 11:51:59 AM9/19/16
to php...@googlegroups.com
Thank you for making your position clear once again, can we stop now?

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

Samantha Quiñones

unread,
Sep 19, 2016, 11:57:34 AM9/19/16
to PHP Framework Interoperability Group
Paul,

I'm not sure what you're looking for here. You've asked repeatedly for someone to explain the role. It is defined in the bylaws here. There is no other secret definition that is being hidden. I don't know if it's your intention or not, but your behavior is very distracting and disruptive. Hectoring the mailing list about this issue is unacceptable. Please consider this your warning. You are welcome to voice your opinions or suggest bylaw changes. You cannot badger the group to play a game that no one but you understands. 

Best,
Samantha

Dave Goodchild

unread,
Sep 19, 2016, 1:59:21 PM9/19/16
to PHP Framework Interoperability Group
The noise this group creates and the outward flowing negativity is seriously embarrassing. How can you all be OK with this?

I literally wish there was a "Block/Mute PHP-Fig" button on the "Internet"; if only that's how it worked. This is doing nothing positive for the PHP community. The constant bickering and back lashing.

At the moment, from an outside perspective, this is not a community I want to remotely associate with.
Reply all
Reply to author
Forward
0 new messages