Am I doing open source right?

8 点作者 lollipop25超过 8 年前

I'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't really know how the internals work, therefore I could not contribute the most essential part of it all: code.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.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'm rewriting years of debugging and work.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't wrap my head around the implementation. I feel like I'm not at the same level as the other members of the project.Am I doing open source right?

8 条评论

ocdtrekkie超过 8 年前

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超过 8 年前

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超过 8 年前

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.

评论 #12561497 未加载

informatimago超过 8 年前

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超过 8 年前

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超过 8 年前

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超过 8 年前

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

Jtsummers超过 8 年前

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):<pre><code> * 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 </code></pre> I then tear it apart:<pre><code> * 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 </code></pre> 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.<pre><code> 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. </code></pre> 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.