FIG Secretary Bylaw Changes

[Michael Cullum]

The suggestion of a new FIG secretary role was initially suggested at the ZendCon FIG summit and later discussed on the mailing list and since then Joe Ferguson and I have worked on expanding the ideas raised in those discussions[1] into a more complete proposal. Obviously it is not complete but the aim was to get a good base upon which we can build upon and adapt. Once the details and contents has been decided upon we can format it correctly into the style of a bylaw, send a pull request and a vote could be commenced.

Link as a formatted gist: https://gist.github.com/michaelcullum/782b1bba4411a3db7cc5

Pasted contents:

# FIG Secretary Bylaw (To be introduced into the Membership Bylaw)

### Overarching role:

The primary responsibility of the FIG Secretary is to serve as an impartial administrator of the FIG. They serve at the member projects pleasure but act as independent and impartial adjudicators. FIG Secretaries will also represent the FIG as a whole to the general community and public on matters relating to the FIG's activities.

Whilst there are a number of defined functions below but they should also perform other duties as required. As the role has continuity (in that there will always be a post holder) and redundancy (There are a number of post holders in case of the absence of one) it can be ensured that responsibilities assigned to the secretary will always be completed and therefore administrative responsibilities such as vote management should always be assigned to the FIG secretary. 

All FIG secretaries are expected to remain impartial and professional when acting in an official capacity as secretary and should also remain aware that even when not acting in an official capacity, their actions reflect back on the PHP FIG and the FIG must not be brought into disrepute.

### Defined functions:
* Keeping the website, twitter and other marketing mediums up-to-date
* GitHub organization administration
* Tallying votes
* Tracking member project activity, and marking projects as inactive
* Ensuring bylaws are being followed
* Clarifying any interpretation of bylaw text (If there is lack of consensus between FIG secretaries then it must be put to a full vote according to the standard voting protocol).
* Ensure that relevant marketing mediums (e.g. Twitter and Facebook) are kept professional, up to date and impartial.
* Moderate discussions on github, the mailing list and IRC channels to ensure that an appropriate environment is maintained

### Granted Access
* Access to the GitHub organisation as 'Owners'
* Full (admin) access to anything relating to official website, marketing and communication mediums including but not limited to the domain, twitter, IRC channel and mailing list
* The ability to start any vote, but not cast any votes. NB: Any vote started by one FIG secretary must be managed and tallied by a different secretary to ensure impartiality.

### Selection:
Secretaries are selected every year at the end of January after a vote according
to standard voting protocols except with the change that any outgoing secretaries
may also participate in the vote. Secretaries are then in post until such a time
as they resign, are removed by a vote of confidence or until the following January.

Secretaries may serve a maximum of three consecutive terms except in the instances
where all secretaries would be leaving post at the same time or the FIG is unable
to find another candidate to serve as secretary in which case one additional term
may be served by an individual.

On the last Sunday in January the term finishes for existing secretaries and the
voted upon secretaries will take up posts. Any secretaries who are still eligible
may re-stand for election as a secretary at this time. The vote for the new secretaries
must be started no earlier than the first Sunday in January and conclude the day before
the previous secretaries leave post and this vote will be organised by the longest
serving secretary. One mailing list topic will contain the vote for all standing secretaries
titled '[Vote] PHP FIG Secretaries for {YEAR}'.

Secretaries must be nominated/proposed by an existing PHP FIG representative or outgoing secretary
to be considered in the vote by an email to the mailing list. People who wish to stand as
secretary may seek proposers in any way they see fit (An email to the mailing list appealing
or individual contact with FIG Members). In a situation where more than three candidates are
nominated for the role of secretary, the three individuals with the largest majority (Where yes votes
count as +1, and no votes count as -1 and abstains are excluded) will be elected as secretaries.

Any member project may call a vote of no confidence in a FIG secretary where, if the majority
(according to the Voting Protocol) vote in favour of their dismissal, they will be removed with
immediate effect. The recording and tallying of votes in this instance is to be managed by another
secretary together with the member project who called the vote. A vote of no confidence must be
proceeded by a one-week discussion on the mailing list.

In the event of a resignation of a FIG secretary or a vote of no confidence, they shall be removed
with immediate effect and an existing FIG secretary should commence a vote for a new secretary
according to the aforementioned protocols. A term that does not begin on the last Sunday in January
does not count as a full term when interpreting the maximum number of terms a member may stand for.

### Eligibility Criteria:
The role should be filled by three people (working together to ensure impartiality in all matters
and continuous availability) at any one time and those individuals must not be:
* Project Representatives of a Member Project
* An Editor of a PSR that is in Draft phase

If during a secretary's term they become ineligible they must resign.

Your thoughts are all most welcome.

[Cal Evans]

In the section "Selection", I would change "vote of confidence" to "vote of no confidence" to be consistent with the rest of the document.

I would like to see Secretaries serve 2 year terms to reduce the churn. Also, for the initial 3, one would serve 1 year, the other two would serve 2 year terms. This would stagger the incoming secretaries and mean that there would be less of an impact on the continuity of any ongoing projects. (At least one secretary would remain in office each year)

