Aegir Maintainers

The Aegir maintainers are committers that have access to the code. They are responsible for specific parts of the project and are general go-to people for various things.

  • vertice - project founder, retired
  • anarcat - release engineering, debian packaging, crazy late night coding splurges, general goto guy for everything
  • mig5 - testing, release engineering, migressions and general bugfixing
  • Steven Jones - documentation, queueing and contexts stuff
  • tbosviel - DNS support

Other contributors

Those people have given significant contributions to the project but do not yet have complete commit access.

All contributors of Aegir's history can be found on Ohloh.net's contributors page although that doesn't count patches that were sent in the Drupal.org issue queues.

Aegir Co-maintainer Criteria

The Aegir core team is somewhat selective about inviting co-maintainers. This is largely due to the complexity of the project, and the crucial functionality it plays for many of its users.

Below we detail the responsibilities of co-maintainership (apart from just commit rights to git), as well as what criteria we feel are important for new team members. Co-maintainership involves taking responsibility for the project's overall well-being. This includes:

  • Participation in the community: issue queues, IRC, community site, etc.
  • Technical involvement: bug-fixing, patch testing, new feature development and roadmap/architecture planning, release engineering, etc.
  • Maintenance of project infrastructure: debian repos, community and API sites, Jenkins, etc.
  • Community outreach: presentations and BoFs at Camps and Cons, blogging, screencasts, etc.

While this isn't an exhaustive list, nor are all these activities required for membership in the core team. We're looking for new team members with regular, productive activity in one or more of the above domains. This essentially boils down to two criteria:

  • code/patches submissions (quality over quantity) and
  • demonstrated interest in the project.

If you believe that you'd make a good addition to the core team, don't hesitate to contact any of us to discuss it.

Aegir Project Leadership

With the recent transfer of leadership, the project's core team has decided to move towards a more democratic model, to ensure clearer structure and smoother transitions in the future. Debian is a shining example of this (in particular, the DPL), and so we will model our leadership position(s) after them.

The Aegir Project Leader (APL) is the official representative of the Aegir Project. They have two main functions, one internal and one external.

In the external function, the Project Leader represents the Aegir Project to others. This involves giving talks and presentations about Aegir and attending trade shows, as well as building good relationships with other organizations and companies.

Internally, the Project Leader manages the project and defines its vision. They should talk to other Aegir developers, especially to active contributors to Aegir core, to see how they can assist their work. A main task of the Project Leader therefore involves coordination and communication.

Obviously, we're a much smaller project than Debian, and so we're adopting a pretty minimalist organizational structure. That said, Debian has many other structures in place to ensure the ongoing health of a large community driven project. As the Aegir Project grows, we can appropriate additional tools to overcome any new challenges that arise.

Finally, the responsibilities inherent in the APL role are not exclusive to it. That is, just because it is the Project Leader's job to give presentations and coordinate our efforts, other community members should not hesitate to continue doing so themselves.

How to welcome someone to the core team

Once someone is deemed worthy of joining the core team, you (a core member) should make a proposal on the core mailing list to welcome the new developer. Subject should clearly state the proposal and give ample time for other developers to chime in. Usually all core team members should give their explicit approval as we try to reach consensus (and usually do) over proposals.

Once the member is approved on the mailing list, you should follow this checklist: