I have just sent myself and one poor maintainer on a wild goose chase for a number of hours, and unnecessarily into the depths and bowels of typical drupal code (which I feel is like convoluted spaghetti code, except the sauce on it is so thick and dark I need a pitchfork and a screaming bright searchlight sometimes to trawl through it and investigate anything), because for some reason a setting (a boolean switch) in a view of mine was wrong. (And I had read the instructions, and that is how I found that I had cause the problem somehow.)
I have a proposal to help prevent this sort of thing, and can save a lot of module developers a lot (and I mean thousands) of hours.
I would like to every single module (as part of the module management system on Drupal.org) complemented by a very rigorous, database served, set of requirements and pre-conditions for correct operation of that module, and that set might be slightly different for (i.e. parametrised by) different circumstances.
I am NOT talking about just listing such as sentences within a page of HTML-authored documentation (and I would suggest that such should no longer appear that way, because otherwise if the conditions are changed in the database, they will not propagate to the help pages, and facts get out of sync).
You might already have such an effective database driven checklist in the wonderful SEO Checklist module.
However I am talking about it being served directly onto Drupal.org somewhere on the module's project page or documentation pages, and generating part of the distributed module with it automatically (for every single module, as a new documentation policy), and for every single module integrating it with a state checking system that can be accessed by admin.
Users would be able to select from a range of requirements and cases (example: "display multiple referenced nodes as structured formatted views") and the system would provide both a static checklist of generated documentation, and in some cases it would pump the system for enough information to check the entire matching state, as SEO Checklist already does for a wide range of values (but can't for all).
For example, in the case I just had with a setting in Node Reference Views, the system would have to be able to check against the following value of (whatever is behind) Allow multiple terms per argument within a view, just as SEO Checklist accesses some state values for its checklist.
I mean introducing this approach as a form of new preventative development and support policy, one that can help drive the entire Drupal module and documentation development process, with requirements, pre-conditions, and states being gradually yet systematically migrated out of paragraphs of text documentation (and I mean out, completely) and into a database, so that it can be exploited actively in many ways, and served back into the online help pages and into the module admin pages on a live drupal instance.
Dr Darren Kelly (Webel IT Australia)
Comments
_
I can't think of a more sure fire way to completely decimate drupal's contrib participation. This is not a corporate effort with people earning 6 figure salaries writing the code. Drupal's contributed modules are created by volunteers-- no volunteer in their right mind would waste their valuable free time on such a painful process.
Expanding the core testing infrastructure to contrib, which is already underway, will greatly enhance bug detection and problem solving. Aside from that, I don't believe there's any substitute for knowing what a module is supposed to do and learning how to use it. Some things just can't be automated.
Concerning hook requirements
I have read the remarks by WordFallz, however this is not a direct reply to them. I do understand the benefits of the quite pragmatic contributor culture of Drupal.
User joachim has drawn my attention to the capabilities and usage of:
http://api.drupal.org/api/function/hook_requirements
It is said that "prevention is better than cure", and this can help (if developers choose to embrace it), although there is much more that could be done with strongly requirements driven development, right through to every artifact of the
Drupal contributed modules.
I have an ongoing interest in strongly requirements+feature driven engineering, with complete traceability from specification documents (and even freestyle technical documents), sentence by sentence, through graphical UML "parsing analysis" to generated or manually-implemented software, with complete digital linking between every medium, in both directions. I understand that is not everybody's cup of tea.
I would bet that barely any contributed module developers work with a digitally controlled set of requirements after that fashion, and it is not my intention here to argue about whether or not that is good for the Drupal.org community (although my preference/bias is clear).
BTW The Drupal API and hook system (with people building hooks with string concatentation, not even through a dedicated, universal, architectural method) makes it particularly hard to integrate Drupal with modern graphical software engineering tools and requirements driven engineering.
My current client Project Performance International (PPI) offers requirements engineering courses for systems engineering and software engineering, and we together have a strong interest in introducing requirements-driven technologies for Drupal, as they have made a strong commitment to Drupal technology, and I would like to also use it for combined workshop and teaching examples, with Drupal as case study.
Webel IT Australia, "Elements of the Web", Scientific IT Consultancy,
For PHP-driven Drupal CMS web sites, Enterprise Java, graphical UML, UML Parsing Analysis, SysML, XML.