Am I doing open source right?

Few people highlight this, but people doing stuff like documentation and support are hugely valuable... and often, completely missing... from open source projects. Open source projects have a high tendency to be seen as difficult to get involved with or difficult to use, because support may be limited or non-existent.

If you're helping people on issues or giving feedback on PRs, I'd absolutely argue you're a valuable member of that project's community, and perhaps key to the continued success and growth of that project.

Non-code contributions are super valuable. They're not "doing open source wrong".

But rebuilding it from the ground up is rarely the best way to try to understand a codebase. You're both biting off more than you can chew and at the same time requiring yourself to build code for concepts you don't yet fully understand.

If you want to get deeper into the code, ask your fellow maintainers to help you do it slowly.

Ask them to assign you a few easy changes - just as you'd do when learning a new codebase for a new job. You can start with something as simple as tweaking copy in a hard-coded string, and move up from there.

With specific tasks you also have a defined learning curve for picking up bits and pieces of how it works, and an excuse for asking for explanations.

Another thing to try might be to start reading the commit history of the codebase from commit zero. However, that's a LOT of code to read, its usefulness (and tractability) depends on the original developers' commit habits, and you still won't have the conceptual guidance around why things were done a specific way.

What you do is also very important, and it's normal that a project has people with different levels of skill and knowledge about the details in it. So no, you are not doing it wrong!

If you want to get more into the details:

If you already do useful work for the project, you should be able to ask one of the devs more familiar with the internals for help/review. Try finding some "easy" issues in less scary parts of the code and work on those, then work your way up. Just because you don't understand all aspects enough doesn't mean you can't start working on some of them.

If you as someone quite familiar with the project has trouble getting started, that should be a sign that onboarding (e.g. high-level documentation of what happens internally) could be improved, and hopefully is something other devs support. Maybe you could write docs about what you learn and have it reviewed by them -> learning effect for you, better docs for the project.

Yes. You seem to be bringing very valuable contributions that few developers are able to dedicate time to.

On the other hand, you also seem to be wanting to explore more depths in software development.

A parser should not scare any programmer, parser theory is well developed and well known. There are a lot of books, and online-lectures to learn about parsing, so you may learn about it and become able to modify or debug the parser or the parsed language.

Just use a search engine to find lectures about scanning (lexical analysers), parsing (syntactic analysers), and compilation in general, since it's usually in the context of compilers that parsing algorithms are studied.

Now the point here may be that for each component of your software, you may have to learn one more technique or one more theory to understand it and be able to contribute to it in a meaningful way. That's how it is: programmers keep learning all the time, we're not finished when we get our diploma, it's only the start.

I'll reiterate like almost everyone - I think you're doing extremely important work.

The bigger question is - is it what you want to do? You might be really good at what you do right now, but you may actually want to code - for various reasons that are yours.

If that's what you want, I'd first suggest - don't try to take it all at once. It's a hard task even for experienced developers. From the top of my head - a good way to get in might be writing tests. Maybe you could partner with a current developer to write tests for him and that way get a glimpse into a specific module.

If you're not into actually writing code, I'd try to understand why you feel you're not at the same level. If it's because of other people's attitudes, well, that's not good!

Sounds like you are doing a good and important job. Personally I would like to get myself into projects, both to help open source and learn more.

What project is this and how does one start helping?

Yes, many projects would kill to have someone like you on their team.

Like the others, you're definitely doing it right. The work you describe is critical to a well-functioning project, and not everyone has to provide code or understand it to provide to a project.

====

If you want to understand the code, something I've taken to recently is to perform a dissection of a project. Obviously, large projects make this very difficult, but if it can be broken down into component parts then it becomes more manageable.

Let's say I want to understand a C project. I'll take the code, verbatim, and put it into a literate code system (I use org mode in emacs, there are others that will do this like the Leo editor but I have less experience with them):

  * foo.c
  #+BEGIN_SRC c :tangle foo.c
    /* Often the license and other basic comments
    */
    #include<stdio.h>
    void function1(void);
    void function2(void);
    int var1;
    int var2;
    void function1(void) {
      ...
    }
    void function2(void) {
      ...
    }
  #+END_SRC

I then tear it apart:

  * foo.c
  #+BEGIN_SRC c :tangle foo.c :noweb yes
    <<comments>>
    <<includes>>
    <<function-declarations>>
    <<variable-declarations>>
    <<function-definitions>>
  #+END_SRC
  ** Comments
  #+NAME: comments
  #+BEGIN_SRC c
    /* comments from earlier */
  #+END_SRC
  ** Includes
  ** Function Declarations
  ** Variable Declarations
  ** Function Definitions
  #+NAME: function-definitions
  #+BEGIN_SRC c :noweb yes
    <<function1>>
    <<function2>>
  #+END_SRC
  *** function1: void->void
  Notes on what I've learned about this function, what it does and why.
  #+NAME: function1
  #+BEGIN_SRC c
    void function1 (void) {
      ...
    }
  #+END_SRC

I keep tearing things apart like this, and test that the whole system still builds (and passes what tests may be runnable on my system) when I tangle the code (C-c C-v t in emacs), which generates a file called foo.c. Another option is to do a diff between the generated file and the original, tell it to ignore whitespace with `diff -w` because you've probably messed up tabs/spaces or empty lines, but those shouldn't stop the program from compiling/executing correctly (be careful with languages like python, but even there it still works just pay more attention).

I keep going until I get to an absurd level of detail sometimes, but I understand what the code is. And by deliberately tearing it apart I learn a lot right there. Often the notes are unneeded for my personal understanding and only written to maintain the habit for those sections that I don't understand. And, being emacs and org-mode, I can insert links to specific lines of code, footnotes, external documentation, internal links, etc.

====

Writing about something (really, communicating with others about it, writing is just one exercise of this) is a great way to understand it.

  Project does X.

  Project does X by Y.

  Y depends on A, B, C. Specifically, A.f, A.g, all of B, and C.f.

  To use Project you do This.

  To test Project you do That.

As you add pieces to this document, you'll realize what's missing. Use a good editor that lets you mark sections as complete, incomplete, in-progress, need-work, etc. This will help you quickly discover what parts to add to and so on. You don't have to complete this, but it may be useful to your community if you can create a series of guides in this vein or get them started and get others to begin contributing to complete them. A developer's guide to the code (the dissection example). A contributor's guide to compilation/testing. And so on. The act of producing these will provide benefit to the project and improve your understanding, and comes from your current experience with contributing to the project.