= Suggested Reviewers = Different developers have different strengths and areas of focus. Use the following table to decide who might be the best person to review your patch. You can then add them under the `Reviewers` section on the right hand side in github. | Area | Reviewer | | ---- | -------- | | Attributes | clumens | | Documentation | anyone | | C refactoring | anyone | | CTSlab | clumens | | Command line tools | anyone | | Fencing | | | IPC | | | Other daemons | narwahl | | Packaging | | | Python | clumens | | Regression tests | | | Scheduler | narwahl | | Unit tests | anyone | | XML | |

= PR Labels = github labels can be used to group PRs and tag them with useful information. This can be used to convey more information than you can fit in the subject, and without having to clog up the description. It also allows us to see everything at a glance on the main pulls page. Some projects go overboard with labels, but I want to keep their use fairly minimal. Current labels are as follows: - `branch: 2.1` - This should be applied to any PRs that are a backport to the 2.1 release branch. - `branch: 3.0` - This should be applied to any PRs that are a backport to the 3.0 release branch. - `review: in progress` - This should be applied to any PRs that someone has started to review. - `status: in progress` - This should be applied to any PRs that aren't ready to be fully reviewed and merged. Typically, this will just be for drafts or PRs sent out as a proof of concept. - `needs attention` - This should be applied to any PRs that have been sitting around for a while and haven't gotten attention recently. Typically, this would be stuff that comes from an outside contributor where there's a little more back and forth, or from a contributor that's no longer active in the project. This should not be applied to PRs that just need someone to review them. = Suggested Reviewers = Different developers have different strengths and areas of focus. Use the following table to decide who might be the best person to review your patch. You can then add them under the `Reviewers` section on the right hand side in github. | Area | Reviewer | | ---- | -------- | | Attributes | clumens | | Documentation | anyone | | C refactoring | anyone | | CTSlab | clumens | | Command line tools | anyone | | Fencing | wenningerk | | IPC | | | Other daemons | narwahl | | Packaging | | | Python | clumens | | Regression tests | | | Scheduler | narwahl | | Unit tests | anyone | | XML | |

= PR Labels = github labels can be used to group PRs and tag them with useful information. This can be used to convey more information than you can fit in the subject, and without having to clog up the description. It also allows us to see everything at a glance on the main pulls page. Some projects go overboard with labels, but I want to keep their use fairly minimal. Current labels are as follows: - `branch: 2.1` - This should be applied to any PRs that are a backport to the 2.1 release branch. - `branch: 3.0` - This should be applied to any PRs that are a backport to the 3.0 release branch. - `review: in progress` - This should be applied to any PRs that someone has started to review. - `status: in progress` - This should be applied to any PRs that aren't ready to be fully reviewed and merged. Typically, this will just be for drafts or PRs sent out as a proof of concept. - `needs attention` - This should be applied to any PRs that have been sitting around for a while and haven't gotten attention recently. Typically, this would be stuff that comes from an outside contributor where there's a little more back and forth, or from a contributor that's no longer active in the project. This should not be applied to PRs that just need someone to review them. = Suggested Reviewers = Different developers have different strengths and areas of focus. Use the following table to decide who might be the best person to review your patch. You can then add them under the `Reviewers` section on the right hand side in github. | Area | Reviewer | | ---- | -------- | | Attributes | clumens | | Documentation | anyone | | C refactoring | anyone | | CTSlab | clumens | | Command line tools | anyone | | Fencing | wenningerk | | IPC | | | Other daemons | narwahl | | Packaging | | | Python | clumens | | Regression tests | | | Scheduler | narwahl | | Unit tests | anyone | | XML | |