Proposed bylaw changes regarding voting

[Paul Jones]

All,

To wit:

- That no vote may proceed without at least 2 weeks of deliberation regarding the measure to be voted on, during which time the measure may be modified or withdrawn.

- Further, that votes may only be held on measures allowed per bylaw.

- Finally, that members have the power to propose and vote on any measure regarding bylaws, including creating new bylaws, and modifying or removing existing bylaws.

This should restrict the pernicious and imprudent view that members can vote on whatever they like, in whatever timeframe they like, without considered deliberation of the measure beforehand.

I ask for input from voting members on the idea, and on the formal language.


--

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

[Korvin Szanto]

I like the idea other than restricting the content of the vote. We should retain the ability to vote on anything not covered by the bylaws, but we should have clear timelines and rules for such votes.

Another thing I want to bring up is abstaining votes on a member project representative replacement vote. If we are voting on people and not on a psr that some may feel unqualified to vote on, we should either be +1 or -1. I feel that +0 in such a vote is harmful to be process and almost allowed Roman to be voted out when that may have not necessarily been the view of the group.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/BA3D6233-A836-4615-8DD9-B849257201D7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Jones]

> On May 26, 2016, at 15:35, Korvin Szanto <korvin...@gmail.com> wrote:
>
> I like the idea other than restricting the content of the vote. We should retain the ability to vote on anything not covered by the bylaws, but we should have clear timelines and rules for such votes.

/me nods

That's why I included, explicitly, the ability to propose and vote on bylaws. In the worst case, if something is not covered by a bylaw, the group can: discuss if a bylaw is appropriate, vote on it, and then proceed to another vote per the new bylaw if it passed. This has the effect of keeping the group itself in check.

[Kayla Daniels]

You realize that's an 8 week period to make any change not already explicitly covered by bylaws? How is that reasonable? 

[Paul Jones]

> On May 26, 2016, at 16:01, Kayla Daniels <kayl...@gmail.com> wrote:
>
> You realize that's an 8 week period to make any change not already explicitly covered by bylaws? How is that reasonable?

I do; if someone wants to vote on something RIGHT NOW, they need a waiting period. ;-)

With a little less snark: I can think of nothing this group has done that is that time-sensitive.

[Michael Cullum]

Might I also suggest that we make any of the above changes that the membership agree with, together with some changes about project expulsion rules so it is possible to both expel a project or a project representative, to avoid such issues as we've had recently, and to clarify whether the project representative/member project in question can vote on their own expulsion.

On a personal note, not speaking as a secretary, I'd concur with Korvin's statement "We should retain the ability to vote on anything not covered by the bylaws, but we should have clear timelines and rules for such votes". If we look historically, we never used to define what we had to vote for at all until the PSR workflow bylaw. What must be voted on was established by precedent and convention, and the stipulation for member project admission to be voted on, then anything else members wished. This allowed votes on other miscellaneous items such as whether or not we should go with one idea or another when discussing specifications, or on other things such as the recent vote on whether we should allow translations of PSRs. The ability to be able to vote on miscellaneous items is something that has been a core fundamental part of FIG operation since it's inception and removing that ability will only add more process issues. However I do entirely agree about implementing rules about the discussion period. Should FIG 3.0 be introduced this will be rendered irrelevant anyway as votes on different things will be delegated to different groups. Something like whether or not we should support translations is unnecessary of a bylaw but doesn't mean it shouldn't be a decision that shouldn't be voted upon and we might end up in a situation where we end up with informal surveys determining FIG policy as opposed to formal votes.

Regarding Kayla's point, just because it's not urgent, doesn't mean we should take two months over simple things, we get accused enough of over-complicated bureaucracy as it is. I recall you yourself complaining about such things recently and I think we should all be working together to combat this and make the FIG an easier organisation to work in, not harder.

Many Thanks,

--

Michael C

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+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/D658F3EE-0BDE-4E5A-8703-B73CA5D23FB3%40gmail.com.

[Colin O'Dell]

> "We should retain the ability to vote on anything not covered by the bylaws, but we should have clear timelines and rules for such votes"

It might be helpful to create a bylaw that defines the process for proposing and voting on such resolutions.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAqcDMgSkRUpGvZ9szEuTz%2Bee43vdbq9i0_qWhBNihFugTWwHQ%40mail.gmail.com.

[Alessandro Lai]

I agree with Michael and Korvin. Stated timelines for the voting process are needed, but the ability to ask a vote on a trivial or urgent matter not stated in the bylaws should be retained; I cited trivial and urgent because I think that they are the two main cases where uncoded matters should be voted on without bylaws backing them; trivial matters shouldn't be coded in bylaws to avoid a gigantic document where every little nitpicking is written down; and urgent matters are the dangerous ones, the one that nobody had thought about.

Maybe a generic process can be written down, such as "at least 3 voting members should sponsor the new vote" or something along these lines. Obviously the 2-week discussion frame should take its place anyway.

[Paul Jones]

> On May 27, 2016, at 03:53, Alessandro Lai <alessand...@gmail.com> wrote:
>
> I agree with Michael and Korvin. Stated timelines for the voting process are needed, but the ability to ask a vote on a trivial or urgent matter not stated in the bylaws should be retained; I cited trivial and urgent because I think that they are the two main cases where uncoded matters should be voted on without bylaws backing them; trivial matters shouldn't be coded in bylaws to avoid a gigantic document where every little nitpicking is written down; and urgent matters are the dangerous ones, the one that nobody had thought about.
>
> Maybe a generic process can be written down, such as "at least 3 voting members should sponsor the new vote" or something along these lines. Obviously the 2-week discussion frame should take its place anyway.

"At least 3 voting members should sponsor" is a nice touch (when combined with the 2-week discussion). I could get behind that as a replacement for "can only vote on bylaw-allowed topics."