Becoming a maintainer

Maintainer is an term by oVirt to identify someone who is committed to a particular project and who has been voted/invited to be part of the core group within the project that ensures the project’s vitality.

One thing that is sometimes hard to understand when you are new to the open development process, is that we value the community in addition to the code. A strong and healthy community will be respectful, productive and rewarding place. Strong code will evolve.

Contributing to a project

The first step in becoming a maintainer is quality contributions to the project. Contributions to oVirt includes the following aspects:

• Community – One must interact with others, and share vision and knowledge
• Vision – A clear vision and consensus is needed
• Documentation – Without it, the stuff remains only in the minds of the authors
• Code – Discussion goes nowhere without code

Once an individual has established a track record of quality contributions to oVirt over a period of time, they are well on the way to maintainer-ship.

Working toward maintainer-ship

A maintainer is voted onto a project based on substantial contribution to, understanding of, and duration of the commitment to the project.

The current set of maintainers vote additional maintainers onto the project. If the project has less than 3 maintainers the vote is ratified by the oVirt board. Maintainers can be voted onto the project at any time.

oVirt does not require code contribution to become maintainer, documentation, community work (such as web work, build systems, running events, release management), or any devoted and valuable activity is counted when someone is considered to be voted into the project or board (More on joining the board here). Anyone who is supportive of the community and works in any contributing areas is a likely candidate for maintainership. oVirt is a meritocracy. That is, once someone has contributed sufficiently to any area they can be voted in as a maintainer. Being a maintainer does not mean you only commit code, it means you are committed to the project.

It is expected that if you earned your maintainership by submitting documentation for example, that you don’t ack patches until you have also earned your stripes in that regard. The general rule is to defer to an ‘expert’ in an area until you become one. It is possible to be voted into one project and not another based on your areas of influence.

One of the key contributions people can make to the community is through the support of a wide user base by assisting users on the user list, writing user oriented docs and ensuring the user viewpoint is understood by all developers. A main idea behind being a maintainer is the ability to be a mentor and to work cooperatively with your peers.

Responsibilities

Working in oVirt projects should be rewarding. As an oVirt maintainer, as a developer, you do as much work as you can. You do not need to participate in every discussion, just because it concerns the project. Neither do you need to participate in every vote or in every development issue. We like people to be involved and we reward contributions (meritocracy), but we do not punish a lack of contributions. Peoples contribution level changes as their needs change and we adapt to those changes.

You do however have a responsibility as a maintainer to consider “what is the best/right thing the project?” in your actions voting and development of the project.

Adding to the discussions and contributing code

Discussion leads to a clearer community understanding of the project’s goals and objectives and also of how the community works.

Of course, there needs to be a balance between too much chat and not enough code. If something is easy to do in code and does not impact the overall product (such as a bug fix) then just go ahead and do it. However, if something is to introduce a new feature, then it is best to introduce your idea to the community via an email to the dev mail list first. In this introduction you should outline why you want to do something, how you propose to do it and ask for comments. Any comments received will help to fine tune the design and, in many cases, produce a quicker, more elegant solution (this is the benefit of many eyes on a solution).

The absence of comments from others does not mean it is not a good idea, in fact the reverse is true, it means nobody has any objection or anything to add. It is only if people respond that you need to discuss further. Once the discussion reaches consensus then coding can accelerate. Once you have implicit or explicit approval for your contribution, just go ahead and do it. Be sure to document what you have done whilst you are at it.

Online discussion is important for community building. Offline discussion and one-to-one conversations deny the community the chance to become involved and lead to solutions that are not ideal. So please do as much discussion as possible on the devel or user mailing list.

It is good practice to post any relevant IRC/IM etc conversations on a topic back to the mailing list. Just cut/paste the relevant section.

Large projects

Once a project is well established and has a diverse maintainer base it may publish more detailed criteria for becoming a maintainer. The idea behind this is that certain attributes may be more valuable to some projects that to others. For example the webadmin and api projects may value documentation where as the VDSM may value hardware enablement and understanding of API compatibility more or to be become a maintainer you need to demonstrate that you know what it takes to not break ABI. This also allows for projects that are diverse and established to create there own cultures.