Re: WG: [PEAR-DEV] [Call for Votes] XML_Statistics

Alexey, How much time does it take to figure out the code first before I can write a tutorial? By the way, in ref. to HTML_BBCodeParser I spoke with the maintainer and posted it here, both have left me with no response as far as a maintainer role or applying the patches. As far as the inline doc's at this point being sufficient. They may be for you... but now let's take little Johnny who is just starting off in PHP and was looking into parsing an XML file he uses for his resume. Johnny finds out PEAR has several XML libraries which may be of use to him. Now Johnny needs to find out the stats of his xml file, specifically number of tags, white spaces, etc. So he decides to use XML_Statistics. Problem is, Johnny is new to PHP and can't assume as much as Mr. Borzov can, and thus XML_Statistics is complicated to him. Stop thinking of developers like yourself, and instead think of those newbies out there. There's two side to what PEAR does, helps the current sophisticated developers deploy code quickly, but also helps know-nothings like Johnny. - Stan Alexey Borzov wrote:

Hi! Stan Lemon wrote:

Exscuse my bitching and let me intervene for a second... The point I'm trying to make is that contributing a package should require sufficient documentation, it should not be a step which is taken later, regardless of the developers reputation.

Inline documentation for the package in question is IMO sufficient.

As for those of us who are bitching about PEAR's pathetic exscuse for documentation, we would contribute if we could count on it being included. Remember, PEAR's other fault is that it doesn't pay attention to use submitted patches and so forth, thus there is a pluthra of patching which has never been done, some of which includes doc add-ons. I wanted access to get to HTML_BBCodeParser to patch some items and improve docs. Has anyone ever even aknowledged that inquiry? No.

You should have contacted package developers. If they are still maintaining then *they* should apply the patches, if they are not then ask them to make *you* a maintainer. Example of this approach: I recently took over the maintainership of HTML_Menu. Of course, the package developers may be completely unavailable and there are no fixed rules for this case. Then again, why don't you contribute your skills and time to coding a bug and patch tracking system? P.S. The amount of words you've writen in this thread would be sufficient for a medium-sized tutorial. Consider this.