[VOTE] Nullification of PHPixie membership

4,165 views
Skip to first unread message

Kayla Daniels

unread,
May 11, 2016, 12:52:04 PM5/11/16
to PHP Framework Interoperability Group
Based on recent events, I am officially calling for a vote to nullify PHPixie's status as a member project within the FIG on the grounds that the project's adoption numbers were misrepresented, whether intentionally or not, prior to the entrance vote.

It should be noted that this would in no way stop Dracony from engaging with or being invovled in the FIG here or elsewhere. It also does not stop him from resubmitting for application in the near (or even immediate future). 

This starts the 2 week voting period. Voting will close at 17:00 UTC 5/25. A vote of +1 is in favor of nullification, -1 is against it. 

Kayla Daniels - The PHP League

Kayla Daniels

unread,
May 11, 2016, 12:57:21 PM5/11/16
to PHP Framework Interoperability Group
:+1: from the PHP League

Dracony

unread,
May 11, 2016, 12:57:59 PM5/11/16
to PHP Framework Interoperability Group
Well, I still get a vote, -1 from PHPixie =P

Robert Hafner

unread,
May 11, 2016, 1:21:28 PM5/11/16
to PHP Framework Interoperability Group
-1 from Stash.

As I've said before, if we didn't kick them our or refuse entry over the logo then doing so using the pathetically small amount of evidence is very inappropriate.

I also think the fact that these drama posts get more responses and feedback than the posts actually trying to accomplish our supposed interop mission is very telling of how far this group has fallen. We might as well change the name of this group to /r/php.

Rob

Taylor Otwell

unread,
May 11, 2016, 1:21:44 PM5/11/16
to PHP Framework Interoperability Group
:+1: From Laravel.

With most damning evidence being the "Andrej" IP address matching Roman's which was further investigated by Andrew. For the record, if Roman would have come clean at the beginning I would not have voted to nullify his membership.

Korvin Szanto

unread,
May 11, 2016, 1:33:34 PM5/11/16
to PHP Framework Interoperability Group
+1 concrete5 

No comment needed.

--
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/0993f8d1-5028-4e96-bfae-6632bd2e5d0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Lukas Kahwe Smith

unread,
May 11, 2016, 2:13:04 PM5/11/16
to php...@googlegroups.com
+0 from Jackalope

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

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

regards,
Lukas Kahwe Smith



signature.asc

Shefik

unread,
May 11, 2016, 2:20:48 PM5/11/16
to php...@googlegroups.com
+0 from Zikula

- Shefik
--

Adam Culp

unread,
May 11, 2016, 2:42:26 PM5/11/16
to PHP Framework Interoperability Group
+0 IBMiToolkit

Reasoning: (since there never really was a valid discussion period)
I will not join in the pitchfork mob. This should never have gotten as far as a vote IMO. At the end of the day this group is supposed to be about interoperability and PHPixie, regardless of size, is a PHP framework. That alone was why my original vote was to admit the project to the FIG. After that I think Roman's regular contributions helped inspire communication while so many do not contribute regularly, despite anybody's personal feelings about him. This group will be less effective without people doing that.

I find is shameful that so many went head hunting on this, and continued to instigate in such a personal way. However, Roman's continued responses and apparent follow-up actions were also very poor judgement.

The other actions apparently carried out by Roman were also poor judgement. However, I do not feel it hurt the FIG. What hurt the FIG is all of the communication on the other thread, which was much broader than Roman alone. The toxic nature and pitchfork mentality saddens me.

Yes, what Roman did was deceptive and morally wrong. So slap his hands and send him to his room. But what does all that have to do with defining PSR's?





On Wednesday, May 11, 2016 at 12:52:04 PM UTC-4, Kayla Daniels wrote:

Paul Jones

unread,
May 11, 2016, 2:48:25 PM5/11/16
to php...@googlegroups.com
-1 from Aura/Solar; per protocol, reasons to follow in a discussion thread.




--

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



Paul Jones

