[Internals] [FIG 3.0 Transition] Core Committee Nominations Open

[Michael Cullum]

Hi all,

The nominations for the Core Committee open today. Below are some details and FAQs.

Anyone can be nominated (including Secretaries or project representatives but if a Secretary is elected they must then resign as Secretary).

Member projects and Secretaries may nominate anyone, or many people, to be CC candidates.

If you would like to nominate someone, please get in touch with them and speak with them about it first. But please do seek out people you think should be on the Core Committee to nominate them, don't wait for them to ask you to nominate them.

If you would like to stand/accept a nomination, please contact me, Samantha, Amanda (or Larry) to find out a bit about what the role entails. You may seek a nomination any way you wish (requesting on the mailing list or asking individuals in private).

If people could also help spread the word (via Twitter and the likes) about this, so we have a good selection of candidates from different parts of the php community, that would be much appreciated.

A list of nominees will be maintained here. Please ensure that you confirm your nomination if you wish to and someone nominates you.

Nominations close on the 10th November at 23:59 UTC (Keep in mind DST changes).

FAQs:

What does the role entail?

To quote the Bylaws:

The Core Committee is a twelve (12) member board of individuals recognized for their technical skill and expertise. The Core Committee is responsible for final decisions regarding what specifications FIG will consider and those that are approved. The Core Committee is responsible for ensuring a high level of quality and consistency amongst all published specifications, and that all relevant perspectives and use cases are given due consideration.

 

The core committee acts as a steering group and handles all entrance votes and, after being completed by working groups, has the final acceptance vote on new PSRs and is responsible for making sure specifications meet the technical direction of the FIG, are of good quality, and have taken relevant stakeholders into account. The core committee is expected to be able to keep an eye on what is going on in the FIG. While this doesn't mean reading every mailing list post or every GitHub issue, this does mean having a general awareness of what is going on and regular activity is expected (e.g. they should be voting on every core committee two-week vote unless there are particular circumstances preventing them from doing so).

What's the timetable?

• 1st November: CC Nominations open
  
• 10th November: CC Nominations close
  
• 11th November: CC Election voting begins
  
• 25th November: CC voting ends
  
• 26th November: CC results announced
  
• 27th November: CC takes post
  

Election Process Summary

After nominations close then voting will start. Member projects can vote, as can any community member judged to have participated actively in the FIG (there are subjective and objective tests for this in the bylaws, this will be clarified when the vote occurs). After which 12 people take post. The top four will have terms until August 2018, the next four until January 2018, and the final four until May 2017; after which they may be re-elected. Voting is done through STV.

For more information please read the bylaws or the FIG 3.0 TL;DR.

What does a balanced Core Committee look like?

The idea of the core committee is that it should reflect a cross section of the PHP ecosystem and community.

This means it's important to have a range of people including (but not requiring or limited to) those with experience relating to things such as:

• Large & small framework maintenance
• Library maintenance
• Consumer package maintenance (by consumer package I mean CMS, blogs, forums, etc.)
• HTTP and non-HTTP based PHP
• Legacy and modern projects
• PHP internals
• Specific topics such as Async and Security

However, it is important to note that you are voting for people, not projects, so please do not vote in people because they are the lead on 'Project X'; but rather you might vote for them because they have experience as a framework maintainer or legacy project maintainer and therefore have a different view on things. CC members should be representing the opinion of the wider PHP ecosystem and community as CC members, not of projects they are affiliated with, and some will likely not be affiliated with any project at all. Furthermore, this should not become a popularity contest of 'who is the most well known' but who would make the most well-balanced core committee that accurately represents the interests of you, the member projects and wider php community.

--

PHP FIG Secretaries

[Michael Cullum]

Just a few of clarifications:

- You can nominate multiple people, in fact, this is to be encouraged so we have a good number of CC candidates (15-20).
- You can nominate yourself if you are a project representative (if you wish)
- Only project representatives and Secretaries can nominate people

Most importantly:
- If you would like to be on the CC but don't know someone to nominate you then please send an email to the mailing list or approach a secretary. The point of nominations is not to exclude people who would be capable of doing the job just because you aren't friends with any FIG members.

--
Many thanks
The FIG Secretaries

[Adam Culp]

Sorry, and I hope I'm not beating a dead horse, but when did the Secretaries gain power to nominate? This would indicate they are no longer overseeing the process, but are part of the process. Do they now get to vote as well?

Seriously not trying to cause trouble, just looking for clarity.

Regards,

Adam Culp

[Glenn Eggleton]

Hi Adam,

It looks like it's power creep from FIG 3.0.

https://github.com/php-fig/fig-standards/pull/752/files#diff-7aeee0a55f5e81ea8a0b5f9dc76c6822R19

Cheers

[Michael Cullum]

Adam & Glen,

This has been in the bylaws since the Secretary role's inception almost a year ago in that Secretaries could nominate Secretaries for election and this same logic was carried forward to the Core Committee in the FIG 3.0 bylaws. This is explicitly defined in the bylaws which have been voted upon in both the initial secretary introduction vote (secretaries nominating secretaries) and in the FIG 3.0 vote (secretaries nominating the CC). It's also been exercised at least one (Andreas Heigl, a previous Secretary candidate, was nominated by a Secretary in the past).

When we speak to potential nominees we always tell people to approach project reps who they know for nominations or post to the mailing list requesting a nomination but sometimes this is difficult if you are someone who is capable of doing the job but just not friends with any project representatives, or perhaps there is not long before the deadline for nominations. The point of the nomination process is to ensure that someone involved in the FIG supports your application in that they believe you know what the role entails and should be eligible to be on the ballot. It is not, however, an endorsement that they think they should get the role, just that they should be eligible for the role and it's then up to the electorate to decide if they should get the role. In the same way nominating does not mean you will put someone as your first vote (as shown in previous secretary elections). We [secretaries] will only nominate people who we believe are aware of the job and capable of doing it but don't have any project representatives to nominate them and we will nominate them in order to ensure a wide field of candidates for voters to choose from.

I hope that clarifies the bylaws & history and allays any concerns you might have.

--

M