Contrib Sprint - Newbies!

Here is a bunch of information to get started with if you are planning on attending the contrib sprint this weekend, and consider yourself a non-coder/beginner/newb. If you can get through prepping all of this before the sprint, you will have a head start once you get there, otherwise I will direct people to go through this info when they are getting started.

Etiquette

Take a deep breath - nobody is going to bite you... probably. ;-) That said, chx and the other developers that are attending are planning to really hit the ground running and get a ton of work done in a short amount of time. All attendees will be expected to be respectful of that, which in practical terms means not being too loud so they can focus, and not interrupting anyone who does not wish to be interrupted. Sounds like we may have a separate room to work in, and I will try and set up some sort of system to identify people who are going nose to grindstone and are best not to disturb.

What you can help with

The two main areas that you can help with are:

1. Testing (ie. end-user testing the modules that are being upgraded and reporting bugs)
2. Documentation (reviewing and writing documentation in/for the modules or D7 in general)

Before you get started with ANYTHING, if you don't have a lot of experience contributing to Drupal, I highly recommend watching this great video of David Strauss' (who is incidentally flying in for the sprint) session about contributing at DrupalCamp Dallas. It is an excellent crash course in how things work and how to get started, and covers most of the basics like IRC, issue queues, etc. If you don't watch it beforehand, I will probably just recommend you watch it when you get to the sprint!

There is also a ton of info you can dig through on the Contributors Guide

Tools

There are several tools that you will need to set up if you are planning on doing testing (you can work on documentation that is on drupal.org with only a site account).

IRC

IRC is the text based chat client that the Drupal community uses, and it will be quite handy during the sprint if you have an IRC client installed and working so you can communicate with the other people there, and anyone who is joining the sprint remotely. I would think it's a safe bet that the developers will be working in the main #drupal channel, so I would suggest that the newbs hang out in the #drupal-vancouver channel, or as always ask for support in #drupal-support.

There is a ton of info on how to set up IRC on d.o.

Your Drupal.org account

Be sure you have signed up for a user account on drupal.org and then go to your account (make sure you are on drupal.org, not groups.drupal.org), click on the edit tab, and then check all the boxes in the block configuration section. This will give you some new blocks in the sidebar with links that are handy for accessing the issue queues. (This is reviewed in David's video as well.)

Setting up your dev/testing environment

You will need to be able to install and run a fresh version of the D7 HEAD (ie. the most up to date development version of the codebase) to do testing. This can be on a server if you have command line access to one, but most developers will run Drupal locally for testing/development purposes - running locally = installing a server on your laptop.

There are instructions on how to set up a local server, so try your best to get through the set up before the sprint. If you are on a Mac, the most straightforward approach is to set up MAMP - these are great instructions to walk you through it.

If you are on Mac, you will also want to install Mac Developer Tools (Xcode) - this install is kind of large, so please do it before hand as it takes a while to download! (There are more detailed instructions here about installing and configuring Xcode, but depending on your level/fearlessness you may or may not want to delve in that intensely!)

Using command line

Scared of using command line? Well, no time better than the present to face your fears! Of course you can do testing by manually clicking and downloading, and moving files around, but that is going to be painfully slow. On Macs you will have an application called "Terminal" that will allow you to use command line to quickly update your code, make and change permissions on files, etc.

Here is a great how-to for command line but I think it is only for unix/linux.

A text/code editor

This is not necessary but it is a good idea to install some sort of text editor as well, so that you can open up the code and look at it, and maybe edit some documentation, read through a patch, etc. There are several listed on this page. I use TextMate, but it's not that great. I know a lot of people like Komodo and Emacs, but what I can say about TextMate is that it has few bells and whistles, so it's pretty straightforward to get started.

Testing patches

Once you get a basic feel for command line, testing patches becomes really quick and easy. There is a big write-up on how to test patches from a workshop we had at the office - check out the "Crash Course" section if you want to try and test out applying a patch on your own. Otherwise I can review this at the sprint.

Documentation

If you want to work on code documentation, you will need most of the same tools as for doing testing. But you can work on documentation that is on drupal.org just via the web interface. You will still need to be able to install D7 and any modules you are working with somewhere so you can be sure your documentation matches what is happening, but it's not as necessary to have it set up locally or to have command line access.

Aside from the Doc Team links that you will get in the sidebar on drupal.org, here are some of the most useful links to get started working on documentation:

• Drupal 7 priority Docs work
• Critical Docs Issues
• Getting started with Docs
• How to contribute to Docs
• Docs maintenance tasks
• Handbook Style Guide
• Pages with comments to roll
• Docs Issue Queue

Ok! I think that should do it for now! Try and work through as much of this as you can, and I will do my best to help out at the sprint - I am planning to be there off and on both days, and I'm sure there will be a couple other people around who can help out as well getting you on track. Hopefully we can get some people trained up enough Saturday to help test/document on Sunday, or at the very least you will be better equipped to keep contributing after the sprint!