[webkit-help] How to get help effectively

Ariya Hidayat ariya.hidayat at gmail.com
Wed Aug 19 08:18:46 PDT 2009

The following tips are for the new members of this list who want to
get help on learning WebKit code base. Feel free to chime in and add
more suggestions.

(1) Search the archive before you ask a question. Who knows a similar
question might be asked before and there was a lead to the answer.
Search both webkit-help (this new list) and webkit-dev (the
development list) using Google.
Example: to find information about 'RenderLayer':

(2) Specify as detailed as possible your system configurations, e.g.
32-bit or 64-bit, which operating system, which compiler, what kind of
CPU, etc etc. If you have a build problem, tell us also which port are
you trying to build (Apple, Win, Gtk, Qt, etc etc). Remember, often we
lose our crystal ball and therefore we can not just deduce your
problems from a very little information.

(3) For a compile or build problem, paste the complete error message,
don't just say "It does not work". If the message is very log
(hundreds of lines), do not paste it in the email. Instead, use
http://pastebin.com/ and include the link in the email.

(4) If you ask 'Does WebKit support Foo?', the most reliable way to
answer it is by looking at the source code. WebKit development is fast
pace, often the asked feature is already implemented although it has
not been widely used yet. Bear in mind, sometimes the level of
supports between different ports are not the same (example: Apple port
has implemented feature X, but Qt port still does not have it).
The following links are also useful (note that they may be incorrect
or outdated):

(5) Want to port WebKit to a new platform? Check first
http://trac.webkit.org/wiki/SuccessfulPortHowTo. Granted, it's not
complete, feel free to contribute. Also, try to find a port similar to
what you are targeting and use it as a basis, instead of writing
everything from scratch.

(6) There are many reasons why a debugger exists. One of them is to
allow you to set a break point somewhere in the source code and see
the stack trace. So if you ask yourself a question like 'How does
WebKit tokenize HTML?', the fastest and educational way to answer this
is to launch your debugger and put some breakpoints in some functions
in the HTML Tokenizer class. From there, you can see who calls the
function along with the program flow.

Something less technical but also related:

(1) We offer our help on a voluntary basis, you can't expect us to be
100% at your disposal. Be patient, no need to insist on the "urgency"
or something similar. We are not in the kindergarten anymore,
screaming does not make the solution appears faster.

(2) We love to grow our community, and thus we like to help the
beginners. Afterall, every expert was a beginner at some point in his
lifetime. However, nobody likes *lazy* beginners. Thus, if you face a
problem, try to analyze and solve it yourself first *before* asking
for help.

(3) WebKit is a big project with a huge code base, you must be willing
to spend your time and effort on learning the source code. Remember,
you can not become a Grand Master just by skimming some chess learning
book (unless you are Chuck Norris).

Last but least: there are often (negative) complaints that WebKit code
is not easy to understand. Well, this is your chance to contribute! I
have started some helping pages on this, just check out:

Do not hesitate to fill the wiki with new information which will help
others to learn!

Ariya Hidayat, Code Monkey

More information about the webkit-help mailing list