unread,
May 11, 2016, 2:51:13 PM5/11/16
to php...@googlegroups.com
All,

I voted -1 on the nullification, not because I think Dracony's in-the-group sock-puppetry behavior is acceptable, but because:

1. There has been no 2-week discussion period, as is customary.

2. This group has no power to nullify, only to expel.

Chris Tankersley

unread,
May 11, 2016, 3:05:44 PM5/11/16
to php...@googlegroups.com
On Wed, May 11, 2016 at 2:51 PM, Paul Jones <pmjo...@gmail.com> wrote:
All,

I voted -1 on the nullification, not because I think Dracony's in-the-group sock-puppetry behavior is acceptable, but because:

1. There has been no 2-week discussion period, as is customary.

From the looks of the bylaws, the 2 week discussion period is only for requests for new members. The expulsion rules state that the votes only follow the voting protocol, which does _not_ contain a 2 week discussion period. 
 

2. This group has no power to nullify, only to expel.


--

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



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

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



--
Chris Tankersley
http://ctankersley.com

Adam Culp

unread,
May 11, 2016, 3:19:50 PM5/11/16
to PHP Framework Interoperability Group
Thanks Chris. I was aware, and agree. My comments about not having a valid discussion period were more along the lines that the single day of discussions were so emotionally charged that it makes responsible decisions hard.

Paul Dragoonis

unread,
May 11, 2016, 4:28:47 PM5/11/16
to php...@googlegroups.com

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


-1 on this removal of Dracony. 

This is on the basis that Dracony is, going forward, willing to contribute and add value to PSR's he's interested in contributing to. If we draw a line in the sand and move forward with an agreement of pure focus on PSR's then I don't see a problem with him contributing here. If Dracony's project's political issues do indeed make their way over to the FIG again in the future, then we'll know clearly what to do.

I don't want to see any individual project's political stuff make its way to this mailing list. If people make posts on the mailing list to anything outside PSR-related discussions then they should be locked/closed. The outcome of this is, if non-PSR things get locked then it doesn't give any room for things to break out and go nuts like we've seen.

As a notable example: Jordi has shown great character in dealing with similar situations on the Composer project, and closing github issues when it's the appropriate thing to do. Let's all strive to be like Jordi :-P

Can we, pretty please, move on and allow Dracony to prove/show that he still can bring value to the PSR's?












 

Alexander Makarov

unread,
May 11, 2016, 5:23:08 PM5/11/16
to PHP Framework Interoperability Group
+0 from Yii.

Michiel Rook

unread,
May 11, 2016, 5:30:07 PM5/11/16
to php...@googlegroups.com
+0 from Phing

On 11 May 2016, at 18:52, Kayla Daniels <kayl...@gmail.com> wrote:

--
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,
May 11, 2016, 5:56:33 PM5/11/16
to PHP Framework Interoperability Group
+0 from SilverStripe

Explanation to follow (for those who care).

Larry Garfield

unread,
May 11, 2016, 8:03:20 PM5/11/16
to php...@googlegroups.com
Paul, isn't that the sort of legal nitpicking you say you hate this
group is doing? :-)

As a procedural matter, I must however concur here. Primarily,
nullifying membership is... not a thing. Does that also invalidate any
votes he's cast since PHPixie was admitted? What does that do to those
specs? Do we need to rebase our voting history? :-)

Additionally, we don't really have the ability to eject a project, just
a voting representative. If a project has no other viable
representatives, then the project gets expelled by default.

Thus, an annulment vote is inappropriate and improper. An expulsion
vote of Dracony as the PHPixie rep (and PHPixie if no other rep is
viable) is appropriate to call, at this or a later time.

--
Larry Garfield
la...@garfieldtech.com
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+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/FC458D18-5940-49A9-BC08-092110C28125%40gmail.com.

Christopher Pitt

unread,
May 11, 2016, 8:56:02 PM5/11/16
to PHP Framework Interoperability Group
If a project has no other viable representatives, then the project gets expelled by default. 

