Recently in a conversation on Twitter the topic of what a successful conference proposal - one that gets accepted - looks like, came up. I thought I would expand upon the conversation and the "3 key takeaways" advice I gave, by providing the raw submissions I entered, in this case, to PHP Tek 12, as well as some lessons learned and additional commentary.

He shares his thoughts on what kinds of things it takes to get accepted (note: one is "luck"), what some of his example proposals look like, how to deal with some of the pre-conference jitters and a few final tips on getting that "accepted" email.

The ConFoo team just opened its call for papers. Candidates can submit proposals until September 23. Consult the call for papers page for details and to start submitting. That page also explains what expenses ConFoo can cover for speakers. You can even get advice on how to write proposals. The call for papers is public, meaning that all proposals get published on the website for others to vote and comment on.

This year's event is happening from February 25th through March 1st in Montreal, Canada with tracks covering things like .NET development, Project Management, Web Standards, DevOps and, of course, PHP. The Call for Papers closes on September 23rd so you have less than a month to get your proposals in!

As any of you who follow the PHP internals list know, scalar type hinting has been a hot topic as of late. You'll also know that I've submitted two new RFC (Request For Comment) proposals for inclusion of two new major features in the PHP language. I figured it was worth going into both RFCs and patches a little deeper, explain my rationale and (hopefully) garner some more visibility of the proposals.

He shares the details of the two main RFCs that are proposed right now - parameter type casting hints and object scalar casting magic methods (both with code examples). Right now, they're only in the patch stage and there's talk of improving the current casting functionality of PHP before something like one of these goes into place.

Today I will be discussing a feature that at this moment is called "Property Accessor". It is a method of defining getters and setters. Originally an RFC was defined as early as september 2009, but recently new discussion took place and an actual patch was created. There is no certainty this feature will ever make a PHP version but discussion seems to target implementation details and not the feature itself, so things are looking bright for this feature.

There's two RFCs posted about the topic - the original proposal (from Dennis Robinson) and a patch for implementing them (from Clint Priest). The proposal replaces the common magic getters/setters (__get & __set) with the optional "get" and "set" keywords inside of custom-defined properties.

I guess with me and Pierre leaving it did spawn a lot of energy about how to organize PEAR in the future. I am still participating in this discussion to some extent, mainly functioning as the historian who can explain why things are the way they are etc in order to prevent people from making rash decisions or even worse repeating old mistakes.

He also comments on the state of package submissions to PEAR, noting that some of them are just unrealistic and that it might be better to start a "PEAR2" side to allow for some of these more expanded ideas to flourish.

Instead I think each of the categories should manage itself more. So packages approval would be handled within the category. The same for QA'ing etc. This way new developers would not be facing this gigantic community. I think this is simply overwhelming. Even for old developers it becomes impossible to feel "at home" in a project of the size of PEAR.