Re: RE: [Phpgroupware-developers] Standard source code header and php Documentor

[Dave Hall]

I know this discussion have moved on some what, but there are some
points in this i wish to respond to.  Warning some of language does get
a little colorful in parts.

Kai Hofmann <address@hidden> wrote:

> Hi Dave,
> 
> > > Last but not least using another free php project would be a 
> better> > political choice
> > > and the documentation would be more similar to the pear one.
> >
> > I did not make the decision, all I am saying is why start 
> changing it
> > when the job is not yet complete?  It would be less work to 
> > finish what has been started, rather start over.
> 
> The job has never really started - thats what I saw in the whole 
> API source
> code
> so there is nothing to finish.
> And comments that already there can be used by simple copy&paste 
> with the
> phpdocumentor format.

I am leaving the format of the inline/external docs alone - for now.


> 
> > > Sorry I don't see it in this way - so maybe someone other will 
> do 
> > > that.
> > 
> > Then how do you see it?  cos you have lost me.  You are saying 6mths
> > work to start from scratch, so obviously it would be faster 
> > to build on the existing base.
> 
> Again: there is no existing base - for an example please take a 
> look into
> the
> phpgwapi/in
> class.accounts.inc.php
> No comment at all - but it is no class and only a few lines of code
> 
> class.accounts_ldap.inc.php
> - Copyright header
> - 1 method out of 14 has a comment
> 
> class.accounts_sql.inc.php
> - 13 methods only 2 of them have docs
> 
> class.accounts_contacts.inc.php
> - 13 methods all undocumented
> 
> class.accounts_shared.inc.php
> - 8 methods only 2 with a doc
> 
> These four classes have been already documented by me completly 
> now - 
> but I have only submitted one as a patch.
> The rest of the api looks the same - maybe 10-15% of the methods is
> documented right now.
> Most of the class/glbal variables are undocumented.

The classes which are commonly used by developers, are pretty well
documented - from what I have seen.


> 
> So before discussing this point with me you should take one or two 
> days to
> read the complete
> api source code (as I did by creating the argiuml diagram - which 
> toks much
> longer).

I look at the source regularly, my point is not that it is perfect, my
point is that some of it is there.


> 
> > Well, the "bug reports" you have logged, not all are bug 
> reports.  The
> > form they have taken has not been very useful.  For example ~10 
> reports> for different apps, with the same name is very annoying.
> 
> So for what I had to set the module specification?
> The topic was correct for all - SYNTAX ERROR.
> Adding the Module name again to the topic is data doublication.

The app field is not displayed on the search screen, so it is handy if
it is in the summary.

> But as I have seen by the session classes that the normal way you are
> working :(

Really?  Shows how much you look at the code!  Look at sessions in 16!

> 
> > We currently
> > have ~160 open bugs, so clear descriptions make my (and others) 
> life a
> > lot easier.
> 
> When I would have cvs access to the api I would never have 
> reported these - 
> I had fixed them and then you have nevern known that they are 
> there ...

Hiding mistakes does not allow developers to learn from their mistakes.

Also you say you are interested in the API, but many of your bug reports
are related to apps.  Have you posted patches? no  Have you contacted
the app maintainers where there are problems? no


> But it seems you like it more to discusses these things than "just 
> doingit".

No, I do not have time to "just do it", because I beleive in
collabrative development.  I also spend a lot of time dealing with
poorly written bug reports, helping users and developers, and work with
others to keep the project moving forward.  I get very little financial
reward out of this, which doesn't really phase me.  What does piss me
off me is having to deal with bullshit!  IMHO a lot of the stuff from
probiz falls into this category.

> 
> > You have also failed to listen to feedback on the tracker.  Also 
> code> changes which are not bugs are feature requests.  
> 
> Bad design is in my opinion also a bug in the design! so they are 
> no feature
> requests.
> but ok I will keep all bugs (code or design) for me internal and 
> will not
> report anything more
> in the future - because when you are not interested it makes no 
> sense for
> me.

I am interested in hearing what you have to say, if your input is
provided in proper forum and manner.  I have yet to see you listen to
feedback.  I am also yet to see any attempt from you (or probiz) to
seriously engage in the community, you seem happy to throw molotov
cocktails from the sidelines from time to time.


> 
> 
> Seems to be better when I only do what my employer wants me to do and
> nothing more.

That is your choice.

Cheers

Dave

dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>