In no particular order, here are some hints/tips to help introduce a new Committer to the DSpace Development process:

Committer Mailing Lists

• dspace-commit : As a new committer, you will be added to the private 'dspace-commit' listserv. We try to only use this 'dspace-commit' list for administrative duties or official nominations/votes for committership, etc. Developer topics occasionally come up here as well, but once they begin to move beyond "administrative" we try to move them to 'dspace-devel' so the entire DSpace Developer Community has input.
• dspace-changelog : If you are not already aware of it, we have a public 'dspace-changelog' email list which just reports recent commits to SVN. You should probably join that list, as it is your friend: http://lists.sourceforge.net/lists/listinfo/dspace-changelog

SVN "Crash Course"

Regarding commits to SVN:

• As a new Committer, you obviously have full rights to commit code. Usually, we try to not commit major code to DSpace that has not be reviewed by others (by posting a patch to JIRA for review). But, obviously minor bug fixes/typos can just be fixed – there's no need to review things that are obvious.
• Please review to the Guidelines for Committing for additional hints/tips on our normal commit process.

There are actually several areas of SVN (in case you haven't browsed around it much). Here's a very brief overview of the main areas available off of http://scm.dspace.org/svn/repo/

repo/
    dspace/
          trunk/  (absolute latest DSpace code -- this is where development for the *next* major version of DSpace happens)
          branches/
               dspace-1_6_x/ (latest 1.6.x code -- once a new major version is released, all minor/bug-fix versions are developed out of its branch)
          tags/ (this is where official releases of the software are tagged, e.g. 1.6.0, 1.6.1, 1.6.2, etc.)
    dspace2/  (This is the DSpace 2.0 prototype from 2009)
    modules/  (Various Maven-enabled DSpace modules for both 1.x and 2.x)
    sandbox/  (A sandbox where anyone can work on prototypes of DSpace changes/features)
    tools/    (Maven management/assembly tools)

More information on the SVN hierarchy is also available off of our Modules wiki page.

You can create your own prototypes in 'sandbox' if you are working on something for DSpace and it needs a home (it's a place to play around, so feel free to commit whatever you need to there). You can also create you own DSpace Maven modules in 'modules'. Generally though, most of the "official" work goes on under 'dspace' (with the exception of a few 'modules' which are actually distributed out-of-the-box).

Also, 'dspace/branches' are generally used for bug fix releases (e.g. 1.6.1, 1.6.2, etc.). The 'dspace/trunk' is generally used for the next major release (e.g. 1.7, 1.8, etc.). Obviously, if something is a 1.6.0 bug fix, it should be committed both to 'branches/dspace-1_6_x/' and to 'trunk' so that the bug is fixed for both 1.6.1 and 1.7.

IRC Overview

• If you can, try to join our DSpace Developer Meetings in #duraspace IRC. It's a good way to stay "in the loop". It's also a good way to get to know everyone. If you cannot make the meeting, transcripts are also available on the above wiki page and off of http://www.duraspace.org/irclogs/.

• You are also very welcome to pop into #dspace IRC anytime – most workdays many of us can be found there. Usually, it's live Q&A there, but occasionally we have ad hoc discussions. You'll probably see us joking around as well – we try to keep it relaxed and fun.

Questions / Issues

• If you have questions – definitely feel free to ask. We are a very friendly group. Although there is the occasional disagreement, no one gets offended, and I think we always end up with a friendly resolution.

• If you are trying to do something with anything related to DSpace (SVN, JIRA, etc.) and you cannot figure it out or it isn't working, let us know! Chances are we forgot to give you some permissions that you need to have (or something is broken).

• Similarly, if you really aren't sure about an "official policy on ____" or have questions on Committership in general, please ask. In most cases, either there is no "official policy" (but there may be guidelines), or we forgot to document it. Either way, it's helpful to point it out to us, so that we can avoid confusing new committers in the future!

• In the end, it comes down to three things:
  1. Have fun! Really – no need to take it too seriously.
  2. We don't really have any strict "rules", just occasional "guidelines"
  3. Ask questions if things are not clear – any of us are glad to help.