My First Patch, chapters 1-3

My first patch to an open-source project was for Dreamwidth, which is a wonderful hosted blogging community built on a fork of the LiveJournal codebase, with an unusual commitment to supporting devs even if they’ve never written a single line of code. If I remember correctly, I added the trailing zeroes to whole-dollar prices in their store so the numbers would line up correctly.

My first patch to WordPress was one line of CSS changing the width of a table. Some people really hated the change, and anyway, the entire project it was part of eventually got rolled back because it wasn’t going to be ready for release time.

My first WordPress props only came after I signed up for a team and volunteered for a whole new feature, which I never would’ve had the guts to do if I hadn’t dipped my toes in first (and sat in on meetings, and followed lots of tickets, and learned who ask questions of, and generally watched the whole process through a cycle) (also, I got fired up by a WordCamp talk and tweeted to a bunch of people that I wanted to get at least one patch in 3.4, and public commitment is powerful stuff).

Ever since I went to AdaCamp, but really, ever since Dreamwidth, I’ve been really interested in new developers’ experiences. I still consider myself one, for one thing, but also, every dev I know, no matter how amazingly skilled or outwardly confident, has or once had a bit of “am I good enough for core?” And really: tiny patches and openness to learning really are good enough.

If you have a good first-patch story, tell me! Or better yet, put it in your own blog and let me know!

WPTRT Review-a-thon tomorrow

The Review Team has been playing around with ideas to get through our backlog of themes to be reviewed, so I’ve proposed an IRC meetup in #wordpress-themes on Freenode, tomorrow at 1700 UTC / noon US Eastern.

The model I have in mind is

In particular, I want to invite any new or wanna-be reviewers to join in; this would be a great chance to get started with reviewing, get your test environment set up and work through your first few reviews with help on hand to understand how the guidelines work.

We have just a few ground rules:

  • This isn’t a meeting with an agenda: it’s a group work day. Drop in for as long as you’re available, and get as many reviews done as you can during that time.
  • The goal is to crunch through as much of the queue as possible while helping and learning from our peers.
  • All reviewers, however new or experienced, can bring questions about how to handle particular issues. Absolutely no penalties for admitting you’re stuck ;)
  • Themers, you’re welcome to join in the discussion, try your hand at reviewing, or just lurk and learn the process. However, please don’t use this time to ask about when your own theme will be done — we’re taking everything in queue order, and we’d most likely just encourage you to sign on to review a few themes.
  • For new or potential reviewers, more experienced people will try to help out as much as we can with getting started, working with trac, setting up your test environment and the like.


Contrib-o-rama week 1

I started the year with a plan (I won’t call it a resolution. They don’t work and I dislike them.) to give back to my communities, both online and off, in small but countable ways, as a regular practice. Bigger bang-for-the-buck is on the list too — it’s an important goal of mine to do some substantive work on WordPress core this year, for instance — but the key to the bigger plan is making the small stuff happen every day. As such, the very first contribution of the year was a list of ideas that includes not only “submit a patch” and “release a plugin” but also smaller things like “answer someone’s question” and “participate in a meeting”.

If (like me) you’re just now looking for where to started, those small things are the big things. If (also like me) you’re prone to having a whiteboard full of big ideas and no time to make them all happen, the small things are a way to make sure you at least take a crack at something. But most important, the small things start to add up surprisingly fast. I got more theme reviews done in the first week of January than I did in certain whole months of last year, in large part because I didn’t want to leave too many gaps on that damned page.

I also want to kill that damned page. I started off with a manual list in order to give myself just enough pain to keep me moving on the plugin version. As I intended, it’s driving me nuts. So I’m digging away at turning the manual list into a slightly less manual list.

So what does it need to do?

  • Allow easy and automagical connection to the obvious things like WordPress Tracs and Github commit feeds
  • But don’t limit it to WordPress or for that matter to any one project. It’s meant to be a contribution-focused lifestream, not a project widget.
  • Incorporate things that don’t natively live online. The internet isn’t and shouldn’t be the only thing that counts. This is most easily done by allowing manual additions rather than limiting the stream to feeds only.
  • But still require that things are verified in some way: if a direct link to a changeset isn’t relevant, then… what? A URI, time/location stamps, anything else? What it points to gets into the somewhat philosophical problem of verifying anything; but at the same time, the stream shouldn’t be just freeform diaries or status. It must point to something real.

And maybe someday:

  • Social proof. Collaborators. Pretty reports and graphs and things. Others?

A contribution a day

Last year, I (again) watched various post-every-day efforts with a lot of hope and interest and (again) utterly failed to live up to them. Still, I like the idea of daily or weekly discipline, and while I know I won’t blog every day or even every week, I figure I can try to do something to contribute, however small:

In your tech community 1

  • Answer someone’s question in IRC or the forums
  • Write a really good bug report
  • Comment (intelligently!) on a trac ticket
  • Participate (don’t just lurk) in a team meeting
  • Review a theme
  • Document
  • Submit a patch
  • Release a free plugin
  • Release a free theme
  • Post your work-in-progress in public. Even if it’s not ready for release, even if it’s just a gist sketching out an idea in pseudocode, it may help someone else. Plus, sufficient eyes, all bugs shallow, yadda yadda.
  • Write a blog post with the intent to inform or debate. As opposed to, say, posting cute pictures of teh kittehs. You can count those as a bonus, if super-cute.

In the outside world:

  • Next time the call to fix your parents’ computers comes in, do it in a way that teaches them to be one small step more self-sufficient the next time.2
  • Volunteer your tech skills for a non-profit in your real-world community.
  • Teach kids to make robots, write code, build games, or just tinker.
  • Give a presentation. Start with your local BarCamp if you’re not yet the kind of rockstar who gets flown around the world to talk.
  • Join a local meetup. Present at a meeting. Help organize a hackathon, pair-programming day, or codefest, and help someone less experienced there.
  • Check out Random Hacks of Kindness or a similar geeking-for-global-good organization.

Obviously, these aren’t all one-day ideas, and you don’t have to check off every box on the list. But I think it’s worth making a habit of contributing time, skills, and knowledge. It makes the universe a shinier, spiffier place. So who’s in?

UPDATE: To start out, I’m tracking things on this page. Better and less manual  developments to come.

  1. As always, my examples are mostly WordPress because that’s where I hang out. But most of this, or something very similar, also applies to whatever your project of choice.
  2. Teaching technology is HARD. I used to make a living at it, and it’s miles easier to just grab something and fix it than to help the user understand what to do themselves. It’s also incredibly rewarding. Try it sometime.