How to

It's too simple for us old-school developers. (It took three of us a half hour to figure out at DrupalCampNYC.)

After creating both groups and some regular fields, you – get ready – drag and drop the regular field inside the group (or fieldset).

Resolution

There's a module for that

This looks like our best bet:
http://drupal.org/project/comment_modr8

Eric:
all these people focusing on fixing a bug

this is my heretic speech.

Project module doesn't support threaded discussions.

Nat: Fairly common that issue trackers are flat.

What are people using?
Unfuddle.
Interpulse - time tracking, create issues and assign them.

Eric: I won't use something I don't control. Can't even put HIPAA stuff on a server, it has to be my own server.

Long-term dedication

Installing and configuring Nice Menus: http://drupal.org/project/nice_menus

Download or drush or otherwise acquire and get it into sites/all/modules. Enable at http://example.com/admin/build/modules and no configuration is even necessary.

Hi Ben,

I added admin_menu to the Radical Reference site, but I couldn't find
where/how to configure it. I did manage to give full_administrators and
technicalsupport roles access to it. Can you advise? Or are you going to
make me rtfm?

Thanks, Jenna

The user login block is ugly in Drupal by default, and we thought we'd posted about theming it to make it look different but apparetntly not yet (hint: you can do a whole lot with CSS, it is id block-user-0), but for lots of sites you may not want it to display at all. (LoginToboggan module can replace the login block it with a login/register link.)

For instance, your site may not have any reason for anyone log in except administrators.

webchick talking to Michelle in IRC #drupal:

I name all my patches as {module_name}-{description-of-changes}-{issue_node_id}-{issue_comment_id}.patch

Personally, I think issue_comment_id might be hard to do (even interpreted as the big #5 etc project module places in the comment title, rather than the internal Drupal ID!) since people can add comments while you are making the patch, but I'm on board with the ideal.

Getting into that habit also really forces you to keep to a one-issue-one-change thing.

Testing a patch and adding a simpletest with Catch as my guide.

Steps taken, starting with checking out Drupal 7 dev (or head, until the code freeze).

(I got the link to the patch for the wget below from the issue, in this case http://drupal.org/node/305740 )

cd /sites/PROJECTNAME/www/sites/all/modules/
sudo /srv/scripts/agaric-updatemodule.sh MODULENAME

Drush can update everything at once without listing a module name but I'm not sure my script (attached) will add them to SVN right if it does (if my script even adds it to SVN right). You can and probably should do this on the test site first, note that everything's working (and hit update.php and make sure that doesn't break anything) and then SVN update live to get the changes over there (and hit update.php again on the live instance of the site, too).

sudo svn commit -m "uploading images will work so much better with the enctype set"

The important part, the lack of which is what was making image uploads simply not work for what were at the time unknown reasons, is the last line: $form['#attributes']['enctype'] = 'multipart/form-data';. For the file form element to work, for the file to be able to upload, the entire form's encoding type has to be set to multipart.