FOSS

Totally, Utterly Petty Reasons to Contribute to Open Source

Posted on by

Yeah, I know you have big highfalutin’ ideals about Open Source being better software made with better development practices to better serve truth, justice, and yummy ice cream for everybody. I have those too. But let’s be honest — there are plenty of completely shallow, selfish, and totally un-idealistic reasons to do it too. How about:

  • You want to whip out your phone at the bar and say to your friends, “see that link? I made that one.” (Note: you might want to look into some better bar tricks.)
  • You really, really, really hated that typo, even if it was in inline docs and the general public never knew it existed.
  • You contributed to the last two releases, and three of anything makes a streak.
  • You contributed to the last three releases, and if you break your streak now, you’ll feel totally OCD about the gap in your record for ever and ever.
  • You feel an unhealthy attraction to those big buttons on http://scotchisforshippers.com/

The thing is? Who cares what your motivation was! The patch is still another tiny step to making the whole project better. The fact that your motivations weren’t quite on the level of world peace and ending famine is between you and your text editor.

The CSS-Tricks License | CSS-Tricks

Posted on by

The CSS-Tricks License is one of the most delightful (and funny, and, yes, thoughtful) open licenses I’ve ever seen.

I don’t give two hoots what you do with any of the design or code you find here.

Actually, I do. I hope you take it and use it, uncredited, on a super commercial website and get wicked rich off it. I hope you use it at work and your boss is impressed and you get a big promotion. I hope it helps you design a website and that website impresses somebody you think is super hot and you get married and have smart, chill babies. I hope you use the code in a blog post you write elsewhere and that website gets way more popular and awesome than this one.

And it goes on from there. Every word is about the spirit of the thing, not just the fine print. Oh, yeah.

Introducing sassy_s

Posted on by

I’ve been using Underscores (aka _s) for all my base theme needs since pretty much the day it came out. And I’ve been using Sass for more and more projects — so, inevitably, I started smooshing the two together.

Sass actually makes it really easy to do this, at least if you use the default .scss format. All valid css files are also scss files; you can just take your css file, change the file extension to .scss, and start throwing around variables and functions and all that Sassy stuff. But while it’s easy to get a project rolling that way, it leaves something to be desired organization-wise.

One of the very cool things about Sass is that it assumes that you’ll work with multiple files (partials, in Sass-speak) and compile them into one at the end; renaming the big stylesheet and working from there like I’d been doing still left me searching through a lot of lines of code to find what I needed. Ideally, I’d have a file for menu styles, a file for media styles, and so on. Even better, I’d be able to drop in a file of my own favorite mix-ins without recreating them for each project. I always set up my color schemes first thing, my base fonts and line heights, set up clearfixes and assistive text the way I want them, set up common styles for borders and boxes and the like; the values change, but what I’m styling has a lot of the same structure from project to project. (That one’s not included in the repo, but I’d love to hear about other people’s favorites.)

So to make more lazy level up my own practice, I finally took the time to make all this into a properly organized repo. Y’all can grab it here: https://github.com/sabreuse/sassy_s

A couple of notes:

  • sassy_s is just a refactoring of the stylesheet — not a complete starter theme. It’s designed to work with a copy of _s, not replace it.
  • I’ve provided links to a couple of beginning Sass tutorials, and a couple of inline examples, but there are lots of great resources out there for installing and using Sass. If you have Sass questions, they’re the place to start.
  • The sass --watch command will overwrite your style.css with every change. Start with a fresh copy of Underscores and copy over your style.css header first. Don’t add this to a theme you’ve already made (unless you’ve got it under version control!)
  • If you’ve heard that you can’t use Sass if your end-users don’t run Ruby on their servers, fear not! In almost all cases, you should be running Ruby and Sass on your development machine, then exporting your Sass to a normal CSS file. It’ll run just as well as any other theme.

Getting started on IRC

Posted on by

PyLadies PDX has a great resource for getting started on IRC: Getting Started on IRC – PyLadies PDX Portland, OR – Meetup.

IRC (Internet Relay Chat) is one of those tools that’s essential to many open-source (and other!) development communities, but sometimes intimidating and strange to new arrivals. This is a great guide to what it is, how to get there, and some basic commands.

Most large projects end up having a number of different channels for different subjects — for WordPress, the main #wordpress channel covers all kinds of support (from basic how-tos to site/theme/plugin development), and the others tend to stay very focused on specific areas (#wordpress-dev for core development, not site development; #wordpress-ui for UI team work; #wordpress-sfd for support & documentation team meetings). Other projects may break things up on social vs. work lines, skill levels, or work on particular sub-projects.

Work-oriented IRC channels are generally logged (social ones may or may not be). IRC Logs for the official WordPress channels are at irclogs.wordpress.org — look them up by date, time, and channel if you missed a meeting, or when you need to refer back to a discussion in a ticket.

My First Patch, chapters 1-3

Posted on by

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!