Re: [Call For Votes] PHP::Fork

<mj@php.net> wrote : > On Sat Nov 08, 2003 at 11:2521AM +0100, Stephan Schmidt wrote: >>> Sounds fine for me. However I'm only +1 on this when there is end-user >>> documentation in plain text or Docbook. (That's one of the >> requirements >>> for contributing new code, btw.) >> >> You can't be serious! > > Adjust your tone. Thanks. > >> Does this mean that a developer has to write >> complete documentation before a pakage will be accepted? > > "Documentation in an appropriate format (plain text, docbook) > > Your code must come with appropriate documentation in one of the > following formats: > > - Docbook XML > - Plain Text" > > (http://pear.php.net/manual/en/developers.contributing.php) > > It is pretty funny to see how much developers have actually read the > "Developers Guide" ... Documentation cannot be a requirement for a package to be accepted. You can't expect documentation for a package in alpha state, as the API might change and the author is going to waste time writing it. Not to say about the translators work. Furthermore, what's the point of having a CVS server if a package has to be in a finished state before being accepted ? CVS is a development tool and developers are encouraged to use it. IMO, you put too much restrictions and that's probably why there have been very few proposals since these guidelines came out. PEAR will break down if no new packages are proposed regularly. PECL is much more open, for C code that could compromise the stability of your system. Maybe you could enforce documentation for a package once it is in PEAR, in beta or stable state. A package without doc is not going to be used anyway and could be removed from PEAR after a certain period of time. I prefer a package without documentation to a package with an outdated or a confusing documentation. Some doc in PEAR manual is totally out-of-date. Bertrand Mansion Mamasam