[fpc-devel] [RFC] fpdoc output comment from the source

[Daniël Mantione]

Op Wed, 21 Dec 2005, schreef L:

> 
> 
> 
> >
> > > We've looked at the people on the mailing list many times, but we've
> > > never seen people sticking out their neck and actually doing something
> > > along these lines.
> 
> I've looked at people in charge many times, but I've never seen those in charge
> sticking their head out telling me directly, with real instructions how I can help,
> along with my
> SVN password, what the rule are with what I'm allowed to help with, etc.

Our policy is that we give people SVN access after they have contributed 
code a few times. Perhaps it is a bit annoying, but we need to be a bit 
conservative here to prevent too many people messing with FPC's code. 
However, it is not very hard to gain SVN access, usually we are quite open 
to it.

> All I've  (we've) seen so far is the people in charge criticising any incoming
> suggestions or concepts.

We need to, not everything that can be done should be done, and a lot of 
proposals are about "let's start from scratch and do it better".

> I'm no lazy man, I'm a grunt worker. I stick my neck in when
> I have precise directions on how to and what I'm allowed to.  I think there are more
> conflicts here going on then just people not sticking their neck in. Constantly
> critisizing people for not sticking their neck in won't really help. Sending them an
> email questioning what they would like to help, where their svn password is, under
> what conditions , etc. will help.
> 
> At times I find the responses of the FPC lists negative rather than encouraging.
> 
> Let's have collabritive discussion with precise directions on where I and others can
> help, in what programming languages, with what restrictions - rather than arguments
> and quick judgements such as "ahh, he won't help, otherwise he would have uploaded it
> already".
> 
> Uploaded where? Under what circumstances? With what password? With what language? I'm
> sorry, but it's not just as simple as a patch, with this documentation system. With a
> compiler change, it is sometimes as simple as a patch. This is not a compiler change,
> this one. This isn't a patch. Plus, I dont' see any way to make patches to the PHP
> code anyway - as stated in previous mail regarding only seeing HTML on svn. Plus,
> even if a patch were possible, I don't think it would be allowed in anyway - because
> my suggestions have been determined as no-goes already. So if our discussion has led
> us to the conclusion that we won't be implementing what I thought up, why bother me
> doing any grunt work anyway? You see, you do have to have discussions before doing
> grunt work - because if I would have done the grunt work, the patch of mine would
> have been disregarded anyway!

That is way too sceptical. Yes, you need to have discussions, if it is 
a good idea. However, if your proposal is to write an enchancement to the 
site, or a cleanup, or whatever it won't be taken so skeptically. 
Proposing features that already exist, like a commenting system, makes 
people skeptical, though.

Daniël