Difference between revisions of "Getting Started"

From GeeklogWiki
Jump to: navigation, search
(Nightly tarball now includes the PEAR classes)
m (added link to inspiration :))
Line 13: Line 13:
  
 
== Dive into it ==
 
== Dive into it ==
 +
 +
''(trying to paraphrase [http://groups.google.com/group/google-summer-of-code-discuss/msg/630ba342ab440c27 this post] by Eric Weddington)''
  
 
Once you have a rough idea how things work, try browsing our [http://project.geeklog.net/tracking/view_all_bug_page.php bugtracker]. Pick a bug that interests you. Try to reproduce it. If you can add any useful information to the bug (e.g. steps to reproduce the problem), go ahead and leave a comment.
 
Once you have a rough idea how things work, try browsing our [http://project.geeklog.net/tracking/view_all_bug_page.php bugtracker]. Pick a bug that interests you. Try to reproduce it. If you can add any useful information to the bug (e.g. steps to reproduce the problem), go ahead and leave a comment.

Revision as of 20:20, 7 March 2009

So you want to help out with Geeklog development? Excellent! Here are the first steps to get you started:

First Steps

If you haven't already done so, download and install the current stable version. This will give you an idea how things are supposed to work.

Next, try the development version. You can either use Mercurial or download the nightly tarball. If you're checking out from the Mercurial repository, you also need the PEAR classes. These classes are already included in the nightly tarball. (more detailed instructions here)

Once you got the development version up and running, you should read Alan McKay's excellent Beginner's Guide to Geeklog Programming, which will explain to you how to do things the Geeklog way.

We also recommend you have a look at our Coding Guidelines. Summary for the impatient: We're mostly following the PEAR coding standards.


Dive into it

(trying to paraphrase this post by Eric Weddington)

Once you have a rough idea how things work, try browsing our bugtracker. Pick a bug that interests you. Try to reproduce it. If you can add any useful information to the bug (e.g. steps to reproduce the problem), go ahead and leave a comment.

See if you can find the area in the source code where the problem occurs. Try to think of a way to fix it and either fix it (patches are always welcome!) or, again, leave a comment.

Don't worry, not all the open bugs are hard. Some are fairly easy and are only open because nobody had a chance to fix them yet. Even if you can't solve the problem, you'll learn a lot in the process.

(to be continued ...)