Events are great because they bring people together.
In scenarios where there isn’t already a cohesive group, organizing an event has two risks:
Will enough people sign up to make the planning effort worthwhile?
Will the people who signed up actually show up?
A Kickstarter for events could solve these two problems.
First, the event would have some minimum number of signups required for the event to happen. It doesn’t happen if it doesn’t achieve critical mass.
Next, the organizer would track which signups actually show up at the event. This data could then contribute to the attendee’s reputation score on the platform, and calculate the likelihood of attendence.
Problem worth solving? It seems mundane but I keep wanting this for situations I come across in the real world.
Woke up at 4 am. Worked on my presentation for a few hours. Went to Stafford Hills for a 45 minute swim and quick hot tub. Got feedback on my presentation from Joe. Took a call on prospective consulting project. Ate lunch — leftovers from an amazing Indian meal Leah made last night. Kissed my wife and kids goodbye for the week. Hacking at the airport now. Flight to Seattle, and then on to London, later.
Last night, I presented to ~25-30 people at the PDX PHP meetup on “WordPress as an Application Platform”. Even though I’m no longer with Human Made, I think what they’ve done with WP Remote (and Happytables) is the bleeding edge and worthy of sharing.
Ultimately, the point I wanted to get across is two-fold:
Many applications you could think of building are easily doable with WordPress.
WordPress-based products are even more interesting when you have a few, and durable components to share between them.
We tried not one but two experiments this year: specifying an overarching theme, "permanence", and requiring applications to be submitted by video.
It’s working out awesomely. Earlier this week, we announced our primary lineup of speakers. I suppose it’s a given because I’m the speaker coordinator, but I’d love to attend every one. They all tie into our theme of "permanence", yet stand strongly in their own right.
And, as if those sessions weren’t enough, we’ve invited Brewster Kahle, of the Internet Archive and the Wayback Machine, to give a keynote. We also have one more keynote to announce.
When we began planning this year’s WordCamp, I knew I wanted us to push hard to raise the bar. There are enough WordCamps happening every month, and subsequently talks making it to WordPress.tv, that the status quo shouldn’t be a generic, third time old presentation. Our idea: if we mandate video applications, and only one per person, it would encourage potential speakers to consider their pitch thoroughly. Furthermore, videos would enable us to better assess the person’s stage presence and ability to communicate concisely, both of which are important for inspiring an audience.
It’s safe to say we didn’t know if the idea would work until the day of the deadline. Up until the last 12 hours, the outcome was unknown and, frankly, a little nerve-wracking. In total, we received ~25 applications; 90% were submitted on the last day. It paid off though. Most of the applications were solid, obvious examples of much consideration, and the video format was a tremendous help for screening.
Go out on a limb every once in a while, take a risk, and see how it plays out.
We did a second pass at our code review meetup — last night turned out much better than the first. The high point for me: most of the “presentation” was, in fact, discussion. The latter proved to be way more valuable for everyone, as most of the twenty people in the room don’t do code review on a regular basis.
Here’s what we did:
Jeremy Ross submitted a section of code he had been working on, along with instructions on what he wanted feedback on.
On Saturday, I reviewed the code. I committed it in one commit to a branch in a private Github repo. On the changeset, I did a line-by-line read-through, commenting as I went. To wrap the review up, I created a pull request explaining how I did the review, what I looked for, and how to interpret my feedback.
Saturday night, I prepared a reveal.js presentation with an introduction to code review and the contents of what I found in my review. reveal.js is a super slick tool for preparing a HTML/CSS/JS presentation out of content in Markdown.
Jeremy read and considered my review, then updated the presentation with his feedback.
I did most of the presentation discussion facilitation, and Jeremy talked through how he received my feedback.
Code With Me, a two day introduction to HTML/CSS/jQuery for journalists, came to Portland last weekend. Even though it was beautiful weather outside, forty students and twenty mentors gathered deep within The Oregonian to improve their digital chops. Just think a bit on those numbers — that’s a lot of people.
Last December, I reached out to Susan Gage, managing editor for digital at The Oregonian, about hosting a hackathon. We had initial conversations about the idea, pulled in Lauren and Ivar, and started planning. Then, in February, I began hearing a bunch about Sisi, Tom, and Code With Me. I got the full download on how Code With Me works from Sisi at NICAR. After a brief discussion with Lauren and Ivar, it became obvious bringing Code With Me to Portland was a much better idea than a hackathon. So we set about convincing Sisi and Tom it was worth their time.
What worked well:
Tom and Sisi have spent a lot of time considering their approach and pulling resources together. All of their effort showed.
All of the exercises were available online during and after the presentations. Useful for students to review.
Each student had a printed reference sheet with many of the topics we covered.
The paper coding exercise was amazing. It was a hands-on, physical application of very digital knowledge, and also promoted discussion between students.
Twenty mentors donated their weekends. Wonderful support from the community.
Refresher for mentors on teaching strategies. Even though we only had two students to work with, it was still challenging to switch into teacher mode, adapt to different learning styles, etc.
Assistance with scoping student projects.
Provide a set of tools/resources (e.g. jQuery plugins, TableTop.js for transforming a Google Spreadsheet, etc.) mentors can refer to when helping students build their projects.
Some logistical notes:
Saturday lunch: Cultured Caveman is a delicious food choice, but one needs to be a little more deliberate about what you need. We were short on some vegetarian options.
Mentor dinner: The Picnic House was the only place, of the half dozen I called, I could find to accommodate a party of twenty on Saturday night. Good deal for the associated costs. Service was a little slow / awkward.
Sunday lunch: Cha Cha Cha has the catering thing nailed. Enough food and options for everyone’s dietary needs.
After the weekend, here are the open questions I’m thinking about:
How can we better enable educators to teach these skills to their students?
Do students have the opportunity to apply their new knowledge? How do their skills progress over time?
For those of us who want to continue contributing as mentors, where do we go next? What’s the most valuable use of our volunteering time?