As one of four core tenets of OpenStack’s open mantra, an “Open Community” is a critical and required component of an OpenStack project. Open communities enable an open development environment, and are a key component of a successful open source project. An OpenStack project should follow this model to ensure its success and growth in the OpenStack ecosystem.
OpenStack projects are required to have team meetings on the Freenode IRC network in one of the publicly logged team meeting channels managed by the OpenStack infrastructure team. As part of working in an open community, the logging of meetings allows those who cannot participate at the meeting’s designated time to read the logs and participate asynchronously.
Worth noting is the fact the OpenStack infrastructure team maintains a limited number of meeting channels. The reason for this limitation is to force teams to spread their meetings around. This allows for participation by people all around the globe. It also allows people to attend multiple meetings where otherwise they may have a conflict if we had a larger number of channels and most meetings took similar timeslots.
To schedule a team meeting, please go to the eavesdrop site and follow the instructions there. All meeting reservations are managed through gerrit in the IRC meetings repository.
OpenStack projects may have a team IRC channel on Freenode. These channels should be logged, in keeping with the open community aspects of OpenStack. Project teams typically congregate in their IRC channels to discuss the project and build a sense of community amongst members. If a new project doesn’t yet have critical mass, the channel #openstack-dev on Freenode is available to use until such time as the project team decides to create their own channel.
Given the fact open source in general, and OpenStack in particular, are global communities, IRC is a great way for the geographically disparate teams to work together. Usage of IRC proxies (or bouncers) allow team members to access messages that were sent while they are disconnected.
OpenStack makes use of mailing lists for communication. Much like IRC, mailing lists are used to allow geographically distributed teams to communicate and share information, in this case asynchronously. In addition to team communication, mailing lists also provide an interaction point for cross-project communication. If an idea needs to span projects, the mailing lists is a great place for this to happen. And finally, mailing lists are used to interact with non-developer community members of OpenStack.
When using the mailing list for team communication, it’s best to tag the subject with the name of the project surrounded by brackets. For example, to communicate something to the mailing list about Nova, you would add this to the subject:
[nova]
There are many mailing lists in the OpenStack ecosystem. Projects should ensure they have subscribers on all of the lists relevant to their project.
Note that communications on OpenStack mailing-lists follow basic mailing-list etiquette rules. Getting familiar with those will make sure your messages will have the desired impact.
As a project in the OpenStack ecosystem, you will inevitably field requests for support from users of your software. These can come in the following ways:
A project must be prepared to provide best effort support for these types of requests. Recommended courses of action include:
Planet OpenStack is a collection of thoughts from developers and other key players in the OpenStack project ecosystem. If your project contains active bloggers, it’s a good idea to make sure their blogs are listed here. This is a nice way to provide an avenue of communication for developers in your project to share their thoughts and ideas around the work they are doing throughout the cycle.
To list your blog in the Planet OpenStack aggregator, follow the steps outlined on the wiki for adding your blog.
All OpenStack technical leadership positions are elected. There are two types of elected technical positions in OpenStack:
The project team guide naturally focuses on PTLs. More information about the TC can be found on the Technical Committee website. Each project team in OpenStack needs a PTL. The PTL is an elected leader who has final say over all things in that specific project team, and all the code repositories in it. The PTL typically leads the day to day operations of the project, and acts as a default ambassador of the project team in communications with other teams. The PTL is expected to have sufficient time available to dedicate to running the project. Responsibilities of the PTL include the following tasks:
The PTL for each project team is elected on a 6-month term. Thus, the project will have an election every 6 months to determine the leader of the project for the upcoming 6-month cycle.
Projects without any nominated PTL candidates during a specified period will be considered leaderless and default to the technical committee for decision.
The electorate for elections (both PTL and TC) are the active contributors to a project or projects. If your project is a git repository and all active contributors submit patches to gerrit, their work will be automatically acknowledged for elections. Should you have any contributors who support your project in a way not reflected in gerrit, edit the extra-atcs file in the openstack/governance repo.
OpenStack uses a Condorcet voting system for all Technical elections. This includes both the TC as well as PTL positions. The elections are run by a trusted team of election officials from the community who make election announcements throughout the process, set up the election tooling and oversee candidate and voter eligibility.
Condorcet may result in ties, which should be broken in a fair and reproducible manner. To this end, OpenStack uses the hash of a string describing the tie results in a seed in a random generator to determine the tie winners. This way anyone may verify the fairness of the tie break. For more details, see the wiki page on tie breaking.
The Technical Committee charter defines the rules for the election schedule. Dates are generally based on the release cycle (for PTL elections) and summit dates (for the TC elections).