> On Aug 9, 2016, at 7:23 PM, Geert Janssens <geert.gnuc...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel