Project Flow & Tracker basic (non-UI) installation profile on GitHub – Status update for early-December 2010

Project Flow & Tracker installation profile is now ready in basic, non-UI form at on the 6.x-1.0-alpha1 branch. Be sure to change to that branch after cloning the project or else before downloading the tarball. Instructions are on the file for that branch.

The installation profile includes the following:

Project Flow & Tracker “Chicago” ready for basic use and download – Status update for mid-November 2010

Now close to “Chicago” release candidate and more usable than ever, the Project Flow & Tracker project has been made public and promoted to front page so you can browse the read-only functionality. I believe browsing from business model to roles to user stories to constituent tasks and back again is the best way (in theory and in practice) to understand what has been achieved at this point.

Much greater usability has been achieved, which is something that will be receiving a great deal of attention as a jQuery based UI layer is implemented in the next phase.

Features driven development — the nitty gritty and thoughts on the future of sustainable “in code” development

Features driven development in the Drupal sense involves placing code into versionable text files and packaging functionality into reusable components rather than relying on error prone user interface based configuration with scripting stored in the database along with the content rather than in code. It has been a great step forward for Drupal developers. It is simply a joy to once again be able to develop without infecting the code repository with database dump blobs. And to be able to install functionality in multiple servers running different applications irrespective of the content production workflow. But it is not without its contradictions and limitations, which I would like to mention in this article for the sake of discussion. However, while I will propose ideas for a better solution, I am mostly concerned with leveraging development in code right now by finding a comfortable process for using features driven development today, based on the promise of Adrian Rossouw‘s now classic “Database Is Silver, Code Is Gold” article The Development -> Staging -> Production Workflow Problem in Drupal.

Project Flow & Tracker Chicago – Roadmap and Status

Planning to be in Chicago to present new version of Project Flow & Tracker (“Chicago”).

It should be basically usable in a couple of weeks. It’s based on Panels Everywhere and OG, and a sub-theme of NodeOne’s Precision theme.

An exclusive theme, logo, icons and graphic design work is being done by Buenos Aires designer Juan Villegas.

Functionality basically the same as always, now a little more Scrum’d up I would think. Full details available soon.

Subscribe to commits:

From the Github README:

“The all new ProjectFlowAndTracker Chicago based on Panels Everywhere and OG

PFT is bootstrapping itself, being used for its own creation, and will be usable soon.

Panels Everywhere – taking the leap, getting it going

You’ve heard about the advantages of Panels Everywhere. Now its time to actually get it going. A drush makefile, a few configuration steps, and we should have a starter site up and going and never have to look back on ugly, deficient and crippled admin/build/block.

In a recent Buenos Aires Drupal Dojo online virtual lab, we did just that, so I shall lay out a series of simple steps here on the basis of what we learned together that night.

Let’s summarize the advantages of Panels Everywhere, take the steps to get it going, and think about next steps.

Project Flow & Tracker “Paris” – Part 3: Towards integration with Open Atrium via our very own branded Feature Server!

So today finally Project Flow & Tracker meets Open Atrium, and does so in style. My friends at Development Seed just told me about the new availability of the feature server code (w00t! out just a couple of days right here:, not to mention a spanking new theme, singular,

“a minimal theme that can be rebranded quickly and simply using background images a la Twitter. The theme comes with several prepackaged backgrounds and site administrators are encouraged to upload their own.”

also out just a couple of days, and which can be found at . Singular and depends on the base theme Tao: (also fresh meat!).

So we will be diving right in. Here are the steps we will be taking, so hang on to your mice, it’s going to be a fun ride:

Project Flow & Tracker “Paris” bursts into life as a feature – Part 2

Dedicated to the compadres at #drupalcampla

Today we witness the birth of PFT “Paris” as a feature, that is, based on the Open Atrium compatible features family of modules which promise plug and play feature components for Drupal. It should also serve as a useful tutorial on how to get started with features (and a smidgeon of drush and bzr too!). And you can download the whole shebang and enjoy Project Flow & Tracker lite. What we’ll do:

In depth: Project Flow & Tracker to be rebuilt on Open Atrium – Part 1

Based on the principles of ideas and architecture over coding, community based collaboration over individual and isolated effort, I have decided to redo my Project Flow & Tracker agile based project management tool based on the new Open Atrium “do-it-yourself project” kit. Not only do I get a huge kick in the butt for starters, but I can give back all the new functionality I develop as shareable features. Talk about win-win!

Lot’s happening over at Project Flow & Tracker

Just so’s you know, things are jumping at Project Flow & Tracker:

  • Even though we are still in pre-Alpha, over 50 people have signed up to work on their projects, with the aim of benefitting from an agile, test-driven approach tailored  to website applications (see Roadmap below).
  • There’s a “stop the music”* podcast on how to set up your project so as to take advantage of the PFT “forest and the trees” content navigation model.
  • I just sent out a Roadmap for April, 2009 to all those who have signed up as product owners to work on their projects online. Reproduced below.

So there you have it folks, short and sweet. Remember: for every 1000 hours you and your client (their work counts too) spend working on a project, 400 at least should be spent on writing and running functional acceptance tests.  Sound like too much? You need… Project Flow & Tracker.