[GNC-dev] Simple Start to Contributing

[John Ralls]

> On Jul 15, 2022, at 10:58 AM, Paul Kroitor <paul at kroitor.ca> wrote:
> 
> Hi, my apologies for asking such basic questions, but I'm new to GnuCash
> contributions - although not to coding - and want to try a simple (useful)
> change to get my feet wet. So I've "fixed" the cash-flow.scm module (the
> Cash Flow report) locally to adjust a minor annoyance (I added a "Show
> Accounts as Hyperlinks" checkbox so it can match the other two standard
> financial statements). It works the way it should now, but needs testing
> against a broader set of inputs, and the localizations must get queued.
> 
> 

Welcome to GnuCash!

What languages and programming styles (I mean what are sometimes rather grandly called paradigms, like object-oriented or functional) do you like?

Your question about feature branches suggests that you may not be familiar with git. What source control systems have you used?

> 
> Some questions arise:
> 
> 1.	Do I have to post anywhere / get agreement before embarking on such
> a contribution (I have 30+ years of experience managing programmers and do
> know I must keep the changes homogenous in style and approach to the
> existing codebase)? 

For simple changes like this, no. For more substantial changes or new features it's wise to discuss here starting with whether the proposed change is even something that we'll accept and once that's settled working out the design.

> 2.	Must I checkout and build the entire project if I am only going to
> be working in Guile/Scheme for the moment, or is there a simple way to do a
> subset?

GnuCash doesn't have any subprojects so you have to clone the whole thing. If you don't want to build yourself you can enable CI on your personal GitHub repo and let Github actions run the building and testing part for you.

> 3.	Do a make a "feature branch" for this very localized change? It's
> about 10 lines in a single file.

Unless you're planning to have only one open pull request at a time you'll make your life much simpler with feature branches. Branching in git is not only utterly painless it's a great way to organize your work. I often create multiple branches to try out different approaches to solving a problem or implementing something, flipping back and forth between the branches as my thinking and the code evolves. Commit often, it's a lot easier to squash a bunch of commits together than it is to pick apart a pile of changes into separate commits.

> 4.	I have about 10 sets of production books here, but I use no business
> or shareholding features. The changes shouldn't interact with these, but
> they should be checked anyway. Are there test .gnucash databases with "one
> of everything" than can be used to test against (I do use multiple
> currencies, and have tested that)?

Unfortunately there isn't. It would be great to have one or more.

> 5.	I understand that the localizations will happen semi-automatically
> by a different team, but is there a way to use a common instance of the base
> (English) text constant so they don't have to re-translate strings that are
> already there (e.g. the "Show Accounts as Hyperlinks" string is already in a
> half-dozen other scheme files, and thus will have already been translated
> into many languages)?

Nothing automatic. You can look at and search the existing translation files in po/ to find existing strings that might work for you.

>  
> 6.	How / who do I tell that it's new and should be tested before
> release?

You can try pleading on gnucash-user for people to try out your feature in the nightly builds once it's been merged, but we haven't had a lot of success with that except when fixing something that someone has complained about.

Regards,
John Ralls