Skip to posts
  • About the Project
  • Welcome
spacer Real Project Management for Real Businesses
  • Home
  • Development Blog
  • Demo
  • Screenshots
  • Download
    • Current Release
    • Release Notes
    • Nightly Snapshots
  • Documentation
    • Wiki
    • API Docs
    • Ohloh Stats
  • Training Videos
  • Support
    • Forums
    • Issue Tracker
    • FAQ
  • FAQ

About the Project

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, a mailing list, GitHub, and Sourceforge – 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 forums and help plot the course?

Recent Posts

  • Microsoft’s SQL Server Jumpin Camp 2011
  • web2project at php|tek 2011
  • Why you shouldn’t use web2project
  • v2.3 Release Notes
  • Meet Us at php|tek 2011

Common Topics

Add On Module API archived audits Brazilian Portugese code review code reviews customization Demo deprecation warnings Development differences Documentation dotProject Gantt charts history iCalendar Javascript minification licensing namespaces news object validation Packaging permissions phpUnit php|tek projects project status refactoring Releases roles Security site updates subprojects Support timezones todos translations Trevor Morse Unit Testing update checker Updates users validations views helpers

Project Stats

spacer Project Management Blog

  • Projects vs operational work - How do companies organise to be 'best' at both?
  • How to write a good product requirements document.
  • Mothers Make Natural Project Managers: Part 1
  • How to build a Project Management Office
  • The Second Key to running Successful Improvement Projects: Senior Sponsor Support
spacer © 2012 web2Project Design by SRS Solutions

spacer
spacer