Documentation translators: Changed para in ch_oview

Geert Janssens geert.gnucash at
Tue Aug 9 10:23:47 EDT 2016

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 

> > 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.



More information about the gnucash-devel mailing list