Sorry to inject a bit of levity, but...prepare for the appearance of a new long-time maintainer...

Roman Tsjupa

unread,
May 12, 2016, 2:36:54 AM5/12/16
to PHP FIG

Christopher, well of course. If the group doesn't like me personally there is no reason for it to propagate to the project. It just means that I as a person am no longer wanted here, and maybe some one else would represent the projwcr better.

Imagine if a representative of a big project like Symfony does something undeniably bad and gets expelled, why should everybody invloved in the project and people uaing it suffer from it ?

On May 12, 2016 02:56, "Christopher Pitt" <cgp...@gmail.com> wrote:
If a project has no other viable representatives, then the project gets expelled by default. 

Sorry to inject a bit of levity, but...prepare for the appearance of a new long-time maintainer...

--
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/TDX--AVR45c/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.

Christopher Pitt

unread,
May 12, 2016, 2:42:07 AM5/12/16
to PHP Framework Interoperability Group
Just to be clear: I said what I did in jest, in an attempt to lighten the mood. I care little for discussing this issue here, in ernest.

Michael Cullum

unread,
May 12, 2016, 5:11:00 AM5/12/16
to FIG, PHP
FIG Members have voting/legislative supremacy meaning they can essentially vote on whatever they like if it's not covered in the bylaws that it must be done a specific way, an example of this was the removal of translations.

The bylaws do not allow for voting to expel a project, but for voting to expel a project representative, who can then nominate a substitute representative. Only if they are unable/unwilling to do that (so it is essentially their choice), the member project will be expelled. The bylaws therefore explicitly don't allow for direct expulsion of member projects (an oversight perhaps) themselves directly, so a nullification makes sense. To clarify, it will not be applied retrospectively, but from the point in time it passes (if it does) onwards. Again, this is permissible because members have voting supremacy.

Now, feel free to call it an expulsion vote, or a nullification vote, but the essence is the same, if it passes, PHPixie will no longer be a member project.

This is the official position of the secretaries on the matter invoking our responsibility to 'Clarifying any interpretation of bylaw text' and we unanimously agreed this was the most appropriate interpretation.

Now, lets please just let this vote proceed as it will, then move on. Discussing the semantics of this vote isn't going to help anything.

We also have a general agreement there should be no discussion in voting topics so please refrain from making further replies to this topic unless they contain votes.

--
Michael C

Brian Retterer

unread,
May 12, 2016, 4:20:24 PM5/12/16
to PHP Framework Interoperability Group
-1 Stormpath PHP SDK

I am in full agreeance of what Adam has said here.  The actions that Roman may or may not have done do not hurt what happens when defining PSR's.  The only thing that hurt FIG was the discussion and "pitchfork mob" that happened over the last couple days.  


On Wednesday, May 11, 2016 at 12:52:04 PM UTC-4, Kayla Daniels wrote:

André R.

unread,
May 16, 2016, 6:41:18 AM5/16/16
to PHP Framework Interoperability Group
-1: from eZ

Given:
1. this is not in accordance to bylaws, and discussion was to short and way too emotionally driven.
2. while the behaviour might be ok to expose on blogs and twitter, the shaming mob drama shouldn't have to reach this group, this is not why most of us are here (hopefully).


On Wednesday, May 11, 2016 at 6:52:04 PM UTC+2, Kayla Daniels wrote:

Jordi Boggiano

unread,
May 16, 2016, 10:44:43 AM5/16/16
to php...@googlegroups.com
+1 for Composer, not because of the fact the project was voted in on
potentially dodgy grounds, but because Roman/Dracony:

- lied to us and tried to bullshit his way out of it with new accounts
instead of admitting to it and moving on, which would have been the
adult thing to do and might have defused the whole thing.

- wasted enough of our time as it is, and I don't think we need a new
thread discussing it even further.

- is the only maintainer of PHPixie, so even though we should call for a
new representative, there is none and I am not so keen on seeing one
magically appear. So the project should be booted altogether.

