Differences between revisions 2 and 3
Revision 2 as of 2010-11-17 03:11:17
Size: 3801
Editor: FredDrake
Comment: add link to project planning page
Revision 3 as of 2010-11-17 03:19:10
Size: 4126
Editor: FredDrake
Comment:
Deletions are marked like this. Additions are marked like this.
Line 53: Line 53:
   D. Python. Possibly several versions. If C code is involved, it's a    D. Mailing list subscriptions, wiki logins/update permissions, issue tracker
      accounts.

      These are important to receive feedback on your contributions and to
      share with the community. Issue tracker accounts are especially
      important if you don't yet have commit privileges for your project.

   E. Python. Possibly several versions. If C code is involved, it's a
Line 56: Line 63:
   E. Bring paper and something to write with. Just in case.    F. Bring paper and something to write with. Just in case.

Sprinting with the DCPython Meetup Group

With the first DCPython Meetup "Beginners" sprint coming up, there are a lot of people interested in joining in and sprinting for the first time. Some folks are new to sprinting, some are new to open development practices, and some are new to Python.

There are a few things that are worth doing ahead of time:

  1. Decide what projects you want to work on.

    Work is always needed on the Python language core and standard library, but you're not restricted to that. Many people are interested in the libraries they use on a daily basis, with perhaps the most common ground to be found in the web frameworks.

    Tell your fellow sprinters what you want to work on using the planning page for the sprint you'll be attending.

  2. Know what tools you need.

    1. You need a laptop. Or something you can bring with you to work on. Expect to need networking support; wireless is best, but it's always a good idea to bring an ethernet cable as well.

      If you don't have or can't bring a laptop, that's not a deal-killer, but you'll probably be watching over someone else's shoulder. That won't stop you from learning and contributing, though.

      Reportedly, independent wireless access may help in our venue (MyFi or similar). Be aware of what you're spending on data access if you use 3G/4G access (directly or indirectly).

    2. Revision control tools. Know what the project you're working on is using, and have some idea how to use it yourself.

      Chances are someone will be able to help you get set up, but doing it ahead of time is best. Packages are readily available for the most widely used tools for most platforms.

    3. Email and IRC clients and accounts. Know what IRC channels you should be paying attention to. Even developers in the same room use IRC heavily if they're used to communicating with team members using IRC, so be prepared.

      If you haven't registered a nick on irc.freenode.net, go ahead and do that ahead of time.

    4. Mailing list subscriptions, wiki logins/update permissions, issue tracker accounts.

      These are important to receive feedback on your contributions and to share with the community. Issue tracker accounts are especially important if you don't yet have commit privileges for your project.

    5. Python. Possibly several versions. If C code is involved, it's a good idea to have at least one debug build available.
    6. Bring paper and something to write with. Just in case.
  3. Build a development copy of your project ahead of time.

    If you're new to developing a project rather than just using it as an application or an API, this is a good test to see how much you'll need to learn to get bootstrapped.

    You should be able to check out your project from a revision control repository, build the software (even if it's just "python setup.py build"), and run the tests.

    If things fall apart at this stage, that's ok! Come sprint anyway, but make sure you ask for help setting up right away. That way you get the help you need to start contributing, and someone who knows more about the project can learn how the project can be improved based on your experience.

  4. Keep in mind that not all contributions are code. Many contributions take the form of issue triage, patch review, proofreading documentation, or just helping someone else understand the problem they're working on.
  5. Take note of what you accomplish at the sprint, or indirectly because of what you learn at the sprint. Someone will pull together an re-cap to post online. (Pictures are good too!)

See also:

SprintingWithDCPython (last edited 2010-11-17 11:06:17 by FredDrake)

Unable to edit the page? See the FrontPage for instructions.