Roles

[ Roles | Reviewing | TODO ]

Working Group Roles

While this new Ansible community thing is unfolding and we are finding better ways to collaborate, let's discuss what roles we have and what your role really means.

Most Ansible collaborators interact using Github about a specific issue or feature, in isolation with some core developers or the accidental bypasser. The main goal for having these Working Groups is to get more people involved working around specific technologies, and at the same time empowering those communities so there is a richer discussion, a better solution and a faster response with people that relate to the specific technology.

Lead

One or more leads ensure that the Working Group stays active on working on open issues, open PRs and new functionality or ideas. This is not exclusive to WG leadership, any member of the Working Group can engage others to help out reviewing or commenting on open issues and PRs, but it is the WG leadership that should be aware of keeping the fire burning while at the same time not overexposing members with too much calls for action.

The WG lead is the first person to contact for questions related to the WG or WG membership. In case of unclarity or issues touching other domains the WG lead will raise those issues to the Community WG or the core team.

Responsibilities

• Regularly (re-)evaluate open issues and open PRs and engage to get them solved/merged
• Keep the Working Group wiki page up-to-date and community pinboard engaging
• Collect ideas and engage the community to speak up on solutions/implementation
• Raise blocking issues to Community WG or the core team
• Empower others to engage in improving the WG
• Question and expand WG leadership when required

The lead is added in BOTMETA.yml as a maintainer and has shipit rights. She will be notified of related issues and PRs.

Reviewer

A reviewer is someone interested in helping improve new contributions and supporting others with issues. A reviewer will review issues and PRs regularly, especially when asked by contributors or WG leadership. A reviewer usually has access to infrastructure to run integration tests against, but that is not always necessary for reviewing PR.

If a reviewer does review a PR without the ability to test running code, he should say so when approving a PR (as to ensure that there's no confusion whether the code was actually tested). We encourage reviewers to only add shipits when they have both reviewed the code, as well as tested the code.

Responsibilities

• Review issues and PRs when they are opened, or when WG leadership asks for help
• Help others to do reviews, perform tests or write integration tests
• Collaborate on new functionality
• Provide expert feedback to the Working Group during discussions

A reviewer is added in BOTMETA.yml as a maintainer and has shipit rights. She will be notified of related issues and PRs.

Member

A member is interested to follow and engage into discussions, but has limited time or experience to review code.

Responsibilities

• Help others to do reviews, perform tests or write integration tests
• Provide expert feedback to the Working Group during discussions

A member is added in BOTMETA.yml as being notified for related issues/PRs, but does not have shipit rights.

Pinboard subscriber

Anyone can subscribe to a community pinboard to stay informed on general discussions or news items on the pinboard. They are not added as members on the Working Group as such and are largely anonymous unless they engage in a discussion on the pinboard.