
Am I doing open source right? - lollipop25
I&#x27;m a member of an open source project. I tend to issues, answer questions, do house keeping, review some PRs, such and such. But I feel out of place because although I tend to the matters of the repo, I don&#x27;t really know how the internals work, therefore I could not contribute the most essential part of it all: code.<p>Other developers in the project are having these cool discussions about implementation in the issue tracker, but I have no idea what they are talking about. They talk about all these buzzwordy things like virtual DOM, view models, and all those things.<p>Every time I try going on a safari, the parser piece is enough to scare me away. I also tried to implement a minimal version of the framework just to get the basics. But whenever I look back at the project for reference, it feels like I&#x27;m rewriting years of debugging and work.<p>I know how to use the framework, I use it regularly. I can explain to others how to use it, why use it. I just can&#x27;t wrap my head around the implementation. I feel like I&#x27;m not at the same level as the other members of the project.<p>Am I doing open source right?
======
ocdtrekkie
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.

------
cauterized
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.

------
detaro
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.

~~~
bbcbasic
> 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!

Companies need product owners, project managers, testers, support staff,
technical authors and many other non-coding roles (roles not mapped 1-1 with
people: a coder can where these hats too). So I suggest open source projects
need this too and the OP's role is quite valuable. It can be useful also to
have someone say ELI5 to make sure the coders can justify those funky changes!

------
informatimago
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.

------
kobigurk
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!

------
hr2016
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?

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

------
Jtsummers
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.

