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 <http://bit.ly/cc-election-candidates>. 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 <http://bit.ly/fig-3-0-full> or the FIG 3.0 TL;DR <http://bit.ly/fig-3-0>. *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 -- 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+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAqcDMhtOsjCvL0aqATpq3Ry_oMUjVJpHyykO9sF9VJVBBQPRg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
