Conferences

Reorganization

Throughout the summer and fall of 2005 there was ongoing discussion related to Core Team reorganization. Based on the guidelines that had been created when individuals were invited to join the team in the summer of 2004, there was clearly a group of members who had not lived up to their commitments. The list of responsibilities included staying involved in Core Team business through the private discussion forum; participating in weekly Core Team chats; contributing bug fixes, enhancements, or documentation to the core product; and being active in community support channels. There were many legitimate reasons, both personal and business-related, which led to inactivity for team members. However, the unfortunate side effect is that it led to a community perception that based on the total number of Core Team members, we were underachieving in terms of our capabilities as a whole. The Core Team reorganization meant that a number of team members needed to be retired to make way for some new members who had earned the right to participate based on their community accomplishments over the past year. The project had never had to deal with a situation like this in the past, and it's safe to say that as software developers, we are much more adept at solving technical problems than human-resources issues. So the dilemma was how to break the news to the inactive members in a professional and courteous manner that still respected their past accomplishments and left the door open for future participation. It was Scott Willhite who demonstrated the most experience and wisdom in this area, as we worked on establishing effective human resources processes for the organization.

Since the original formation of the Core Team, all members had received equal rights in terms of project participation. This included not only communication channels but also permissions to the product source code repository. This model worked well when the team was small and all members were on equal footing in terms of their technical abilities. However, it proved to be a challenge when the team grew in size and members were added with varying technical backgrounds. DotNetNuke had grown into a mission-critical web application framework that many businesses now relied on for rock solid performance and reliability. We could no longer accept the risk of inexperienced team members checking in code that could compromise the stability of the application. As a result, we needed to re-factor our project roles to reflect the new project requirements.

A common theme that helped drive the re-factoring of the project roles was accountability. In the past, we had witnessed the fact that without accountability, an individual would not exhibit the same level of commitment, dedication, or passion for the project. As a result, it was important to provide Core Team members with areas of accountability where their contributions would be highly visible and easily recognized by the general public. This public aspect provided them with a much greater benefit in terms of visibility in the community, but it also made them a target for criticism if they were inactive because they were personally responsible for specific areas of the project.

Using the Apache Foundation as a meritocracy reference, we made some significant changes to the organizational model of the project. The old "Inner Team" designation was abolished in favor of a new "Core Team Trustee" role. Scott Willhite came up with this new name based on the desire for industry-accepted terminology and the fact that this innermost project role assumed the highest level of trust from a development perspective. Core Team Trustees had multiple years of experience on the project, had successfully demonstrated their technical aptitude, and as a result were granted write access to the core repository. The old "Outer Team" designation was simplified to "Core Team Member" — a role that was able to participate in all Core Team communication channels, but was only provided read access to the source code repository. In addition, we added a role for the DotNetNuke Projects of "Project Team Lead." This role was responsible for managing the project infrastructure and communicating project status to the Core Team.