I guess I should say again that privileges don't have an inherent meaning. This is a good thing. For best practice, it depends entirely on the application. In general the best practice is to use privileges efficiently to achieve the desired level of security. Adding a create privilege is unnecessary, and doesn't even make sense in the context of the OpenACS permission system, since privileges apply to objects, and you cannot assign privileges until after an object is created. Efficiency means using one privilege as a proxy for multiple permission checks. For instance whenever you visit a package, the request processor already checks the user's ability to 'read' the package_id. Therefore adjusting the context_id of a package can allow easy control for an entire package UI. I think a best practices document should explore various use cases and demonstrate how to use privileges. When folks discover new uses for the permissions system, they can be added to the list.
Another underexploited idea is the use of roles. An explicit role system doesn't exist in OpenACS, this is analogous to the fact that the meaning of privileges is defined in the UI, not in the database. Using relational segments to serve as a container for members of a role is one way of modeling roles. The actual meaning of a role will still be defined in the UI, but instead of checking if a user has the 'admin' or 'create' privilege on an object, you could check if the user belongs to a relational segment, that is, the user has a certain relationship with a group. The advantage of using roles instead of additional privileges (like 'create' or 'forum_create'), is that in the case of using privileges you get weird artifacts such as having 'forum_create' on your photo album folder.
