I hope that you have participated in the well-known open source projects of friends to give some of their own experience and experience.
Reply content:
In recent months, I have been involved in Mruby, not a well-known project, but the more I think about it, the more I think this project is suitable for my rookie:
- Development is more active, Matz in the evening basically will look at
- Matz very good temper, reply also very fast
- Small code, relatively easy to get started
- Not yet officially released, so not very stable, more bugs
- Vision is good.
Before the participation was simply over the garbage collection part of it, happened to see a duplicate code on the deletion of a PR, quickly was the merge. Bold after looking at the code side to send a PR to the garbage collection Section annotated. Slowly familiar with the code, began to Watch it on GitHub, if someone reported a bug will receive mail, reported that the bug is basically 100% reproducible, so easier to locate the repair. But move fast, otherwise let Matz see on the second repair. Try to add regression test after the repair.
The current regret has not yet been submitted to feature, but there are several small idea brewing. Use the Software
Read the source code and documentation
Tracking Mailing Lists
Answer novice Questions
Submit bug reports and reproduce bug codes
Submit patches and test code, modify patches repeatedly
Discuss new functional requirements and design 1. Find Interesting Project
2. Fix issues of this project
3. Fork and Pull Request
4. Congratulations!
reproduced . Source Address: Step by step teach you how to contribute code to Apache Spark
This article will teach you how to accomplish the task of contributing code to Apache Spark in 10 steps .
- Click the Fork button in the GitHub page of Apache Spark
- Spark this project will appear in your GitHub account
- On the local computer, use
[你的 spark repository 的 github 地址]例如：git clone git@github.com:gchen/spark.git
First of all, the benefits of participating in open source,
- Broaden their horizons. It's like learning to draw more famous masterpieces. If you want to improve your skills, that vision can not only be limited in their own work to develop the maintenance of the piece of code. The code of the master is everywhere, but the active open source project is undoubtedly a very good way. Paper on the end of the light, if you can participate in, fix bugs, contribute code, then the efficiency of learning than light look at a magnitude higher. From the perspective of participation, with the source of the book and so can not be compared with open source code. In addition to the code, you can learn a lot of things, such as design patterns, development process, etc.
- * Occupation bonus points. Open source projects can be work-related or irrelevant to work. For example, if you want to change direction, but do not want to be a newcomer to the status of the job, then first in the open source project accumulation of experience is undoubtedly a feasible way. If it is related to work, then open source code who can see, in the job search is also easier to be inspected, recognized. Imagine a resume inside such a sentence will be compared to drag: "Detailed implementation please fork:/ http/github.com/nnnbbb/"
- * Opportunity to know the people of cattle. A good teacher is priceless, sometimes a word, a recommendation may change your career. Can fight with all kinds of cattle in a trench, this opportunity is not a company can provide.
- * Learn English. Given that most of the open source projects still communicate in English, it is also a good way to learn about the native Programmer's English. Say goodbye to your racked-up and lame variable names and function names.
- * Well, I admit that the above mentioned is too utilitarian. In fact, the pleasure of sharing, the code is widely used by the sense of accomplishment, is also very fascinating.
Based on the list above, analyze your needs and think about what projects are right for you. Then is how to participate in, to join in a harmonious open source community, there are some areas to note:
- * First, respect the time of others. Cattle are very busy, do not use low-level problems, low-level mistakes to trouble them. First take a good look at the document, what can not understand the first search, other questions about the attention to the question, see many technical forums have a top "art of Questioning"
- * If you are not very cow, then you can start from the use, testing. Re-open source project will not reject other people's bug report, of course, please note the way to mention the bug, usually, version, environment, the steps to reproduce is not limited. There are other chores that are also a good way to get started and face up, including but not limited to document translation, code collation ...
- * Then you can start to change the minor bug. Usually it is better to walk faster than to eat a big fat man. When you are familiar with the project, you will naturally find that your patch is getting bigger and more important.
- * Submit patches, or request pull before you put the code to clean up, testing, the novice is allowed to err, but the old mistake is a problem.
- * Code style and project already have code consistency. This is like the width of the rails, no right or wrong, 1.4 meters wide than 1.3 good? Not necessarily, but everyone is 1.4, so please you also 1.4. When you start a project yourself, you can decide how you want to be.
from From Github:shop
Read code, participate in discussions, submit patches, report bugs, help reproduce bugs, fix bugs, help test, help Code Review, iterate over your patches, report basic test data, help answer other people's questions, help with supplemental documentation. From fixing a spelling error, adding a test case to submitting a feature, you can do a lot of it. In particular, according to their own interests and the needs of the project. GH on a lot of developers are very nice, their own initiative, can not start from the difficult point, first from a few small places. GH on a lot of developers are very nice, their own initiative, can not start from the difficult point, first from a few small places. If you say "join" an item, using it is also a join.
If it means joining the "developer Team", the culture and style of each open source community is different, and the most effective way is to actively contact them. In 2008, I started using FreeSWITCH ( http://www. freeswitch.org
), join the mailing list / http lists.freeswitch.org
Diving
Later, I was / http wiki.freeswitch.org
An account was created on the update document
Later, in / http jira.freeswitch.org
Created an account to report a bug
Later, a contributor was applied for the permissions on SVN (Freeswitch-contrib directory, which is now unused), in which to submit some of their own scripts, etc.
Later, the project library went to git and requested git commit permissions to update the core code. However, the general update will communicate with the original author of the relevant module or core code via mail or IM. If it is an obvious error (such as a clerical error, or compilation errors, etc.) or a part of your own responsibility, you can submit it directly.
