Documentation translators: Changed para in ch_oview

David T. sunfish62 at yahoo.com
Thu Aug 11 12:19:31 EDT 2016


Geert,

I truly appreciate your reasonable and reasoned reply. It makes clear even to the densest of us (me). I was not aware of Frank’s longstanding and ongoing contributions to GnuCash, and for that I also apologize.

I have since seen Frank’s explanation as well, and I appreciate his work to improve the program and its documentation. I heartily endorse such efforts, and I hope that my misguided comments can be set aside, and the actual work can continue.

Thanks,
David

> On Aug 10, 2016, at 9:29 PM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> On Tuesday 09 August 2016 21:22:36 David T. wrote:
> > 
> > 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.
> > 
> While I appreciate your concern I don't perceive it the same way.
>  
> While this patch started the discussion, it's not an example at all of what we are discussing. On the contrary. Frank is a core contributor to the project and as such has direct commit rights. He exercised this right by committing a change in the documentation. Such direct commits by developers have always been part of the gnucash development cycle and are nothing new.
>  
> As he cares about the quality of the documentation he explicitly asked the other translators to review his work. Without this request the change may have gone unnoticed until the next release. The question was a terse and cryptic for those not fluent in git(hub). That was acknowledged and addressed (I hope).
>  
> And I can't tell why Frank chose to push this commit rather than following your suggestion in bug 743672. He can explain that himself if he cares to. By the way, I believe you were on the right track and agree even more with John we should remove this section completely as it tends to outdate the documentation.
>  
> Yet in essence all of this had nothing to do with pull requests, which is what this discussion is now evolving around.
>  
> Bugzilla is still our main issue tracker. Patches are welcomed there.
>  
> Our choice to also accept pull requests is complimentary to this and targets a different kind of contributors. Those that write code (or documentation) directly as a feature request. Instead of describing what they need fixed they offer the fix itself. This is not possible for all contributors, but for those who can it's the most efficient way to contribute. That is just the reality. (1)
>  
> Will this dilute our attention from bugzilla ? By no means. Bugzilla is still our main issue tracker and as far as I know will remain so. Anything that can't be solved immediately should be added in bugzilla still. And when looking for things to fix I still start from there.
>  
> I agree with you that having two issue trackers would indeed most likely result in one being favored over the other. However we don't use github as an issue tracker. We use bugzilla. Pull requests are ready-to-review change suggestions, which is much lower level and direct than a feature request or bug report.
>  
> Since we started accepting these we are seeing more so called drive-by patches - that is patches from occasional (non-core) contributors that happened to tweak something in gnucash and decided to share it because sharing is so easy via pull requests - than we ever had before. So that means more improvements in gnucash with less core developer time spent. I consider that a win-win.
>  
> Regards,
>  
> Geert
>  
> (1) Note that even those contributors are encouraged to announce their plans an discuss beforehand before sending in huge pull requests. We had to refuse some of those already because they were not manageable which is really a shame, frustrating and lots of wasted time on good-meaning people. But this is no different from attaching patches in bugzilla (except adding lots of patches to bugzilla is more cumbersome).



More information about the gnucash-devel mailing list