Software Development Practices

From ClioWeb Wiki

Some points to discuss for One Week | One Tool. A somewhat disorganized list of things I've learned in managing Omeka development.

Contents 1 Points to keep in mind 2 Approaches 3 Tools to use 4 Topics

Points to keep in mind

• Stay organized
• Create and maintain internal best practices
• Have a direction/scope/milestones.
• Scope should be as detailed as possible, written down, shared.
• Encourage knowledge sharing among team; No single person owns the code.
• All decisions have ramifications for end users. Always detail those ramifications before making final decisions.

Approaches

• Agile development
  • Extreme Programming
  • Test-Driven Development
• Waterfall development
• Cowboy Coding

Tools to use

• Version control system
  • Types: SVN, Git, Mercurial
• Issue Tracking
  • Trac
  • Redmine
  • GitHub
  • Google Code
• Documentation
  • Wiki
  • PHPDoc
• Testing
  • PHP Unit
  • Selenium
  • Infomaki

Topics

• How to prioritize work?
  • We have a system for assigning levels to tickets on the Omeka trac.
    • New features are almost never "blocker" tickets.

• Issue tracking software seems much better that other task management (Basecamp, to-do lists).
  • Use wiki for documentation, meeting notes
    • Example: ExhibitBuilder page on the Omeka Addons Trac.
    • Example: Changelog for Omeka 1.2 on the Omeka Trac.
  • Use tickets to report issues, or request new features
    • Be as explicit in ticket descriptions as possible
    • have conversations about tickets in the comments section.
    • When changing tickets, justify change in comments.
    • When reporting an bug, should try to also add a test that helps replicate the bug, and/or add a patch that fixes the bug.
      • Example: Ticket #929 on the Omeka Trac.

• Create and maintain internal best practices
  • Example: Development Process notes on the Omeka Trac.
  • Example: Meeting Goals on the DevTeamMeetings page on the Omeka Trac.

• Defining features

• Knowledge sharing among team
  • Having only one person know, or be responsible for, all the code is dangerous.
  • Weekly meetings, where developers discuss current projects, issues they're running into.
  • Review commits.
  • Share patches on specific tickets, review those
  • Code review with at least one other person.

• Version numbers
  • Omeka Version Numbers

• Software Licenses