P.S: This is quite a special and unique case, and the bylaws might not
be clear, but I don't think this should stop us from taking action, and
I don't think it's worth spending time on adjusting the bylaws either.

Cheers
Jordi
> --
> 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
> <mailto:php-fig+u...@googlegroups.com>.
> To post to this group, send email to php...@googlegroups.com
> <mailto:php...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/b35d130d-712f-4ff8-95ae-08db0462e576%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/b35d130d-712f-4ff8-95ae-08db0462e576%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


--
Jordi Boggiano
@seldaek - http://seld.be

Adam Culp

unread,
May 16, 2016, 10:58:50 AM5/16/16
to PHP Framework Interoperability Group
REVISED: +1 IBMiToolkit

Because Roman brought the deception to the FIG after the accusations. Too bad. Let's just move on.

Paul Jones

unread,
May 16, 2016, 12:56:48 PM5/16/16
to php...@googlegroups.com

> On May 12, 2016, at 04:10, Michael Cullum <m...@michaelcullum.com> wrote:
>
> FIG Members have voting/legislative supremacy meaning they can essentially vote on whatever they like if it's not covered in the bylaws that it must be done a specific way,

That's an interesting assertion; what makes you think it is true?

Regardless, it seems to me that "voting on whatever we want" is effectively unlimited in scope, which in turn seems imprudent. Random voting on whatever strikes one's mood is rather arbitrary.

As a limited-government kind of person, I suggest that the scope of voting is more prudently restricted to "voting based on existing bylaws" and "voting to add/change/delete bylaws." Want to start a vote for something that's not covered? Fine: pass a bylaw first to see if the rest of the group thinks it's a big-enough deal.

Otherwise, polls are perfectly acceptable.


> an example of this was the removal of translations.

I can't speak to the removal of translations; perhaps that was handled improperly, given what I said above. If indeed it was handled improperly, then let us recognize it and guard against it in future, rather than use it as a basis for further improper action.

Jordi Boggiano

unread,
May 16, 2016, 1:34:05 PM5/16/16
to php...@googlegroups.com
On 16/05/2016 17:56, Paul Jones wrote:
>> an example of this was the removal of translations.
>
> I can't speak to the removal of translations; perhaps that was handled improperly, given what I said above. If indeed it was handled improperly, then let us recognize it and guard against it in future, rather than use it as a basis for further improper action.

As per my answer on the nullification vote, IMO this group's members
have a right to avoid wasting their own time on needless nitpicking.
It's a special situation, can we please handle it as such with whatever
common sense prevails and then *move on*?

Cheers

Chuck Burgess

unread,
May 16, 2016, 10:19:15 PM5/16/16
to php...@googlegroups.com

+0 from PEAR

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

Andres Gutierrez

unread,
May 17, 2016, 10:15:05 PM5/17/16
to PHP Framework Interoperability Group
+0 from Phalcon

Ben Marks

unread,
May 18, 2016, 7:54:14 AM5/18/16
to PHP Framework Interoperability Group
+0 Magento

Roman Tsjupa

unread,
May 25, 2016, 1:07:15 PM5/25/16
to PHP FIG

Alright, since the time has elapsed im happy to announce the results:

+1: 5
-1: 6
0: 8

19 total votes (out of 39 projects if i counted correctly). I counted my own vote as -1, but even if you discard it the vote still doesn't pass.

Yay )) and thanks to all the +1s and +0s

--
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/TDX--AVR45c/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.

Michael Cullum

unread,
May 26, 2016, 1:12:53 PM5/26/16
to FIG, PHP
Hi all,

Apologies for not getting to this sooner. As most of you know two of our number are at php[tek] and I've been rushed off my feet with other things the past few days but thank you all for your patience in waiting for us to announce the results.

We had 18 total votes, out of 41 counted projects. We discussed it internally amongst ourselves and decided not to count resigning projects in the quorum calculations unless the voted before they resigned (as Laravel did), there was no precedent for this but this was agreed by the secretaries and so will serve as a precedent for future votes should a similar situation arise. This did not affect if we achieved quorum however.

