Section 11.2. A Project Web Site

11.2. A Project Web Site

The best idea that I know of for helping a group to communicate clearly is a good set of web pages. Even the best web page won't replace other forms of communication, but it can be a central place to store many of the results of using the other tools to communicate. A web site can be useful both for relatively static information (such as how to build the product) and also for more dynamic information (such as the latest commits to the project or the current state of the automated builds).

Some general suggestions for a project's web pages include:

• Host the web site on a server with enough resources to run other jobs, as well as serving up web pages. There are always periodic jobs that are more convenient to run on the same machine as the active collection of web pages. Larger jobs can always be run elsewhere and their results can be copied over to the web server.

• Create an email alias for each area of the web site and make this address prominent on each area's web page. Example addresses are scm-admin for SCM-related questions, build-admin for build-related questions, and bug-admin for questions about bug tracking in the development environment.

• When someone leaves the project, wait a month and then scan the web pages for references to him, then update the pages with the relevant contacts or remove the references. The information is still there in the SCM tool. Updating the web pages doesn't mean erasing his name as though he never existed; you're just removing him from the current contacts.

11.2.1. Access Control

One issue that is part of making the project's information available on a web site is how to restrict access to it. In an open source project, this is usually a question of who is allowed to change the information, which then comes down to commit rights (see Section 12.5). Still, in some open source projects, some bugs are marked as private if they are related to security risks.

In a closed source development environment, the web site should be accessible only from within the private network. In some companies, the engineering group doesn't want salespeople selling features they may have seen being added to the source code, since the features may never be released. Many companies consider the list of bugs in a product to be sensitive information.

The simplest way to restrict access to sensitive areas of the web site is to configure your web server to request a username and password for certain locations. There is a good tutorial about authentication, authorization, and access control for Apache at http://httpd.apache.org/docs/howto/auth.html. You can also use .htaccess files on a per-directory basis, but this is less efficient. If the information on sensitive web pages is going to go over a public network, or any part of the network contains a wireless link, or the physical security of the network is in doubt, then make sure that URLs use https:// rather than http://.