GnuCash page Documentation Update Instructions has been changed by Sunfish62

[Chris Good]

> -----Original Message-----
> From: David T. [mailto:sunfish62 at yahoo.com]
> Sent: Friday, 27 January 2017 9:04 PM
> To: Geert Janssens <geert.gnucash at kobaltwit.be>
> Cc: gnucash-devel at gnucash.org; Chris Good <chris.good at ozemail.com.au>
> Subject: Re: GnuCash page Documentation Update Instructions has been
> changed by Sunfish62
> 
> Geert,
> 
> Thanks as always for providing a clear explanation of the situation. You have
> gently shown me where I have misunderstood the process, and make it
> clearer to me.
> 
> I have entered a version that I think does a reasonable job of promoting git-
> maint as the commonly-used mode, but also explaining when git-master
> might be used. I also included a reference to Git#Branches for the curious.
> 
> Chris, does that work for you? I hope so!
> 
> …Now on to the next areas…
> 
> David
> 
> P.S. Chris, you don’t need to apologize to me for being argumentative; I can
> be obnoxiously argumentative as well—for which I apologize as well.
> 
> > On Jan 27, 2017, at 2:06 PM, Geert Janssens
> <geert.gnucash at kobaltwit.be> wrote:
> >
> > Op vrijdag 27 januari 2017 11:09:10 CET schreef Chris Good & David T:
> >> On another point, you commented on the page that I took away
> >> information about committing to master. A few things on this: First,
> >> for documentation, a non commit contributor is only going to be
> >> documenting existing features, so they will ALWAYS be using maint.
> >> One of the wiki pages for git states this; I was merely making this agree
> with that.
> >> Second, the pages on git already go into this in more detail (which,
> >> by the way, was why I suggested having one git wiki page earlier), so
> >> adding it here only muddies the water. Third, you did precisely this
> >> with regard to the user of xmllint/xsltproc and make. David
> >>
> >> Non commit  contributors are not the only ones to use this page.
> >> Both Git and Git_For_Newbies say:
> >>  maint
> >>    Bugfixes, translations, improvements of the documentation should
> >> *usually* be applied on this branch.
> > For sake of the discussion I will add the exact rule would be that you
> > should document a feature on the same branch as it is available on in
> > the gnucash repository, with maint taking priority over master if it's
> available on both.
> >
> > It's true that currently most new documentation is written for
> > features that have already been released in a stable gnucash version
> > (and hence are on the maint branch), so this documentation should go on
> the maint branch as well.
> > However this is partly because the documentation is running behind so
> > much and the current writers are still catching up (for which I'm
> > immensely grateful!)
> >
> > There is a period in each development cycle where this is not so
> > obvious. When we start releasing development snaphots - the next one
> > being 2.7.0 somewhere later this year - documenters are invited to
> > look at the new features that weren't previously released and write
> > documentation for those. Similar to how translators mostly work on the
> > maint branch, except during the prerelease period. Both are examples of
> when to create patches against the master branch.
> >
> > If you find a way to express this distinction concisely and clearly,
> > I'd love to have this at least mentioned in some way indeed.
> >
> > Geert

Hi David,

Much better thanks!
I have made a couple of slight adjustments.

1.  Changing
for example, when GnuCash is in a development cycle),
To
for example, a feature only in a future stable release),

because GnuCash is effectively always in a development cycle.

2. Changing
For more on this, see [[Git#Branches|Git - Branches]]
To
See [[Git#Branches|Git - Branches]] for more on this.

I have previously been called to task for not ending a sentence with a full stop.
When other points at the same list level all end in a full stop, I think we should be consistent.
You may have been concerned, like I was, that the full stop would cause problems with the link.
I now try to restructure the sentence so the link is not at the end of the sentence.

Regards, Chris Good
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4817 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20170128/4951744c/attachment.p7s>