Out of 18 votes cast there were 8 abstentions, 5 votes for and 5 votes against resulting in a tie, and therefore no action will be taken.

We did not include Dracony's -1 vote, but this did not affect the result.

A member project asked us on the final day of voting, after 5pm UTC if they could still vote to which we said no as is previous precedent. However later looking at the bylaws, it states 14 days, not 336 hours, so all future votes should be set to end at 11:59 on the 14th day after a vote has been called. This vote would have changed the result.

You can view more detailed statistics and the breakdown on the FIG 2016 Votes Sheet.

--
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+u...@googlegroups.com.

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

Robert Hafner

unread,
May 26, 2016, 1:28:16 PM5/26/16
to php...@googlegroups.com
Can you explain the logic- including bylaw references- for not counting Dracony’s vote?

Rob



Paul Jones

unread,
May 26, 2016, 2:09:24 PM5/26/16
to php...@googlegroups.com

> On May 26, 2016, at 12:12, Michael Cullum <m...@michaelcullum.com> wrote:
>
> We did not include Dracony's -1 vote, but this did not affect the result.

Why was the vote of a voting member not included?


> A member project asked us on the final day of voting, after 5pm UTC if they could still vote to which we said no as is previous precedent. However later looking at the bylaws, it states 14 days, not 336 hours, so all future votes should be set to end at 11:59 on the 14th day after a vote has been called. This vote would have changed the result.

On a historical note, some early votes specified a day and time for the termination. The original intent was 14 days, to the minute.

Perhaps the secretaries should deliberate rule interpretations in public on this list, not in private among themselves, so as to gain the benefit of the wider knowledge of the group.

Michael Cullum

unread,
May 26, 2016, 2:20:13 PM5/26/16
to FIG, PHP
Had it affected the final result it might be more of an issue for debate but it didn't so it's more of a statistical point. There is no bylaw point reference pointing to either way (The bylaws do not contain a clause stating that 'all voting projects always have a vote' nor that 'voting members cannot vote on an expulsion/annulment of membership'). There is therefore a necessity to make a choice to include, or not include that vote, (we had multiple members question whether this vote was legal) and potentially allowing people to vote on their own project's annulment of membership (Which would have in turn removed their ability to vote in that same vote) could be a potentially dangerous road to tread.

As a result of this lack of bylaw clarify, it then comes down to a matter of interpretation which is delegated on a day-to-day basis to secretaries to prevent having to vote on every tiny measure, however I do agree this is a point that is best cleared up explicitly in the bylaws so we will include something in the upcoming bylaw changes to prevent this ever being a factor in which it affects a vote.

As this hasn't had any effect on this vote, I don't think we need to continue to discuss it with regards to this instance, however it should be resolved in the bylaws before any other such future votes.

--
Michael C

Paul Jones

unread,
May 26, 2016, 2:36:39 PM5/26/16
to php...@googlegroups.com

> On May 26, 2016, at 13:19, Michael Cullum <m...@michaelcullum.com> wrote:
>
> Had it affected the final result it might be more of an issue for debate but it didn't so it's more of a statistical point. There is no bylaw point reference pointing to either way (The bylaws do not contain a clause stating that 'all voting projects always have a vote' nor that 'voting members cannot vote on an expulsion/annulment of membership'). There is therefore a necessity to make a choice to include, or not include that vote, (we had multiple members question whether this vote was legal) and potentially allowing people to vote on their own project's annulment of membership (Which would have in turn removed their ability to vote in that same vote) could be a potentially dangerous road to tread.

I admit I do not find this position credible. Is it really your position "voting members votes count at some times, and not at others, depending on unwritten factors that may be different at different times"?

Frankly, that seems like cause for a vote of no-confidence. Or do voting members not get to vote in that? Or only some members and not others? Depending on who Michael Cullum feels like allowing to vote?

No, the correct position is and must always be that voting members always have their votes counted. It seems so obvious as not to require stating, but apparently the obvious must be stated explicitly from time to time.


