General considerations
Thu, 01/24/2008 - 11:55 — admin
- All Drupal coding standards (http://drupal.org/coding-standards) need to be followed. All functions, classes, methods, and constants must have properly formed, complete Doxygen code comments (http://drupal.org/node/1354).
- The module should use the APIs of the subscription module and the organic groups module wherever possible and do as little direct database access as possible.
- All API functions that are used and that are not already fully documented need to be fully documented. This will provide a useful start for the API documentation for the subscriptions module that is currently still lacking, see http://drupal.org/node/194570. A good place to put this API documentation is as a child page of http://drupal.org/node/50377. This will be a very useful resource for other developers and will be crucial for the maintainability of the compatibility between the modules in the future.
- User and administrator documentation for the module should be written and published on drupal.org at http://drupal.org/node/206728.
- There is a close similarity between subscribing to taxonomy terms and subscribing to groups. The analogy is 'vocabulary' <-> 'group type' and 'term' <-> 'group'. This means that the subscriptions_og module should start out with the subscriptions_taxonomy module code and then extend that. Keeping the code that does similar things similar between the modules will help maintainability.
- When the subscriptions_og module is installed it must check whether there are already any notification subscriptions held by the og module and automatically convert these to subscriptions module subscriptions. Notifications must then all be switched off in the og module. This functionality depends on a hook in Organic Groups module http://drupal.org/node/211031#comment-6957939.
- It is crucial that the notification emails respect the node access restrictions and do not reveal any nodes that should be kept secret from a user. This should be tested extensively.
- The following rules will ensure that the project will proceed in a timely manner: Development will take place in the drupal CVS repository, as specified on the project's home page (http://drupal.org/project/subscriptions_og). Code will be committed frequently rather than in big batches so that progress can be monitored. The developer will stay in frequent contact with the drupal community via the issue queue at drupal.org and will work on the project for not less than two hours per day on average. The developer will not be out of contact for more than four days.
- All functionality implied by the specification of the user interface will have to be implemented, all documentation written and all bugs fixed before version 1.0 can be considered complete. The developer will receive payment immediately upon successful completion of version 1.0.