11.2. A Project Web SiteThe 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:
11.2.1. Access ControlOne 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://. |