To all FIG project representatives:

Like those who have posted before me, I too am writing to the list today to 
request a nomination to the FIG 3.0 Core Committee. I'm asking for a 
nomination on the mailing list as I do not have a strong personal 
relationship with any voting members.

For the many of you that don't know me, allow me to introduce myself - I'm 
Michael, a polyglot developer based in the UK. I've been writing code 
professionally for about a decade for all kinds of clients, from tiny one 
person companies to code that processes 100% of the Facebook firehose 
(see http://blog.datasift.com/2015/03/10/datasift-and-facebook-partnership/). 
Over the last few years I've really doubled down on conference speaking, 
presenting on topics as varied as application profiling to deploying 
WordPress (see https://michaelheap.com/talks/). I've also made some 
contributions to open source projects, but not as many as I'd like.

So, why vote for me as a member of the core committee? The answer lies in 
what I'm not, rather than what I am. I'm not deeply involved in various 
open source projects. I've not been vocal on this list (though I have read 
this and internals for years). In short, I'm not your typical FIG member. 
Instead, I've spent time working with companies that want to standardise 
and adopt new technology, but don't know where to start. These companies 
cover both ends of the spectrum - from monolithic projects to dozens of 
microservices, from deploying with FTP to immutable infrastructure. The one 
thing they all have in common is that they want to adopt the standards that 
the FIG are producing - both to improve their own code base and to reduce 
the learning curve for new hires. By joining the core committee, I believe 
that I can help by providing practical input that will help everyday 
companies adopt new PSRs.

If you ask those that I've worked with to describe my working style, they'd 
tell you that it's "strong beliefs, loosely held". The end result, whilst 
important, isn't the only thing that we should consider. The journey 
towards any solution is one of the most important parts. Making sure that 
every edge case has been considered (even if it's been considered and 
discounted) is imperative to arrving at solutions that are robust and 
applicable for all.

Thanks for reading this far, and I'm more than happy to answer any 
questions that you may have.

Cheers, Michael



-- 
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/89f794b9-d3f5-4d5e-92d3-d0389aaf2d0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to