Unfortunately Go's lack of generics hurts in letting me use these helpers in a way that guarantees the data types going in/out of the generic channels.
Promote the hell out of it on Twitter, Reddit, Hacker News (done). Apply to speak at conferences and go speak about it. There are plenty of PHP conferences to choose from. Get your employer to pay for the trips.
The problem for me was that the example you gave (yourself) was way too meta for the typical end user. It needs to be more obvious what the problem is. For this reason "Does this solve your problem?" is a horrible opener.
Here's the process: (1) State the problem, (2) Propose your solution, then (3) ask for feedback.
Overall: Don't make me think. You're never going to get replies otherwise. A big textbox is daunting.
I imagine this almost as a streamlined "proposal" process. Lets say you get an RFP from Widgetia, a company that creates and sells widgets. You get the RFP (problem), then you write a proposal (comprehensive or not) to address the the problem. Because this is on the web, you can use text, photos, video, whatever. Just communicate the solution as efficiently as possible.
Then your job is to ask people to identify. "Does this sound like you?" "Would this work for you?" Don't put just one textbox. Put a couple -- in strategic spots in your presentation. You'll gather better contextual feedback as well as gather analytics on when/where people are commenting to gauge how effective your presentation was.
The best teachers teach humility toward the subject matter.
For technology in particular, there is always so much more to learn that by not having humility there is no incentive to want to learn, which is arguably the strongest point to make. Teaching is not one-way. Students have to want to learn just as much as teachers want to teach.