In ancient times (also known as 2007), Pedro Azevedo, Bruce Bodger, and Keith Casey were members of the dotProject team. For a variety of reasons ranging from the mundane to the fundamental, Pedro began to strike out on his own. In a matter of days, he realized that he needed more stress in his life, so he recruited Bruce and Keith to join up in the effort. Fast forward a few months and the forked dotProject code – now known as web2project – began to take shape.

At that point, we set some priorities for the project:

• Regular and predictable releases are vital to the health of the community, we should have at least two each year;
• Bugs and feature requests should be reviewed, evaluated, and prioritized regularly;
• Frequently Asked Questions should be considered indicators on where we should simplify or clarify the system;
• The community should be open with clear expectations for behavior while encouraging constructive criticism; and
  
• Features and functionality should be driven primarily by input and involvement from the community.

The first changes (v0.9.7) were a new look and feel, some major cleanup to the underlying database configuration, and a permissions caching system for better performance. The following year saw fits and starts in development and we stalled at v0.9.9 for a few months. Then in 2009, something happened and everything began to move. By April our v1.0 Release Candidate was live. By June 2009, v1.0 was released.

Towards our statement of purpose, we took a number of steps:

• We have committed to a regular and predictable release cycle – we make a Major Release each year (June) and a Minor Release each quarter [1];
• Every bug is reviewed, triaged, and categorized according to its own criticality, its dependencies, and the current release [2];
• We have a formal policy and procedure on how community members are evaluated for possible team membership and the expectations that follow;
• Every commit is available in a variety of places – forums, GitHub, and we actively encourage Code Reviews to get feedback, criticism, and insight that we may not have/discover by ourselves.

Just prior to the v1.0 release, Keith met Trevor Morse  at php|tek 2009. Trevor made the mistake of singing the glories of Unit Testing large legacy codebases and – within a month – wrote a simple testing setup and over 40 tests of varying complexity. In the following month, he shared more and more with the team and just a few weeks later, Trevor had earned his spot on the team. To date the Unit Testing effort has discovered and eliminated numerous oddities and bugs in hidden dark corners while improving the overall stability.

So where are we going next?

Our Project Roadmap is going live this quarter, but why not join the support forums and help plot the course?