| 1 |
On 2012-10-10, karan garg <karangarg31@×××××.com> wrote: |
| 2 |
|
| 3 |
> I have been an open-source enthusiast since 2010 and using Linux as my |
| 4 |
> operating system for last 2 years. However, now I want to take an active |
| 5 |
> part in open-source development and contribute to the society under an |
| 6 |
> expert guidance. I am an RHCE and have a basic understanding of a fair few |
| 7 |
> things like database, c, c++, ruby, shell scripting, etc. I would really |
| 8 |
> consider it an honor if you would guide me. |
| 9 |
|
| 10 |
I always recommend that first you need to find something you _want_ to |
| 11 |
do. Is there a program you use regularly that doesn't quite do what |
| 12 |
you want it to? |
| 13 |
|
| 14 |
In my opinion, it's easiest to start with adding a small feature or |
| 15 |
improvement. |
| 16 |
|
| 17 |
Once you've decided what you want to do, file an enhancement "bug" |
| 18 |
with the project's bug tracker describing in detail what it is you |
| 19 |
want to do. It's always nice to explain why they new feature is |
| 20 |
useful and how you anticpate it will be used. |
| 21 |
|
| 22 |
There will probably be some discussion in the bug-tracker or project |
| 23 |
mailing list about whether the feature/improvement is a good idea and |
| 24 |
how it might be done. Once there's some agreement, then add the |
| 25 |
feature and submit the patch. There will probably be comments on the |
| 26 |
patch, so try not to get defensive. After a few iterations getting |
| 27 |
new feature tweaked and the coding style fixed, then somebody will |
| 28 |
apply the patch and your name shows up in the ChangeLog file. :) |
| 29 |
|
| 30 |
Alternatively you could try to fix an existing bug that's already been |
| 31 |
reported, but that's usually more difficult: |
| 32 |
|
| 33 |
* It will often take quite a bit of effort and knowlege to set up a |
| 34 |
test that can duplicate the bug. |
| 35 |
|
| 36 |
* Fixing a bug will often require a lot more knowlege of the |
| 37 |
program's internals that will adding a new feature. |
| 38 |
|
| 39 |
If you _can_ duplicate an existing bug that somebody else is working |
| 40 |
on, simply offering to help test proposed fixes will usually be very |
| 41 |
much appreciated and is a good way to learn more about the program and |
| 42 |
its internals. |
| 43 |
|
| 44 |
Working on documentation is also always very welcome: |
| 45 |
|
| 46 |
* Expanding manual sections that are incomplete (adding simple, |
| 47 |
useful examples is almost always welcome). |
| 48 |
|
| 49 |
* Writing a tutorial showing how to use a program to accomplish a |
| 50 |
complex task. |
| 51 |
|
| 52 |
* Updating tutorials/examples that are out of date and show obsolete |
| 53 |
usages. |
| 54 |
|
| 55 |
* Translating documentation into a new language. |
| 56 |
|
| 57 |
* Fixing formatting, grammar, and spelling errors. |
| 58 |
|
| 59 |
-- |
| 60 |
Grant Edwards grant.b.edwards Yow! If our behavior is |
| 61 |
at strict, we do not need fun! |
| 62 |
gmail.com |
Archives