> and potentially allowing people to vote on their own project's annulment of membership


Voting members vote on their own proposals when they act as editor or sponsor. This is no different.

And again, this body has no power to "annul" a membership.

Finally: the Secretaries exist to serve this body, not to rule it.

Robert Hafner

unread,
May 26, 2016, 2:44:24 PM5/26/16
to PHP Framework Interoperability Group
The fact that Paul and I are in complete agreement should say something.

I don't think the Secretaries should have the power to remove a voting member's vote arbitrarily, and there is nothing in the bylaws that says that power exists. I also don't believe the Secretaries can just give themselves new powers without discussion with the group. You're secretaries, not rulers. This move was incredibly inappropriate, and the fact that it was even attempted makes me wonder if the secretary role was a mistake to begin with. On top of that there was no discussion, despite there being weeks of time for one, and you are now claiming that a discussion isn't even needed. This is a horribly way for a group to operate.

I ask that you fix this vote count and the spreadsheet to reflect this, and commit to being more open and transparent about these things going forward.

Rob

Michael Cullum

unread,
May 26, 2016, 2:50:29 PM5/26/16
to PHP Framework Interoperability Group
You make fair points but as I've pointed out, this in no way affected the outcome of the vote, otherwise it would have been an important topic for discussion which we would have brought to the membership to debate. I have now adjusted the voting sheet but this is simply a statistical discussion point as opposed to a practical one.

--
Michael

Paul Jones

unread,
May 26, 2016, 3:03:49 PM5/26/16
to php...@googlegroups.com

> On May 26, 2016, at 13:50, Michael Cullum <m...@michaelcullum.com> wrote:
>
> You make fair points but as I've pointed out, this in no way affected the outcome of the vote,

The *outcome* is of less importance than the behavior that led to it.


> this is simply a statistical discussion point as opposed to a practical one.

Incorrect. It is *entirely* practical, and goes to the heart of what the secretaries are allowed, and not allowed, to do.

Paul Jones

unread,
May 26, 2016, 3:10:00 PM5/26/16
to php...@googlegroups.com

> On May 26, 2016, at 13:44, Robert Hafner <ted...@tedivm.com> wrote:
>
> The fact that Paul and I are in complete agreement should say something.

Sign of the apocalypse. ;-)


> I don't think the Secretaries should have the power to remove a voting member's vote arbitrarily, and there is nothing in the bylaws that says that power exists.

I agree, but apparently the thinking is "that which is not explicitly forbidden is implicitly permitted." That's the opposite of what should be the guiding philosophy.


> This move was incredibly inappropriate, and the fact that it was even attempted makes me wonder if the secretary role was a mistake to begin with.

Yes, I confess to thinking the same thing shortly after the role was voted into existence. Perhaps the role description needs to be re-written, by someone who is not going to *hold* that role.

Kayla Daniels

unread,
May 26, 2016, 3:24:20 PM5/26/16
to PHP Framework Interoperability Group
This vote is over and this conversation is veering towards policy discussion in a place that people wouldn't expect to look for it. 

If you want to discuss the role of secretaries, whether or not votes should count when they represent a clear and irrefutable conflict of interest, or any other policy matter: that discussion should be taken to a different thread with a clear purpose. 

Kayla

Dracony

unread,
May 26, 2016, 3:38:34 PM5/26/16
to PHP Framework Interoperability Group
The not counting of my vote looks especially great in the light of that there was somebody willing to vote after the voting ended. Which, if my vote is not counted, would be the killing blow.
Also, I really wonder about what would cause somebody to wait entire 2 weeks before casting the vote at the last moment =\

Samantha Quiñones

unread,
May 26, 2016, 3:47:44 PM5/26/16
to PHP Framework Interoperability Group
This vote has been closed and recorded and the result announced. 

This thread is not an appropriate venue for further discussion of bylaws and voting policy and I'm going to lock it now.

Thanks,
Samantha Quiñones
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages