CSI Development Process

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Development will follow the Drupal.org process with a few changes

General Guidelines

  • All tasks will be on Drupal.org
  • All code will be a patch before it's committed
  • All patches must include tests (See testing methodology)
  • Keep issue summary updated to reflect what the code is * really doing
  • Keep related issue links in the issue summary
  • All functions should have document blocks
    • Summary
    • Purpose
    • How to use it
    • @params
    • @return
  • Use Readme files to talk about how the code fits together
  • Create *.api.php files for full code examples
  • Create a branch for your issue if it is going to be multiple time or patches

Patch Process

This only applies if you are using a seperate branch for development.

  • Create the patches against 7.x-1.x branch.
  • Any futher patches should have both the patch against the 7.x-1.x branch and the patch with the diff of the branch.
  • Name the patches to apply against the 7.x-1.x with *.patch. Name the patches agasing the branch as *.interdiff.
  • The file name difference will help when we turn on automated testing.
  • Once the ticket is complete, set to RTBC assign back to indytechcook to review and merge the branch into the 7.x-1.x branch.

Issue Tags

Use of Tags: http://drupal.org/node/1023102

  • All issues should have an "lsd-csi" tag. This includes any related issue in other projects.
  • Sprint tags: "lsd-csi sprint 1"
  • "lsd-csi blocker" tag used if the issue is completely blocked. Be sure to update the issue summary about why the issue is blocked
  • "lsd-csi community" tag is used for issues which are good candidates for community involvement.
  • Issue summary lists can be made using RSS feeds. Links will be kept on the CSI GDO home page.