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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
