GitHub's new Atom editor is out in limited beta.
I've been blessed with a finite number of invites to share with you, my Internet friends. One can be yours for opening a pull request on someone else's public GitHub project that makes a meaningful contribution. Here are some ideas:
Just mention me on the pull request to claim your invite.
One of my favorite parts of working at GitHub is helping our Supportocats answer support requests. Since I focus mainly on the GitHub API, I get to work with our more technical users. I've shopped at BestBuy enough to know what it's like when you think you know more than the staff.
Nearly nine months of helping technoweenie pursue Inbox 0 at the API Help Desk has changed the way I ask for tech support for other products and services.
In the software industry, many of us have friends who have founded or work on some of our favorite services and tools. With those personal relationships, it seems easier to shoot an @reply or DM on Twitter. For site down questions, that's often good enough, but 140 chars just isn't conducive to describing (much less troubleshooting) most issues.
For GitHub, our support form makes it simple to reach out and say Halp! Sending an email to support@github.com works, too. Including "API" in the subject line routes you straight to the API team.
Many open source projects have mailing lists, issue trackers, and IRC rooms to talk about issues. Find the right channel before you send a flurry of questions to a project maintainer.
Once your request makes it to the top of the support queue, it has to be grok'd by a human. Verbosity is your foe here. The more you write, the longer it takes to distill your words into your actual issue. Not just once, but each time your ticket is passed to someone else on the team, it has to be reinterpreted.
Your chances of getting speedy help go up substantially if you can avoid that
dreaded "more info please" follow up. Photos, screenshots, URLs, stack traces,
and other facts help speed up the six stages of debugging. If you're
calling a HTTP API, the developer has a hard time refuting curl output.
`curl -v` or it didn’t happen.
— Wynn Netherland(@pengwynn) December 18, 2012
Many request tools thread messages by subject or ticket number. You might be tempted to reply to that six month old email because the person who helped you last time seemed to know what they were talking about. Unless the issue is directly related, chances are you're delaying your new ticket because there's more previous conversation to wade through on the other end.
Most support queues use plain old unencrypted email. Please, please, please never send passwords, API tokens, credit cards, or other sensitive information in email. Always mask or omit sensitive info in email. Be sure to scrub that stack trace or log snippet you're including, too.
You might have justified rage because a certain feature has been long broken and no one seems to care. Just don't let frustration undermine your own cause. Name calling and insults might make you feel better in the moment but it won't bring you any relief. Most support folks are extremely professional. They like to help or they wouldn't do what they do.
That said, humans are more inclined to help when they're treated like, well, humans.
Oh yeah, we're hiring Supportocats.
Erik and Mislav have an interesting discussion going on a Faraday commit on the merits of those badges in GitHub repository READMEs.
I use them in a few of my projects, but lack of consistent size and Retina support have me leaning towards removing them.
What's your take? Ease or sleaze?
In case you missed it, technoweenie set up a new GitHub organization and moved Faraday and Sawyer over. Mislav and I have also moved our middleware project over and I'm maintaining a legacy fork at the old spot as a redirect.
It's a big island. If you've spotted any others or have your own Faraday-related initiatives, come join on us on LOST Island.
As I've written previously, I've learned a lot just by digging through dotfiles on GitHub. Adam Jahnke and I set up a guide to help others looking to fork, share, and mine them for tips and tricks.
We're starting small, but we aim to be a curated list of the best dotfile projects, files, and one liners, which we'll dispense at the @octodots Twitter handle.
When you create a public repository on GitHub, the whole world can watch you work. As developers, we feel the need to say "But wait, it's not done yet!"
@pengwynn ah not worth advertising yet, lol.just hacked that up last night.
— risk _danger_ olson (@technoweenie) December 31, 2011
@pengwynn thanks for the mention, positive response so, far…I was planning do an announcement once it gets a little polish
— Richard Schneeman (@Schneems) December 28, 2011
But that's the whole point of social coding isn't it? In addition to just sharing code, aren't we supposed seek out those developers more skilled than we are and learn a thing or two? After all, if we were only interested in deconstructing finished products, there would be no Food Network. The same goes with software. Watching a project come together is a chance to peek into how software is built.
I started watching Rick's Faraday project when it only was a few commits old (before it was even called Faraday if I recall correctly). Rick's approach to REST wrappers seemed intriguing and he graciously fielded my questions as I started using it in a few pet projects. I liked it so much I began spreading the word at conferences and meetups, and out of that came Faraday Middleware.
Faraday is now appearing in all sorts of Ruby projects and enjoys a growing network. Mislav is doing a great job moving the project forward. Speaking for myself, it's doubtful if I would have been involved at all had I not caught Rick working one weekend in the fish bowl.