While listening to Kenneth Reitz on this Talk Python to me episode and I realized that the most popular Python module, which is requests, could have failed due to a bad name choice! Instead of "Requests: HTTP for Humans" Kenneth Reitz almost named it "Requests: HTTP for python that doesn't suck"! See the difference?

That got me thinking about the "Right Way" to Open Source a project and how to build a community around it. There are several good posts and articles on the topic, like this (and many others on building communities).

Here I just want to add a few points that I think are important, not sure if they are the right way to do things:

• Variables names are meaningful*.
• Avoid committing to master. Fork it, branch it, and send the PR. It does not matter if you are the BDFL.
• Avoid, as much as you can, self-merging PRs. Ask another person look at your code. Or at least, if you can afford it, let the PRs sit for a day or two. (All the great coders do that!)
• Try to send "Hemingwaynian PRs". AKA bold and clear text code that is small and concise.
• Make an effort to send a test with every new feature or bug fix.
• Be nice to everyone that reaches out via issues, PRs, e-mails, etc. They might know nothing, like John Snow, but their help might be of the essence when winter comes.
• Give proper credit to those that reached out. Say thanks. I lost count of the PRs I merged and needed to be fixed right after merging, but I merged them anyways just so the original author got the credit for her/his contribution.
• Do not revert merged PRs and re-send them as yours :-<!
• The "entry level" to your code should always be low. If the code is complex, write better docs. Why not go the extra mile and write a developers guide documentation?
• Start any public development at early stages. Avoid code dumps!
• Do not be afraid of reaching out to others. Be the first (or the second ;-) guy on the hill **!

* https://www.youtube.com/watch?v=o5D8DwvkOc8

** https://www.youtube.com/watch?v=fW8amMCVAJQ

The video below, by Kenneth Reitz himself ;-), is a good place to start.

And if you are not feeling good about your code just sit down and watch this.