Package Maintainer Teams

What is a Package Maintainer Team?

Created by: Stephan Borg, Last modification: 12 Jun 2005 (23:50 UTC)

What is a Package Maintainer Team?

As with the architecture described in bitweaverPackage, each individual feature is kept within a Package. To ensure high quality standards, I believe we require teams of dedicated people who have a common invested interest in a package, to take on roles of Package Maintainers. Ideally, there should be a minimum of 3 team members for backup and support.

You don't necessarily have to be a developer to be a Package Maintainer. Some of the important functions of package maintainence are quality control, user support, future direction and tutorials. User and developer documentation is equally important, but these other functions are often overlooked.

What does the role involve?

Take a look at System Development Life Cycle - SDLC to gain an understanding of the overall process. This methodology could be applied on a per package basis and developed autonomously to the core project. I believe that by following these processes, our efforts would be a lot more focused and effective, instead of the current competing requirements of team resources.

There are a number of roles within the team, shared between members.

Steering Committee

Future direction from a user and technical perspective are required for a goal-oriented process. As a member of the Package Maintainer team, you would have strong input and be across issues with implementing future aspects of the package.

Investigation of Third Party Library and Project code would be carried out here in an effort to improve the efficiency of the package.

Key Users

If your a user and you've invested your reputation on a package, this is the role for you! I'm sure you can help with something else, but for future direction, key issues, user acceptance testing, functional requirements, and deliverable expections are all part of this role.

Creation of user acceptance procedures that ensure everything that should work does, is critical here to ensure that a quality product is always released.


User manuals and tutorials are the focus here. There maybe requirements for Technical training if the package is complex. Most of the documented specification work by Steering and Key Users, would be formatted and form a basis of the documentation, making this job a little easier.

Quality Assurance

Application Automated testing of Classes, interfaces and package functionaltiy is the role here.

There are two objectives of this role.
One is to standardise API's so that Technical Documentation and future developers are able begin with minimal effort. As Quality Assurance, the role here is to keep the interface and class code segregated (see CodingGuidelines), standardising the API and creating test suites (see TestingSuites).

Two, you will help the overall effort of development if you can ensure package functionality works from the lowest API levels, ensuring smoother user acceptance testing and final release. Prototyping tests using StubsAndMockObects is a useful method to ensure correct functionality.


Apart from coding, there will come a time when you will require policies for Change Control and use Third Party Library and Project code dependencies. Along with Key Users, you should tentatively plan project milestones (keeping in mind that this is a volunteer project) to provide guidelines of release.

Development of user interfaces and class code should be as segregated as possible (see ObjectOrientation and Model View Controller - MVC) to enable stable independent API interfaces and functionality coding.


This is a mix of roles, most likely not performed by a single person but as a team. Requirements of bug fixes and their criticality is important here, along with upgrade/migration paths and post-production support, performance and package assessment. Also scheduled improvements can be prepared using mini-SDLC's.