Cheers!

=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/22802359-0739-4e0e-8f51-003f3827a689%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Culture of Respect

How to find, hire, and retain developers

[Larry Garfield]

Agreed on the second point. I have been involved in other organizations
where we had that sort of "staggered" term. In particular, we had a 3
person committee where everyone served 2 year terms, offset by 8
months. That way there was a regular overlap of one person going out
and another in every 8 months, reliably. (I don't see a reason we need
to have term limits or anything in our case.)

If 2 years is too long of a term, the same concept still applies just
with a shorter period. Like the US senate, 3 people means we should
have an election for 1 person every 1/3 of whatever the term is so that
there's always someone with experience in the role there.

We should also define how we handle a vacated position. Special
election to fill out the remainder of the term is the obvious mechanism,
and I'd be fine with that.

On 11/16/15 2:47 PM, Cal Evans wrote:
> In the section "Selection", I would change "vote of confidence" to
> "vote of no confidence" to be consistent with the rest of the document.
>
> I would like to see Secretaries serve 2 year terms to reduce the
> churn. Also, for the initial 3, one would serve 1 year, the other two
> would serve 2 year terms. This would stagger the incoming secretaries
> and mean that there would be less of an impact on the continuity of
> any ongoing projects. (At least one secretary would remain in office
> each year)
>
> Cheers!
> =C=
>
> On Sat, Nov 14, 2015 at 6:11 PM, Michael Cullum <m...@michaelcullum.com
> <mailto:m...@michaelcullum.com>> wrote:
>
> The suggestion of a new FIG secretary role was initially suggested
> at the ZendCon FIG summit and later discussed on the mailing list
> and since then Joe Ferguson and I have worked on expanding the
> ideas raised in those discussions[1] into a more complete
> proposal. Obviously it is not complete but the aim was to get a
> good base upon which we can build upon and adapt. Once the details
> and contents has been decided upon we can format it correctly into
> the style of a bylaw, send a pull request and a vote could be
> commenced.
>

> *Link as a formatted
> gist:*https://gist.github.com/michaelcullum/782b1bba4411a3db7cc5
> <https://gist.github.com/michaelcullum/782b1bba4411a3db7cc5>
> *_Pasted contents:_*

> <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/22802359-0739-4e0e-8f51-003f3827a689%40googlegroups.com

> <https://groups.google.com/d/msgid/php-fig/22802359-0739-4e0e-8f51-003f3827a689%40googlegroups.com?utm_medium=email&utm_source=footer>.

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

> *Culture of Respect <http://bit.ly/1tOIyjG>*

> How to find, hire, and retain developers

> --
> 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/CAPf%3DPyJUr%2BBig%2BiV53ay-OgUk1%2BSzJhmS%3D%2BEhH1bjQ5pV9r6WQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAPf%3DPyJUr%2BBig%2BiV53ay-OgUk1%2BSzJhmS%3D%2BEhH1bjQ5pV9r6WQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

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

--

--Larry Garfield

[Cal Evans]

+1 for special election to fill vacated seats.

=C=

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/564A41AD.5050801%40garfieldtech.com.

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

--

Culture of Respect

[Jeremy Lindblom]

This bylaw sounds good to me. Nice work writing this up.

--
Jeremy Lindblom (@jeremeamia)
Software/Platform Engineer at Engrade (part of McGraw-Hill Education)

Co-founder of the Pacific Northwest PHP Conference (@PNWPHP)

Co-author of the AWS SDK for PHP (@awsforphp)

PHP-FIG Representative for the Guzzle project

Looking for a senior-level software engineering position doing PHP? I have some available with McGraw-Hill Education in Seattle and Los Angeles (Santa Monica or Irvine). Contact me for me more information.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAPf%3DPy%2B8LGLAdFK33efMj_cgdt3kM%2BGQ7JMEbOk%3DG72siB1uyQ%40mail.gmail.com.

[Korvin Szanto]

I like this change, I appreciate the work on this. One question, what are the specific remaining responsibilities of the "coordinator" role? Is tallying the only thing that coordinators no longer do?

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

[Dracony]

As for "Tracking member project activity, and marking projects as inactive" I was actually thinking about making an app for that. Just show number of emails per member per thread per month or something. This would be a sort of impersonal soft policing nobody would have a problem with.

[Michael Cullum]

Sorry for the lack of inline comments, I'm replying on my phone whilst I have a free 10 minutes.

I agree that we should never have all three leave at once, hence the provision for an additional term being allowable to prevent that but if we don't see a need for a maximum term then we can remove that and just add a note that secretaries shouldn't all leave at once?

The idea of one year terms is longer terms are a much larger commitment and whilst most will serve more terms (2 or more years?) it allows for an easier way to leave that resigning and it also allows for an easier way to get rid of someone than a vote of no confidence.

I meant to add a note that resignation would trigger an immediate special election but ommitted it accidentally.

