[development] Reviewing patches and making decisions -> Sociocracy could be a way to go!

David Metzler metzlerd at metzlerd.com
Fri Nov 7 05:28:13 UTC 2008

Funny that I was having just this discussion with my Dev team at work  
today.  How shall we document how/why something works.   I think most  
of the folks agreed that closer to the code is better. So comments is  
the best answer but it's often difficult to document how disparate  
modules connect in code comments.

Another resource that we have that's not used as much as it could be  
is the API module and it's document generation techniques.  It  
already documents much of the bigger picture with core modules.   
Correct me if I'm wrong, but cannot developers maintain "extra"  
technical documentation in a separate document along with their  
modules in CVS?  That might be a good thing to version control, but  
keep a static document, that feeds api documentation. I know this is  
possible with other modules such as Doxygen, but am not sure that it  
works in API module. (but I bet it could). This is the solution we  
landed on in my dev shop.

That way rational/design info could(should?) be supplied with  
patches.  In separate documentation and it would help those who do  
patch review understand how/why something is supposed to work before  
it gets committed.

You see that's the one problem with using CVS annotate.  The commiter  
provides that message, but the patch submitter is the one who needs  
to supply the documentation :).  And remember our goal here is to  
make it easier for the review/commit phase, so adding doc work to the  
commiter is counter productive.

So I like using CVS for why something changed, but not how something  
is supposed to work.  That needs to be in code comments or lean text  
base documentation that goes with the code.

But perhaps we near exhausting all that can be said on this issue.

On Nov 6, 2008, at 8:21 PM, Angela Byron wrote:

> On 11/6/08 6:19 AM, Thomas Zahreddin wrote:
>> Hi Angie,
>> thank you for answering the first third of my mail. I think we are  
>> not on the
>> same page:
>> in the last third I wrote explicit, that I know all the tools and  
>> places where
>> to find informations - but i also mention that it is impossible to  
>> follow all
>> relevant information.
>> To lower the workload for us all we need a summery on a much  
>> higher level than
>> CVS-messages (btw how many do we count a day - my estimation is  
>> two a minute).
> I answered the first third, because it seemed to me that the last  
> two thirds were based on the presumption that the information you  
> seek is not readily available. But CVS annotate seems to do exactly  
> what you request and it requires no manual effort on the part of  
> our already over-burdened maintainers to keep up to date, since  
> it's updated automatically with every commit.
> In what specific ways does CVS annotate not get you what you're  
> asking for? That would probably help the justification for your  
> proposal be a bit more clear.
> -Angie

More information about the development mailing list