Getting Started with eLanman

About

Place holder for Getting Started section This document provides a set of best practices for open source contributions - bug reports, code submissions / pull requests, etc.

For the most part, these guidelines apply equally to any project regardless of programming language or topic. Where applicable, we outline where individual projects/languages may have additional requirements.

Naturally, this document is itself open source, and we encourage feedback & suggestions for improvement.

Sources

Currently this document draws from the contribution documentation for a handful of related Python open source projects: Fabric, Invoke, Paramiko, etc.

It’s expected that over time we will incorporate additional material from related attempts at consolidating this type of info. We’ll update with a list here when that happens.

Submitting bugs

Due diligence

Before submitting a bug, please do the following:

  • Perform basic troubleshooting steps:

    • Make sure you’re on the latest version. If you’re not on the most recent version, your problem may have been solved already! Upgrading is always the best first step.
    • Try older versions. If you’re already on the latest release, try rolling back a few minor versions (e.g. if on 1.7, try 1.5 or 1.6) and see if the problem goes away. This will help the devs narrow down when the problem first arose in the commit log.
    • Try switching up dependency versions. If the software in question has dependencies (other libraries, etc) try upgrading/downgrading those as well.
  • Search the project’s bug/issue tracker to make sure it’s not a known issue.

  • If you don’t find a pre-existing issue, consider checking with the mailing list and/or IRC channel in case the problem is non-bug-related.

What to put in your bug report

Make sure your report gets the attention it deserves: bug reports with missing information may be ignored or punted back to you, delaying a fix. The below constitutes a bare minimum; more info is almost always better:

  • What version of the core programming language interpreter/compiler are you using? For example, if it’s a Python project, are you using Python 2.7.3? Python 3.3.1? PyPy 2.0?

  • What operating system are you on? Windows? (Vista? 7? 32-bit? 64-bit?) Mac OS X? (10.7.4? 10.9.0?) Linux? (Which distro? Which version of that distro? 32 or 64 bits?) Again, more detail is better.

  • Which version or versions of the software are you using? Ideally, you followed the advice above and have ruled out (or verified that the problem exists in) a few different versions.

  • How can the developers recreate the bug on their end? If possible, include a copy of your code, the command you used to invoke it, and the full output of your run (if applicable.)

    • A common tactic is to pare down your code until a simple (but still bug-causing) “base case” remains. Not only can this help you identify problems which aren’t real bugs, but it means the developer can get to fixing the bug faster.