Skip to content
Hubert Chen edited this page Aug 24, 2015 · 5 revisions

Keeping the Project Manageable

Statistics

As of July 2015 this V²Configurator is:

  • over 1000 man hours
  • about 4000 lines of code
  • 4 contributors, now expanding to 6
  • Over 40 Articles on documentation (if you include the learning GitHub Articles)
  • Over 100 custom visuals (product specific to ViCase)

Frequent rewrites

For both the Code-Base and the Documentation we practice frequent rewrites / refactoring to Keep it small and simple.

Eating our own dog food

Wikipedia►Eating your own dog food. We are using the V²Configurator ourselves, even during the development phase. As such we experience bugs and shortcomings directly and are most motivated to fix them ASAP. It also makes us reasonably competent in terms of feature selection.

GitHub Pages as Test Platform

Before we using GitHub Pages it was very complicated to set up a Test Platform for the V²Configurator. Now you can set up the Test Platform literally under 5 minutes, presuming you have a GitHub account. → Hello World in under 5 min

Reusable code

Standardized Parts Data Structure

Benefits: It makes everything easy: Short and reusable code, short documentation, fast implementation, fast learning.

How to: All configurator data is in one folder on the server. Every part has a corresponding parts folder in the configurator folder. Each part in the configurator has 6 (foldaway) standard elements: ( 1. Comparison Table | 2. Advice | 3. Gallery | 4. Your Choice | 5. Datasheet | 6. Interfaces ). Each element has again its corresponding folder within the corresponding parts folder. In the most simple implementation, this folder contains the HTML content as .html file. It will be simply included in the configurator in the right place. The parts folder can contain supporting files, such as visuals.

Divide and Conquer

This is the philosophy to keep this project manageable:

  • Development in Releases
  • Revision Control in GitHub
  • Easy Contribution Workflow
  • Clean separation of Code and Data

Project Management

Management in Trello Board

The bulk of the Project Management is don on this Trello Board:

Concepts

  • Working from left to right. We close projects first on left side columns
  • Projects are grouped in columns
  • First Trello Card in Column explains what this columns is about
  • One Project is one Trello Card. If all tasks are completed it shows by green ticker sticker
  • Versions: Each Version has its own column
  • Trello Board is public, anyone can see, but only registered team members can edit

Flag Colors

  • Red: Urgent
  • Orange: Working on
  • Blue: Scheduled for next work

Management in Issues on GitHub

Benefits of using Issues on GitHub

  • When closing an issue it is easy to link to commit that is closing it
  • No need to have an additional Trello Account
  • Simpler system to filter cards (issues) than Trello

We may move all Management to Issues only

Motivation is that one Management system provides a more consolidated view and less learning curve than two systems. We use Trello also for documentation, but actually the Wiki of GitHub does a better job at that too! We are now experiencing to use the Issue System for management and will see how this goes.

Reference

Clone this wiki locally