Clarifications and guidance for a hopeful contributor

[Tracy]

On 1/17/2016 01:31, John Ralls wrote:
>
>> On Jan 16, 2016, at 5:02 PM, Jesse Olmer <jesse at wickedgoodtimes.com> wrote:
>>
>> Hello,
>>
>> I've spent a few days going through the wiki, uservoice, HACKING & README
>> files, commit history, list archive, and building and debugging the code.
>> I'd like to start contributing but would appreciate some help with the
>> following few questions:
>>
>> 1. How does the project prefer code submissions which are not fixes for
>> bugzilla bugs? Several sources have contradictory information on how the
>> project prefers to receive commits/patches. It's clear that if there's a
>> bug filed the project prefers a patch submitted in the bug. Beyond that,
>> are pull requests allowed/encouraged, or ignored as the README suggests?
>>
>> 2. How accurate is the Roadmap in the wiki? Some of the goals there haven't
>> been changed since 2010 so I'm not sure if they're still a priority or not
>> (e.g. replace deprecated libs that are gone from gtk3).
>>
>> 3. I believe I read that all new features should be written in C++. How
>> strict is this (e.g. are feature additions to, say, the register, locked
>> until the register is ported?)
>>
>> 4. Probably most important for now: What's the best place for me to start
>> contributing, get my feet wet in the code-base, and make an impact? With
>> over 1000 bugs in Normal priority it's hard to identify a true priority vs.
>> an area which is likely to be rewritten "soon".
>
> You'll also want to review the Doxygen-based documentation at http://code.gnucash.org/docs/. There are two sets, MAINT and MASTER for the stable and development branches.
>
> Pull requests are encouraged, especially for complex changes where multiple commits make clearer the stages of redevelopment. Work in a feature branch and rebase it frequently on the branch it tracks.
>
> The roadmap is up to date. It's also very ambitious and we're short of resources so we expect it to take a long time.
>
> The requirement for C++11 depends on what you're doing. On the one hand there's plenty of work that can be done in C, on the other anything that involves substantial rewriting should be done in C++11 so that it's done only once.
>
> Register and its GtkTreeView sibling Register2 is a bit of a special case. I don't think we've really figured out what to do with it at this point. Its code is a bit messy and reg2 simply copied-and-pasted huge swaths of reg code, changing a few pieces here-and-there to work with GtkTreeView instead of the gnumeric-based custom code of reg. I think that it all needs massive cleanup before it's even safe to add features to it, but others might think otherwise.
>
> The best way to get familiar with the code base is to work on bugs. As you observed, there are plenty to choose from. The severity and priorities are usually set by the submitter and seldom changed by the developers so they're not very useful for selecting what to work on, but I put crashers at the top of my list. I suggest that you pick a single component to limit the amount of code you have to digest right away, look at some of the bugs in that area, and then come back and ask more questions.
>
> Regards,
> John Ralls
>

Here's a bug that shouldn't involve Register or Register2, but should be 
an easy fix, if you're looking for a convenient starting point... O:-)

https://bugzilla.gnome.org/show_bug.cgi?id=739571