Getting Involved

  1. Getting Involved
    1. Getting the Source
    2. Contributing
      1. Tickets
        1. Creating Tickets
      2. Posting Patches
    3. Commit Access
      1. Getting Commit Access

So you want to help with Cocode? Fantastic!

The center for Cocode development is this Trac installation. If you're not familiar with Trac, trust me when I say it's an amazing tool that integrates  Bugzilla-like bugs--called "tickets" here--with a wiki and  ViewVC-like repository browser, with some extra features for fun and profit.

Getting the Source

To grab the current source for Cocode, you'll want to check it out of  Subversion: 

svn co svn://jamessocol.com/cocode/trunk cocode/

Then follow the instructions to InstallCocode and get your copy up and running.

Contributing

So you've added a great new feature to your local Cocode, or fixed one of the tickets, and you want to contribute that back to the project. Wonderful, that's how open source projects work.

But what do you do with it? First you should create an account here on Trac. Since this is the center of Cocode development, it's important. Second, you should search to see if there's already a ticket.

Tickets

The first few revisions are pretty bad about this, but in general, each patch should correspond to exactly one ticket.

There are three types of tickets: enhancements, defects, and tasks. Enhancements are new features or tweaks to make something better even if it's not broken; defects are things that are not behaving as intended, expected, or required--for example, a new feature in the next milestone that isn't there yet; tasks involve doing something that isn't really broken or an enhancement, like refactoring a section of code, or updating some wiki pages.

Creating Tickets

If you find a bug in Cocode, file a ticket, please. Things like steps to reproduce, expected vs. actual behavior, and relevant settings are helpful. Bugs will usually be assigned to one of the next couple of milestones. Security bugs are worth creating a new milestone.

If you want a new feature, check the WishList? and/or the Roadmap first. Features are usually tied to 1.0 or 0.1 milestones (ie, new versions or major revisions). If the feature is accepted, a tracker ticket targeted to that milestone will probably be created.

Posting Patches

Now that there's a ticket for your issue, you're ready to post a patch. The preferred format for patches is the  unified diff format. SVN can do this for you: 

svn diff >> mypatch.diff

Make sure that only changes relating to the ticket are included in the diff, then add it to the ticket as an attachment. Add the haspatch keyword. Someone with commit access will test the patch and commit it.

Commit Access

Right now, I'll probably be fairly liberal with granting commit access. If things change, you'll probably be expected to have contributed a few patches first.

Development is on /trunk and in /branches. Tags are created for releases and should not be modified.

If you have commit access, you're basically free to commit. Still, try to limit commits so that any one revision addresses a single ticket. Seriously, have lots of working copies.

Getting Commit Access

Register, submit some patches, we'll talk. (If I've seen your code before you can probably skip the patches step.)