By aquila on

We are going to start an internal project which will require quite a lot of integration of CCK, views and custom code. The project will be started by an internship.
Drupal will work very well, but we want to make sure that we know very well how the project is integrated so we can track possible problems very easily afterwards.

What do you think would be the best way to document such a project? How do you document these things?

⋅ Categories: Drupal 6.x

Comments

peterx’s picture

peterx commented

Start by explaining the site to people who will create content, upload images, and all that stuff. They are the people paying for the site. If you cannot explain something to them, rethink the design.

The documentation for them can be the basis for the final user test, signoff, and creation of the production site. The Drupal book approach is fine. Use the http://drupal.org/project/print module to publish documentation as a giant checklist for testing.

Any other documentation is for the benefit of coders, not the customer. Usually the person creating the code presents something to other coders. The other coders ask questions. All the questions and answers go into the documentation.

In the reality of big Web site development projects, you vote on who presents the best documented code and send one coder home each week until there is just one coder left. :-)

petermoulding.com/web_architect

stevecowie’s picture

stevecowie commented

Have a look at casetracker module. It uses a similar model to projects/issues in adapting comments so that a case is a node, and follow-ups such as module installations, configurations, bugs can be added as comments. The other good thing about this approach is that you can produce relevant taxonomies for cases so that it's easy to find stuff when you come back to this in two years' time.