I don\'t want to anger the woods gods by posting this, but I\'ll risk it.  So far, this is shaping up to be the first summer in 5ish years (or more, I\'ve lost count) where I haven\'t been exposed to poison ivy.  And that is despite finding some very poision ivy looking plant in one of our plan beds out back.  According to Jim Fallows, Tecnu is a bonafide wash that can remove the oil once you\'ve been in contact.

Now it\'s mainly available through forestry-supply outlets or direct from the manufacturer. If you use it to wash your skin as soon as possible after you\'re near poison ivy, it really does the job.

While I\'m Still in the Churl-Free Mood: #5, Tecnu! - James Fallows - The Atlantic

I can\'t seem to remember the specicfic magic git switches when pushing and pulling branches between different git repositories, so I am writing it down here.

1. Create your local branch for development

git checkout -b my-branch

2. Push local branch to remote server & track it.

git push -u origin my-branch

3. Checkout and track a remote branch

git fetch
git checkout -b my-branch origin/my-branch

Alternatively:

git pull
git checkout -b my-branch origin/my-branch

Matthew at DogStar describes his PM toolbox today, The Project Management Tool Box | Opensource, Nonprofits, and Web 2.0.  It\'s a detailed and well organized list, and I think reflects a very practical approach. The first thing that strikes me, is the overwhelming amount of tools available to the would-be PM.  Certainly, there is no lack of tools out there.

You see, the general feeling is, there is no silver bullet. There is no grail of a tool that does everything a single Web Producer, Project Manager, Product Manager, or Content Manager might need or want. There is clearly a gap that is filled with a series of different products. This walked hand in hand with a desire to review processes at work and engage in course corrections. It is an excellent habit to follow - look what you are doing with a critical eye, analyse why you are doing it, and make changes as needed. I have worked across four different shops with a wide variety of different ways of practicing project management. I have used these methodologies and tools across \~ 50 different Drupal projects and another 25 or so custom PHP MySQL projects.

I could not agree more that its important to not be seduced into picking the one right tool for every situation.  It is a difficult tempation to resists, especially when you have tool makers pushing to sell you a solution. The best tool for the job isn\'t the one that has the most features, its the one that you, and your team, end up using the most.

As I read the article, a thought that struck me is that sometimes, you don\'t need ONE tool, you just need to make sure everyone has the right tools (and skills) to be productive and responsible. At work, we\'re a tiny team of 3 who deal with day to day management of our Drupal site, unexpected requests on tight deadlines, and long term projects to build new features. Here\'s a secret - we don\'t have a central bug/ticket tracking tool. We can be productive simply with email, IM, code bearing, and face to face conversations. For big projects we use a whiteboard to wireframe, capture tasks, and track progress.  This works better than a more sophisticated technical solution that would impose a greater burder on our time.

What\'s your experience with tools and grappling with finding the perfect tool?