So here we are, just before the festivities, with a few bits of good news!
In the previous blog post, we were discussing how to push forward the PSR interfaces, to keep up with all the new features that PHP is giving us, version after version. I proposed a new bylaw which went through a long discussion and many revisions on GitHub, but which is now approved and in effect!
Larry Garfield has already started working on using it on PSR-13, as a testbed for this approach. We're confident in it, since it's being used by other big libraries, like Symfony (with version 5) and Doctrine (with the next majors of its sub-libraries).
As always for us, every 8 months we need to start a new election cycle. This is due to our bylaws, and it helps us to have new people in our ranks, without shuffling all of them at the same time.
We have one secretary and four Core Committee positions up for election. The terms that are ending are currently held by:
The nominations period, due to the holidays, will be a bit long, and it will be open from December 20th 2019 to January 9th 2020. The elections will be held immediately after, from January 10th to January 23rd. You can find the full announcement on our mailing list.
If you are interested in helping and joining us, please reach out to us, through our mailing list or contacting any sitting secretary.
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 PHP-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 PHP-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 PHP-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).
The full role can be read from the bylaws here: http://www.php-fig.org/bylaws/mission-and-structure/#secretaries
Between the three secretaries they handle all the administration that goes on with the FIG such as votes, the website, GitHub as well as also being responsible for moderation of FIG mediums and representing the PHP-FIG to the wider PHP community. Feel free to reach out to any of the sitting Secretaries if you would like to know more about the role.
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 CMSes, 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 rather who would make the most well-balanced core committee that accurately represents the interests of you, the member projects and wider PHP community.