Co-ordinators would still hold *responsibility* for their individual vote counting in theory but in practice the secretary's would have to do this anyway to keep track of project activity and impartiality checking so the coordinators can just get the count information from the secretaries I think. This just means errors are less likely and there is more checking in place.

I will ammend the draft and post up a PR tomorrow.

--
Thanks,
Michael Cullum

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

[Michael Cullum]

Dracony,

I missed your reply earlier when I made mine.

Activity would be tracked how it always has been (and how it's been stipulated in the bylaws) which is through votes? We don't require member projects to dive into the ML every five minutes, we do require them to vote (For full requirements see the bylaws). I don't see any reason to change that as it was discussed long and hard and agreed upon and people seem happy with that. This bylaw isn't about changing that, it's just about providing someone to fulfil that role that gets neglected and done by a string of random individuals.

--

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/0e9c4003-6ba7-46b3-9b3c-5d4532e73450%40googlegroups.com.

[Roman Tsjupa]

Ahh no, I did not mean that there should be some enforced ML participation, not to mention a bylaw. It's just a small weekend project I had an idea for, totally separate from the actual FIG workflow. 

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

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

[Michael Cullum]

So I've made discussed changes and worked it into a pull request. https://github.com/php-fig/fig-standards/pull/673

I apologize for the slightly ugly diff on the PSR Workflow and PSR Amendments bylaws with removing random . I hope it's clear (from github's darker green highlighting) where I've actually made content changes.

I suspect there will be a PHP FIG summit at PHP World this week so I'll wait to see if there is feedback from that but otherwise this is probably almost ready for a vote.

--

Thanks,

Michael Cl

[Michael Cullum]

After the discussions at PHP World (Full notes will come at some point soon) this has been updated to use Single Transferable Vote for the first vote, normal voting protocol when one person is nominated in future votes and Instant Runoff when more than one person is nominated in future votes. Also after the summit at PHP World the terms have been adapted to be two years long with one term ending every 8 months.

At the meeting it was agreed that IRV would be used and STV was not mentioned but IRV cannot select multiple people (by its definition) and STV is the multiple selection equivalent. You're welcome to look them both up (https://en.wikipedia.org/wiki/Single_transferable_vote and https://en.wikipedia.org/wiki/Instant-runoff_voting). STV becomes IRV when selecting one person and IRV becomes STV when selecting multiple people.

This should now be in an almost complete state so please do point out any typos/errors or anything content-wise you disagree with.

Thanks,

Michael C

[Brian Retterer]

Michael,

Thank you for your updates here.

A few other things that we talked about were fully describing what happens when a Secretary resigns from office or is voted out.  My suggestion here was that we vote in a new member and they will only be voted in for the remainder of the term.  

I also suggested during the meeting that we begin the voting process 4-6 weeks before the end of term so we don't have any lapses. 

These were my two thoughts on the matter, everything else looked good to me sans some fine tooth comb reading.

Brian

[Michael Cullum]

Hi Brian,

Comments are inline.

On Monday, 23 November 2015 17:18:03 UTC, Brian Retterer wrote:

Michael,

Thank you for your updates here.

A few other things that we talked about were fully describing what happens when a Secretary resigns from office or is voted out.  My suggestion here was that we vote in a new member and they will only be voted in for the remainder of the term.  

This is there in the paragraph about resigning.

 

I also suggested during the meeting that we begin the voting process 4-6 weeks before the end of term so we don't have any lapses. 

Well, the vote would be a standard two week vote. Then nominations would happen in the weeks leading up to that so it probably would be about a 4 week process anyway. I don't think having it earlier will help and we do have three people at any one time anyway so handovers should be quite easy and if we ever experienced and issue and only had two for a couple of weeks due to no nominations that wouldn't be a huge problem anyway. 

[Mike van Riel]

Hi Michael,

Thanks for taking point on this effort. Conceptually I have nothing to add but say: good job :)

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/c0bcfecb-3f5e-4b28-afd7-c6d00c564945%40googlegroups.com.

[Phil Sturgeon]

I was doing most of this for the last few years before somebody took my keys off me. I'd be happy to help out once again.

I no longer have a project listed as a member. I believe in this group and want to help it succeed. 

[Korvin Szanto]

One more day left, it looks like we've had 35 members vote, lets hear from the remaining 10!

On Wed, Dec 9, 2015 at 12:02 PM Phil Sturgeon <pjstu...@gmail.com> wrote:

I was doing most of this for the last few years before somebody took my keys off me. I'd be happy to help out once again.

I no longer have a project listed as a member. I believe in this group and want to help it succeed. 

--

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/28ef7350-35ee-46f0-b3bf-e0141bbd1335%40googlegroups.com.

[guilher...@gmail.com]

+1

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

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

--

Guilherme Blanco
MSN: guilher...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

[Robert Deutz]

+1 Joomla

Robert

[Korvin Szanto]

I appreciate the extra support, but this isn't a voting thread :)

--

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/363ff468-0475-4cca-9fa8-b68d0076942b%40googlegroups.com.

[Robert Deutz]

Whatever :-)