Documentation translators: Changed para in ch_oview

[David T.]

> On Aug 9, 2016, at 7:23 PM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> On Tuesday 09 August 2016 16:59:10 David T. wrote:
> > Geert,
> > > 
> > > Ok, I had to re-read this a couple of times to get your point.
> > > 
> > > For some time now we are accepting changes in two ways: either as an
> > > attachment in bugzilla or as a pull request in github. The
> > > submitter can choose freely based on his/her preference, but is not
> > > required to submit to both.
> > > 
> > > So yes, there can be changes that are only proposed via github.
> > > 
> > > Thanks to your heads up I do realize now this can make it harder for
> > > non-developers to give feedback on those changes. So this can raise
> > > the bar for documentation changes review.
> > > 
> > > On the other hand, I do want to understand in how far github solely
> > > as a review board is crippling you. You didn't answer my direct
> > > questions related to Frank's request.
> > Frank’s first request read as follows: "So I ask you kindly, to review
> > commit e4c8bae - Replace the confusing Release_Schedule link by
> > 2.6-release-tour and website”
> > 
> > That, simply put, means absolutely nothing to me, and I have no way to
> > even know how to find the change, since I do not know how to use
> > git-whatever. Hence, my request, which I thought was respectful.
>  
> I figured this was indeed way to cryptic for you, which is why I added the link in my first reply.
>  
> Your request was absolutely respectful. To be absolutely clear, I didn't intend to criticize you in any way either and I hope I didn't come across as doing so. I understand git is a big hurdle for you (as it is for others). My sole intention was to gather more information to see where we can improve.
>  
> > > You can submit a patch to bugzilla, so I assume you can more or less
> > > interpret such a patch file as well ? (That may be a false
> > > assumption I know hence the question mark). If not the rest below
> > > makes no sense.
> > I believe that when you say “You can submit a patch” that you mean
> > that “You are able to submit a patch.” While it is true that I have
> > submitted patches to bugzilla, each such submission has come at a
> > great deal of trial and challenge—not just for me, but also for the
> > development team (cf. threads “Fun with Git” and “Fun with Git,
> > Redux” in February and August 2015). FWIW, each time I have submitted
> > a patch, I have started from an entirely fresh installation of
> > git-whatever and whatever development platform software is popular at
> > the time, and a fresh installation of GnuCash’s material. This is a
> > major impediment to my contributing more regularly. Honestly, I don’t
> > enjoy such challenges.
>  
> I can imagine and I'm not pushing you to do so. This question was mainly an introduction to the one right below, which is more to the point for this conversation.
>  
> > > So if you are presented with the changes in such a format, would you
> > > be able to read it and understand what's ok and what needs
> > > improvement ?
> > Yes, with the subsequent direct link to the changeset, I can read the
> > changes. I will note that the editorial process is ill-served by the
> > patch method of propagating changes; editorial changes are IMHO best
> > viewed in context; the patch method strips away the context. Whenever
> > I consider a patch in docs, I have to open the current doc in another
> > window to see what the change is actually going to do.
>  
> I agree to this. Technically a patch does provide context, but that's just enough to be able to apply the patch. It's not context in the sense of text to interpret the change in. I really wish I knew a better document management format... But that's a whole other discussion which it don't feel like going in this time.
>  
> > > If you find such areas, as far as I'm concerned, you can post your
> > > feedback on the mailing list right here. Or you can click on the
> > > blue plus sign on github right in front of the line you want to
> > > leave feedback on
> > I don’t see any blue plus sign, unfortunately.
> > 
> Hmm, another developer blind spot... In my case it appears when I hover my mouse over the line I want to comment on. However it's possible you can only do this when you
> - are logged in into github (most likely at least this)
> - have certain permissions in the gnucash repository (don't know which that should be).
>  
> > > and just write it down there in the text box that appears. I'm not
> > > sure how much easier giving feedback can become (all assuming a
> > > patch file can be understood of course).
> > As for the modification that Frank is offering, I will note that there
> > is a bug that I filed in bugzilla (743672) proposing that this
> > section be moved in its entirety to an appendix. Perhaps now would be
> > the time to consider that bug? I don’t see the point of having the
> > What’s new section in a section promoting the features of GnuCash to
> > a new user.
>  
> Yes I agree to this.
>  
> Regards,
>  
> Geert

I think also of concern to me here is that there are now two recommended methods for suggesting and making changes, and as I noted here, with two avenues for change, there is the increasing likelihood that bugs will languish in one or the other systems, depending on chance. This patch provides a concrete example.

David