Submitting for commit rights to cloud-init

As the community expands we have an identified process for earning commit rights to the cloud-init source repository. It is not a requirement to be a Canonical employee.


Applicants will build a public discourse post, using the template below, addressing the questions and requests for information. Once the applicant is ready for a formal review an they will remove the “Draft” status of the post and the application will be open for voting from the pool of existing committers to the cloud-init project for a 14 day time period. to review and provide feedback with a majority vote on granting commit access to the applicant. Once a majority of existing committers +1 in the discourse thread the applicant will be granted commit rights to the cloud-init project.

If the applicant is not able to achieve affirmative votes in the 14 day time period from the majority of current committers then the voting body will provide feedback to the applicant and encourage them to improve their application and try again in the future.

Applicant Template

Who I am

Tell us a bit about yourself.

How I came to work on cloud-init

Tell us how and when you got involved, what you liked working on, and what you could probably do better.

My involvement

Examples of my work / Things I’m proud of

*Include links to pull requests, reviews you’ve performed on other developers pull requests, discussions in the mailing list or discourse, and any other contributions you think help accurately represent your work in cloud-init.

Areas of work

Let us know what you worked on, with which development teams / developers with whom you cooperated, and how it worked out.

Things I could do better

No one is perfect or has mastered all of cloud-init, please be thoughtful about your own areas of improvement and how the community can help you progress in those areas.

Plans for the future

What do you plan on working on and doing to improve cloud-init if you were to receive commit rights. Do you have a roadmap or ideas for the future for things you’d like to see advance?


What I like least in cloud-init

Please describe what you like least in cloud-init and what thoughts do you have about fixing it.

Endorsements (1-3 endorsements required)

As a sponsor, just copy the template below, fill it out and post it as a reply to the applicants application thread.

Endorsers TEMPLATE

Endorsers Feedback

Please fill us in on your shared experience. Notable pull requests, improvements to the project, documentation, or special expertise brought to bear

Specific Experiences of working together

Please add good examples of your work together, but also cases that could have handled better.

Areas of Improvement

Please note specific areas that the application can continue to improve and watch out for going forward

What reviewers are looking for

  • a continued history of work (6 months?)
  • breadth of codebase
  • breadth of types of work
    • tests and their quality in both functional and unit test types
    • documentation
    • PRs
    • QA, release assistance
    • reviews of PRs, not their own and not only in their special focus of the codebase
  • Endorsements from the Ubuntu process
    • 1-3 endorsements in your application from existing committers
  • demonstrates an understanding of limits of knowledge and shows a reach out to others when appropriate.

Note: Cribbed a ton from

Admins of the repository reserve the right to adjust commit rights as is deemed important to protect the project.

1 Like

my background are FLOSS communities where existing members suggest active members of the community as committers

while not perfect, given its roots in “meritocracy”, it’s a good way to suggest people who otherwise may not step forward themselves.

do you see such a route within your proposal?

1 Like

I feel that the cloud-init community is small enough to know most of usual contributors. I always thought the FLOSS meritocracy could be measured with git log, but I understand that things have changed over the years and discussions and reviews also counts sometimes as much as a commit.

I think this initiative might be a good start, the template doc looks good. My only concern is how this choice will be made. During community meetings? Open Google Meet interviews/discussions?

I think that the endorser pattern here helps with that a little bit. You get active members being nudged to apply, help with their application, and encouraging them to look at the requirements to fill in any gaps they might yet have. It has a bit of that sponsorship pattern available.

This is my opinion and experience but I find that there’s value in someone wanting to have something vs just given it. There is a certain amount of responsibility to this and I’d prefer folks were looking for that vs handing it out because there’s some weight there that committers will be asked to help guide and work with others more than another contributor.

Does that make sense or do you feel this is something that won’t work to encourage as much?


I’ve left this open for the moment. I’m open to feedback from the folks that would be asked to do the review work. My first instinct is that a Google Meet or other real-time method would be good to help encourage a conversation and provide the oppertunity to address or respond to questions that might come up.

That is a big commitment though and isn’t as friendly to various time zones and such. In that light the discussions could happen in the open in the discourse post of the applicant? Or over IRC or the like.

I think if the person is committed to commit (pun intended) it could work :slight_smile: I think actively applying to something might be better than getting voted for.

1 Like

Thanks for putting this together, Rick! I think this looks like both a good process, and a good template for the process.

Based on observing the DMB, I think we may want a little more clarity around the voting. In particular, I think we need to explicitly define who will vote (I assume cloud-init committers?) and we should define the required quorum: does every committer need to vote for the vote to be valid, or do we just need a majority of cloud-init committers to vote positively?

The DMB Application Process page has the following, which seems like a reasonable sort of thing to crib:

During the meeting the DMB members will cast their votes and if quorum is reached (4 of 7 currently), will add the applicant to the team or ask to re-apply in due time.

(I think it’s definitely worth including that last clause about reapplication: it’s worth acknowledging that we may reject someone’s application, but that that isn’t necessarily the end of the line for them.)

1 Like

On the voting procedure itself, what do you think about using GitHub PRs? We could have the applicant prepare an application PR based on the template above against a dedicated branch. The branch can be “orphan” (git switch --orphan) and contain only approved applications. GitHub allows for setting a per-branch minimum number of approvals from people with commit rights with no “changes requested” reviews to allow merging, so this would work if we go for a “quorum with no vetos” voting.


  • Everything stays where we already develop, no need for additional discussion venues
  • Everything is public and we’re all already used to do reviews on GitHub
  • Easy to reference past work within GitHub in the application
  • All the bits are already more or less in place :slight_smile:
1 Like

I would agree that the voters are other committers.

I would presume that getting everyone will at some point become impractical. Would it be better to have a “majority of current committers” or define a set number, such as “three committers must +1”?

One question I’d like to hear feedback from the pool of committers would be is there a preference to doing this publicly vs privately with a public response?

I could see we could do it all in the discourse post as comments to the thread, it could be done via an IRC meeting, or it could be done via an online conference such as a Meet or other tool. What path do folks think is most conducive to honest feedback and the ability to have a discussion when required?

+1 for sure. I’ll add that in.

I’ve added some clarifying comments around who voters are, the majority, and the process for feedback and repeating if the first vote doesn’t go the applicants way.