Getting started with KDE Software
Krita is a great place to start even if you are brand new to KDE development. We'd love to have you join!
KDE has undergone big changes since a major 2014 reorganization. As a result, working with KDE software has never been easier. Unfortunately, since the changes were so widespread, the documentation has not caught up at all. If you are embarking on the journey, please remember that all of these wiki pages are open to editing. (Select the OpenID / Identity Login option with your KDE Identity account.)
The KDE Techbase Wiki has instructions for new developers. On top of basic tools of C++, git, and general notions of building and packaging large code bases, some special tools that are particular to Krita are Qt, CMake, and KDE Frameworks. It can be very helpful for you to get started to find and read some of the articles discussing these tools. Here are some of the more useful pages to get you started:
Getting in touch
Patch review and issue tracking happens on Phabricator. You can use your KDE Identity for the LDAP login field. Just search for Krita under Projects! https://phabricator.kde.org/
Other places to talk are the forums, IRC, and the mailing list. Wolthera put together a nice guide here. https://forum.kde.org/viewtopic.php?f=288&t=125955
To get started, all you need to do is get a copy of Krita and build it! There are guides to doing that on Krita's front page on this wiki.
Calligra and Krita
In October 2015, the Krita project separated from the rest of the Calligra office suite. The new repository still clearly contains this history. Most source code files will have one of two prefixes. "Ko" stands for KOffice, the original name of Calligra office suite. These files mostly comprise basic, lower-level libraries. "Kis" stands for KImageShop, the original name of Krita. These files are where most of the painting-specific functionality is maintained.
Krita is nearly ten years old, consists of around 1.1 million lines of code, and has had many individual contributors throughout the years. If you run into something in the code that doesn't make sense to you, it may very well not make sense to anyone. Developing a codebase this large is an art form, you should feel confident in making risky changes even if you're not sure they'll work, you can always go back with git checkout -- * if you mess it up!