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

[Nathaniel Catchpole]

Just quickly on committing api.module documentation along with patches - I
started an issue here to have the hook_* documentation committed to core:
http://drupal.org/node/314870 - which I think goes at least some way towards
what you're describing.

Nat

On Fri, Nov 7, 2008 at 5:28 AM, David Metzler  wrote:

> 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.
>
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081107/cbeb24aa/attachment-0001.htm