Re: Another others for maintainer?

[Eli Zaretskii <eliz@gnu.org>]

> From: Rasmus <rasmus@gmx.us>
> Date: Fri, 23 Oct 2015 00:06:18 +0200
> 
> Well, I have commit access and I contribute to Org fairly often (though
> recently time is an issue).

Thanks.

> Emacs is the most important program on my PC.  I would like to do more,
> but Emacs-core is daunting.  It’s hard to get into Emacs-core, not only
> because you are dealing with something that’s fairly complex and it’s hard
> to even identify tasks (to me), but also because I’d be scared of messing
> something up.

You shouldn't be scared.  You can always push a branch to Savannah and
let you and others use the modified code for a while, until you are
sure enough it has no adverse effects, and then take the plunge.

I know the feeling, believe me.  I was exactly at that place when I
needed to merge the bidirectional display engine onto master for what
became Emacs 24.1.  The display engine is one of the most complex
parts of Emacs, perhaps _the_ most complex part.  It is also central
to any Emacs operation.  The thought of screwing up everybody's Emacs
or have Emacs crash every few seconds absolutely petrified me.  I
remember debating and procrastinating for some time, unable to make
the final decision.

What made it happen was an email from Stefan and Chong saying they
absolutely trust me with this merge.  (They didn't see the code, so I
have no idea what could make them say that.)  The rest is history.

The lesson I took from that is clear: well-tested changes are safe to
merge.  Make sure you test your code as much as you can, run the test
suite, prepare your own test cases if the suite is not extensive
enough for your changes, use the modified version in real-life
sessions -- if all that passes without problems, you are good to go.

> I’m not saying the information isn’t there, simply that it’s overwhelming,
> especially if you are more interested in improving existing code, instead
> of, say, providing new modules.

My advice is not to try to comprehend all of it.  Instead, take some
specific problem that needs to be solved (the bug tracker has many
candidates, or maybe you have your own bug you want to fix or a
feature you'd like to add), and study the parts(s) relevant to that
single problem.  Don't hesitate to ask questions here where you are
unsure you understand the stuff.  Add helpful comments to the code
where the existing comments were not enough for you.  Keep going until
that single problem is solved.  Then take another one, preferably in
the same area of Emacs -- now you should feel more at home there, and
things will move quicker.  Rinse, repeat.  It really works.  You just
need to take the first step, then the second, then the third.  One
step at a time.  "Rome wasn't built in a day."

Thanks in advance!