1. Develop small features locally
To really work on features I'd say you need a local copy of d.o. Only the relevant sections would be enough, but as they are hard to cut out we go with a complete copy.
To get a local copy of drupal.org:
Apply for bazaar pull access for the d.o. live repo. This way you can always pull the latest d.o. code from that repo.
The process is described in detail here: http://drupal.org/node/1018070
You can work on stuff in this local site.
The stuff we create will be mostly views, content types, maybe blocks and organic groups. So probably there won't be too many code changes on d.o. that affect
2. Upload your code to the sandbox project
Leisa has created a sandbox project: (URL will be inserted here)
Wen can use it for an issue tracker and to collaborate on the code.
Once you have a chunk finished, try to export content types, views, css files and post it up to .
If you are good with Features module, you can also pack it as a Feature, which should be easiest to extend on and continue work.
3. Our shared Dev Server
When something appears promising, we will upload it to our Development Server, so everyone can see it.
We have a dev environment at http://prairie-drupal.redesign.devdrupal.org
This does not keep in sync with the current d.o. code, it is a one-time checkout that has to be kept up to date manually.
This can be accessed by ssh. Also we can use drush on there. Apply here to get access.
This page explains the Dev Server in Detail: http://drupal.org/node/1018084
Basically we could work on there with several people. But as we have no version control on there, things might get shaky with overwriting each others changes.
Once you got ssh access to staging.drupal.org, got to /var/www/dev/prairie-drupal.redesign.devdrupal.org/htdocs.
This is the root of our dev website. In the root you find a file "comment". In here you find the password for user/1 to log into http://prairie-drupal.redesign.devdrupal.org
Fun fact: user name is Dries, since he was and is user/1 on d.o. So you log in with Dries/pw from comment file
Comments
I look forward to seeing code
I look forward to seeing code contributions, but am worried about this process. Along with a few others, I've been working to provide high-quality dev sites on our server, http://drupal.org/node/1018084. The whole section of the site is starting to get filled up with some excellent content, http://drupal.org/make-drupalorg-awesome, especially thanks to webchick. New documentation should be updated there, rather than duplicated here.
We used local development for the Drupal.org redesign project, and I was a big believer in it. However, it is just plain cumbersome. You have to be a sysadmin to get the basic services working; Linux does decently and other platforms do have some installers that help. And the data, even after reduced, takes a long time to move around.
Using the central server has worked well for a couple projects, http://drupal.org/node/648218 and http://drupal.org/node/1036132. The have taken awhile since there has been debate about what the functionality should be, and affect a few modules for deployment. They have been the exclusive way people have worked on http://london2011.drupal.org/. I now use the exclusively, my local dev environment just got too outdated and hard to update with new data. These projects have had multiple collaborators from the start. The sites being public has been a real asset.
As far as I know, we have not had any real issues with people stepping on each other's changes. If a site gets too noisy, we can provision a new one. It is always good to break up work into smaller, deployable chunks, and get them done. Architechting the Drupal.org redesign really taught me that monolithic projects are not fun.
The system does have some rough edges, but is always improving. I just added support for bakery last week so we can do some real testing when improving that. We are planning some larger moves as well.