This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This document describes the meaning of the GitHub labels for the Beats related projects and how to use them properly.

Release tags convention:

• Should be created only the Beats team
• Should be created in advance
• Should start with v followed by the release version, example: v5.0.0-alpha1 or v1.2.1
• Should have the same color: #eeeeee

Note: The labels are available only in the beats repository.

How to manage GitHub issues:

Select the category for which the issue is opened for:

• filebeat
• metricbeat
• winlogbeat
• packetbeat
• libbeat
• new beat
• new module - you need to specify in addition the beat
• packaging - for issues that the infra team can solve
• dashboards

For Windows related issues, select the windows label:

• windows

Select the type of the issue:

• bug
• question
• meta
• discuss
• duplicate
• docs
• refactoring
• enhancement
• blocker
• blocked

In addition to these types, we also have the following labels (temporary):

• Pioneer Program

Set an overview for a feature:

For big features, it’s nice to have an issue with more details about that particular feature. This issue should be labeled meta and contains a list with the tasks that need to be done. Each task is a checkbox and it’s marked when the task is finished. This meta issue should be updated periodically, so our users can follow the status of a feature.

Set a blocker:

To specify that an issue is a blocker for a certain release, you need to set the blocker label and optionally the release tag (when is known).

Mark an issue as blocked:

If there is an issue that waits for another issue to be finished or for a pull request to be merged, then you can set the blocked label.

Start a discussion around a topic:

Create a GitHub issue with all the details that you would like to be discussed and set the label to discuss.

Set the waiting status of the GitHub issues coming from community:

• Needs details - if more details are needed

Manage an invalid GitHub issue:

When the issue is invalid or it proves not to be a bug, the issue doesn’t have to be labeled, it’s just closed.

Specify the release tag:

A release tag is associated to a GitHub issue when that feature or enhancement is on our roadmap for that release.

Specify one of the priorities for the issue:

• P1 - high priority
• P2 - important as other features depend on it
• P3 - nice to have

Group multiple issues related to the same feature

Anyone in the team can create (temporarily) labels that start with : and has the #000000 (white) color. For example :Filtering label can be used to tag all the issues related to the Generic filtering.

How to manage GitHub pull requests

Select the category for which the pull request is opened for:

• Filebeat
• Metricbeat
• Winlogbeat
• Packetbeat
• libbeat
• new beat
• new module - in addition you need to specify the beat
• dashboards - in addition you need to specify the beat

Note: If an user opens a pull request to add a new module in Metricbeat, we need to set the labels: new module and metricbeat.

Set the status of a GitHub pull request:

• review - if the pull request is ready to be reviewed
• in progress - if the pull request is in progress
• blocked - waits for other pull requests to be merged

Manage the GitHub pull requests that require backport:

• backport
• needs backport

After merging a pull request in master, you have the option to label it with needs backport and the release tag to specify that the pull request needs to be backported to another branch.

The code with the actual backport should be included in a different pull request. This pull request should have the title Backport of #xxxx, the backport label and optionally the release tag. Additionally, the link to the backported pull request should be added.

Set the waiting status of the gitHub pull requests coming from community:

• needs CLA - in case the user didn’t sign the CLA
• needs tests - requires adding tests (integration tests + unit tests)
• needs updates - wait for updates from the creator of the pull request

Mark a pull request as blocked:

If there is a pull request that waits for other pull request to be merged, then set the blocked label.

Refuse a pull request:

When we decided that the pull request cannot be accepted, we don’t need to add any label, just provide the motivation why we are not receiving the pull request and closing it without merging.

Associate the pull request with the issue:

Not all pull requests need to have an issue associated in GitHub. In case there is one already opened, link the issue into the pull request and add the issue in the commit message that fixes the issue: https://help.github.com/articles/closing-issues-via-commit-messages/.

How to manage documentation

Let’s consider you have created a pull request to add a new feature and it contains also the documentation about how to configure the feature. To make sure Dede, our technical writer, is checking the documentation, you need to create a GitHub issue for that and associate the docs label together with the priority. The docs related issues are solved in order of their priority.