Documentation translators: Changed para in ch_oview

[Geert Janssens]

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