No one is entitled to freebies. But let's talk about why we're fond of giving free shirts to (presumably) well-paid people anyway.
I'm a community manager & community builder. When it comes to software, "community" can feel like an abstraction. What does "community" even mean, right?
A community is comprised of people who share an attribute that's important to them, that feels distinct from those who don't have it in common, and which is tied to a sense of personal identity.
"I live in San Francisco" is a statement of geographical fact; whereas "I am a San Franciscan" reflects an aspect of my identity. My sense of belonging to something that will outlast me. My passion & loyalties. San Francisco is my community. I feel this way about other things, too. Ruby community has its flaws, but it's a community I am invested in long-term regardless of what else I'm doing.
"What does this have to do with t-shirts?" you might be wondering.
Let's circle back to the question of why the heck we give away swag shirts. Some reasons:
We need people's passive help in getting the project or brand known better.
We want people to associate the project or brand with being cool, whether anyone knows anything else about it whatsoever.
We want people to feel appreciated, and feel that others are being treated well too.
We hope people feel proud to wear our logo; proud to be associated with it.
We intend that when someone sees a crowd full of people wearing the shirt, that they'll feel they're missing out and be excited to go do something about it.
We intend that it'll ultimately lead to questions, usage, contributions, and personal identification.
Every time someone walks away with a shirt that doesn't fit them right, or there's no shirt to fit them at all, that's a lose-lose situation for us all.
A failure to elicit help bolstering the image of the project or brand.
A thoughtless decision that looks decidedly uncool.
Showing due appreciation to some, while disregarding others who equally deserve appreciation.
Implicitly communicating that some people needn't take interest in what we're building.
Making people feel they're missing out, then reinforcing the accuracy of that conclusion.
It is possible to build software community without caring about swag shirt inclusivity; but it makes that mission unnecessarily harder.
UPDATE: In the next post I'll be going into details of what swag shirt inclusivity entails. For now, here's a nice writeup about gender-inclusive shirts. Swag shirt inclusivity goes beyond gender considerations, but it's a solid start.
Yep, this stuff takes effort to do well. But it serves a community-builder's mission.
If we're trying to bring more women and men into coding, start by listening to young learners in their own words. These have shared useful insights, for instance. Understanding what drives their interest is critical, not just as future coders themselves (we hope!) but also as reps for a future cohort of consumers for tech products that speak to their interests/needs.
Good news for me: co-organizing Railsbridge Outreach Workshop for Women #34 is going swimmingly thanks to +Amy L. & +Tina Lee. We rock as a team. Tina and I are discovering that the Railsbridge community has done a bang-up job of documenting what we need.
Sign up ASAP. Don't be intimidated by the wait list. A lot of people get moved up before the big day.
Meta-meetup! CodeChix, Black Girls Code, Confident Coding, Girl Geek Dinners, among other tech women's projects/meetups. I've put out the word to the Railsbridge, Women Who Code, and PyLadies organizers in hopes that they'll also get on that evening's roster.
Although the meetup is a tie-in to the Fluent conference, it's open RSVP.
(If you're one of the Saturday frontend Railsbridge students in search of followup education, take note of the workshops calendar for Fluent. 20% off with coupon code, ahem.)
If you're a woman looking for like-minded communities to join, c'mon down to our meetup on Wednesday evening. In addition to great networking, you'll hear lightning pitches from groups, companies, and...
If you still want to take a shot at evaluate the correctness of an email address string, at least do it with library that uses a parser and has attempted (nevertheless imperfectly) the difficult task of complying with all the relevant RFCs. For example:
Patting myself on the back for having spotted the error. It was over 2 months old — surprising for a standard library like URI::HTTP. So I second-guessed myself initially.
Surely that doc gets scrutinized by hundreds of people daily. Surely someone else would have spotted it ages ago, if it were done incorrectly. Surely I just haven't heard about some fancy new syntactical construct. Surely the fact that the example doesn't work for me is because I must've done something incorrectly. Surely.
Trust your instinct. Verify. Make better things happen. Commit.
Last month I also made a first commit for the official Rails documentation, and — hooray! — it was accepted. Though not without a brief facepalm moment when I accidentally submitted a big bunch of other people's commits with it. Luckily, the railsdocs repository is maintained separately from the Rails codebase. So it was a quick fix by doing git reset --HARD on master branch then the documentation maintainers and I each did a git push -f on our respective repos, and rebased my branch's commit back in. Voila, solved.
It's a good example of where Git is a big win for contributor, maintainers, and collaborators. It is also a good example of how wins like these are made easiest when developers are required to submit to an upstream via a branch rather than on top of master.
So, summary: I can now put "Rails documentation contributor" on the résumé, and hopefully soon will be able to put "Ruby documentation contributor" on it too. Don't worry; even though I'm a cool kid now, I still want to hang out with you.
I'm speaking October 21st at Confident Coding III ("Everything Else You Need to Know"), an all-day web technology education conference for women and friends. We'll be at Microsoft's San Francisco offices at Market & Powell. Join us for a fun day of learning about developer tools, automation, HTTP, the commandline, and more. Really useful stuff. Come!
(Pssst. Women still earn 77% of what men do. Use discount code EQUALITY to register at 77% price.)
In an ideal world, you could check out any arbitrary commit and it's pass all tests, and have no bits of code trailing along that belong to another feature/issue. Line-by-line staging is how I first got religion where Git was concerned. Judicious use of it truly makes ideal commits feasible. Ahhh. Truly a Cool Git Trick.
But there's a bug. Maybe you've seen it. Periodically, seemingly at random, attempting to stage or unstage a line results in an patch error such as "Applying patch failed with return value 128. Error: fatal: corrupt patch at line 12". Don't believe it.
P.S. Want to learn about staging lines with Git? Check out "Splitting up commits the easy way" by Peter Savage. GitX(L) and SourceTree both support this workflow really well, and (ironically) are much nicer GUIs overall. SourceTree, by the way, doesn't show this bug. GitX(L) does. Bah humbug.
Being able to edit PS1 (the shell prompt) was an eye-opener and productivity transform. My prompt has, among much fancier things, two newlines prefixed on to it, plus colorization to make the prompt stand out from the command it's receiving. I cannot emphasize enough how much this changed my ability to catch errors and reliably connect them to the command that generated 'em. I'm a better programmer for having discovered that one small detail that PS1 is customizable.