Re: volunteers needed for tasks

> Do you mean something like > http://php-gtk2.de/manual/coverage.htm > ? > I could do this. Some words about the php-gtk2 documentation: It consists of two parts: Tutorials and the reference. At the beginning of php-gtk2 development, we generated a reference doc skeleton from the C sources that should be filled with method descriptions, short method descriptions and examples. Now this coverage analysis script is just a simple XSLT script that counts the number of /empty/ description and short description tags in the documentation, and generates the coverage report HTML. This system is very easy to implement, but has a disadvantage: It knows only about the classes/methods that already have a skeleton in the documentation. We have had problems coping with newly added methods or whole classes, not to speak about extensions to php-gtk2 (e.g. GtkSourceView that brings 12 new classes and lots of methods). The classes and methods were there, but the documentation wasn't aware of them and couldn't count the missing ones. This week, we got a working update script which checks the reference documentation for missing methods, missing classes and wrong parameters and automatically adjusts the xml documentation to reflect reality. This way, we the doc coverage analysis shows the correct percentage when running the update script regularly. ----- What I wanted to say :-): We can't just take the php-gtk2 coverage script and do some 2 changes in the code and it works for PEAR. Reasons: - The PEAR documentation is only partly a reference. It has tutorials and method reference mixed. We would need to distinguish between them /automatically/ - There is no skeleton for PEAR methods and classes in peardoc, thus we can't count the empty places. - We need a solution to get a list with all classes and methods of a package which we can compare to the actually documented methods/classes in peardoc. - What about external documentation, such as for PHPUnit or some other packages that have their doc in some wiki? I guess we should count this as "no documentation", since it's not in peardoc. I would consider a multi-step-coverage: - Get a list with all packages in PEAR - Does the package have a entry in peardoc at all? If not, we have the worst case. If yes, look if there are some non-reference files: This is better than nothing - Compare the classes and methods found in the package with the classes and methods documented. While this is not a trivial task, the results once we have them give a nice percentage number. So the open tasks are: 1. Tool to get list of all packages - Get list of all classes in that package - Get list of all methods in that class - Store this list somewhere we can use it as reference count - I think a serialized array would be nice $ar[package][class][method] 2. Tool to find out if and where the section of a package in the PEAR manual is. - Find the number of "non-reference" (i.e. tutorial and general explanation) pages/sections for the package - Match the reference section of a package documentation with the previously list of package classes and methods. This is the hard task IMO. Daniel, could you do the first task? We should not count unit tests (files that are in tests/ directory), nor private methods. I don't know what would be best: Just include the files and reflect the class via PHP5's reflection mechanism or preg_match-parse the .php files? I would try to do task 2, at least the first bit until next week. -- Regards/MfG, Christian Weiske

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc