-Users
+### Users
Right now, the best way to contribute to Uzbl is to use it, hang around in
our IRC channel, and tell us when things break. If you're feeling more
a look at the CHECKLIST file to see all the stuff that is supposed to work.
Play around with the configs and scripts and see if you can improve things.
-Developers
+### Developers
If you don't feel like just sending bug reports, by all means dive into the
code and clone the code to start hacking. (github makes this really easy
with their "fork" concept). But it's usually a good thing to tell us first
what you want to do, to avoid unneeded or duplicate work.
+Note that cloning and letting us pull (preferably via github) is way more
+workable then submitting plain patches. Git is good in merging in branches
+even if the base code has changed in the meanwhile. This does not work with
+patches.
+If you're new to Git/github, have no fear:
-VALGRIND PROFILING
-add this to Makefile header: CFLAGS=-g
-recompile
-valgrind --tool=callgrind ./uzbl ....
-kcachegrind callgrind.out.foo
+* [Github guides (highly recommended)](http://github.com/guides/home)
+* [Guides: Fork a project and submit your modifications](http://github.com/guides/fork-a-project-and-submit-your-modifications)
+
+Our convention is to develop in the *experimental* branch, and keep only stable, tested stuff in *master*.
+So ideally, all contributors develop in their experimental, that gets merged into the mainline experimental, and after QA it gets merged into the main master.
+
+
+### VALGRIND PROFILING
+ $ add this to Makefile header: CFLAGS=-g
+ $ recompile
+ $ valgrind --tool=callgrind ./uzbl ....
+ $ kcachegrind callgrind.out.foo
+
+### MEMORY LEAK CHECKING
+ valgrind --tool=memcheck --leak-check=full ./uzbl
+
+### DEBUGGING / BACKTRACES
+
+* compile with -ggdb (enabled by default on experimental tree)
+* run: `gdb ./uzbl`
+* `(gdb) run -c /path/to/config`
+* `bt` if it segfaults to see a backtrace
+* you'll find more info on the interwebs
projects / uzbl-mobile / blobdiff