Starting point for people who would like to contribute.
I think Notepad++ is an incredibly awesome text editor, and I am always hearing that if you want to contribute to an open source project, it is best to find one you will actually use. So here I am. I am sure this question is a stupid one or it has already been asked, but where should I start if I wanted to understand and try and contribute Notepad++ code? I have programming experience, I just have never programmed with a group and figured what better time than now. Is there a certain source file I should start looking at that would help me understand the structure of code? Seeing all these files is overwhelming and I want to know how other people can come into the project so late in development and dive right in being productive. I understand it is not something that happens over night, or even in a weeks time, but there has to be a starting point to become familiar with the code (I hope). How important is an understanding of scintilla? Must I learn how to use scintilla before I can understand Notepad++ code? Sorry for a million questions, I just think this is a really neat project that I would like to try and contribute to. Thanks!
The best starting point if you have some C++ knowledge is to try to fix bugs already reported in github (all bugs reported for the 6.x releases). If you have any doubt on how to fix the problem (or if it implies to change the architecture, which is quite possible), you can propose a solution before submitting any pull-request.
There’s not really a good starting point, and don’t try to understand all the code at once. Find a particular piece that interests you (maybe a few files) and just stick with that for a bit. As you play around with that you will eventually wonder to other pieces of the code and learn slowly how it works. Understanding Scintilla isn’t required depending on what part of the code you’re fixing. There is certainly a lot of code that doesn’t touch Scintilla at all.
And as milipili suggested, bug fixes are definitely a good place to start, plus those are usually easily accepted.
Also, a good way to learn about the code is look at the git commit history. Find a commit message that sounds interesting and see what files were committed and what changes it introduced. That way you are seeing a set of changes over multiple files, without having to know what is going on in tons of files.
Awesome! These are great suggestions.