Skip to content

Commit b0bcfb9

Browse files
mmccartymmccarty
committed
restored contributing docs
1 parent 35bfc18 commit b0bcfb9

File tree

5 files changed

+288
-1
lines changed

5 files changed

+288
-1
lines changed

‎contributing/code.md

+78
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
---
2+
layout: default
3+
nav_order: 2
4+
parent: Contributing
5+
title: Code Contributions
6+
---
7+
8+
# Code Contributions
9+
10+
## Overview
11+
12+
Outlines the best way for developers and the community to contribute to RAPIDS projects.
13+
14+
Contributions can be made in three ways:
15+
- [File a bug report]({% link contributing/issues.md %})
16+
- [Suggest a new feature or improvement]({% link contributing/issues.md %})
17+
- [Implement code for an issue](#your-first-issue)
18+
19+
### Intended audience
20+
21+
Community
22+
{: .label .label-yellow}
23+
24+
Developers
25+
{: .label .label-green}
26+
27+
### See also
28+
29+
- [Issues]({% link contributing/issues.md %})
30+
- [Pull Requests]({% link contributing/prs.md %})
31+
32+
## New developers
33+
34+
If you are new to RAPIDS, make sure to check out <https://rapids.ai/> to help understand the purpose of RAPIDS.
35+
36+
### Your first issue
37+
38+
1. Read the project's README to learn how to setup the development environment
39+
2. Find an issue to work on. The best way is to look for the <span class="label" style="background: #7057ff; color: #ffffff; text-transform: none">good first issue</span> or <span class="label" style="background: #008672; color: #ffffff; text-transform: none">help wanted</span> labels
40+
3. Comment on the issue saying you are going to work on it
41+
4. Code! Make sure to update unit tests!
42+
5. When done, [create your pull request]({% link contributing/prs.md %})
43+
6. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed
44+
7. Wait for other developers to review your code and update code as needed
45+
8. Once reviewed and approved, a RAPIDS developer will merge your pull request
46+
47+
Remember, if you are unsure about anything, don't hesitate to comment on issues and ask for clarifications!
48+
49+
## Seasoned developers
50+
51+
Once you have gotten your feet wet and are more comfortable with the code, follow these steps to find prioritized issues.
52+
53+
All RAPIDS projects have project boards for triaging [issues]({% link releases/triage.md %}) and planning [features]({% link releases/planning.md %}).
54+
55+
### What do I work on?
56+
57+
__Note:__ If you are have been assigned issues, work on those issues first.
58+
59+
For all others:
60+
61+
1. Find the project board for the next release (named `[version] Release`)
62+
2. Issues are prioritized from high to low: `P0`, `P1`, and `P2`.
63+
<br>Within each column, the issues are ordered top to bottom from most important to least.
64+
3. Select the highest priority issue that you are comfortable working on
65+
4. If you are in the RAPIDS org, assign the issue to yourself. If not, comment on the issue saying you are going to work on it
66+
5. Code! Make sure to update unit tests!
67+
6. When done, [create your pull request]({% link contributing/prs.md %})
68+
7. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed
69+
8. Wait for other developers to review your code and update code as needed
70+
9. Once reviewed and approved, a RAPIDS developer will merge your pull request
71+
72+
### Reviewing pull requests
73+
74+
1. Find the project board for the next release (named `[version] Release`)
75+
2. Scroll right to find the `PR-Needs Review`
76+
3. Review the PR (Make sure you follow the [Code of Conduct]({% link resources/conduct.md %}))
77+
78+
If you are project lead, also review pull requests in the `PR-Reviewer Approved` column and merge as needed.

‎contributing/contributing.md

+44
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
---
2+
layout: default
3+
title: Contributing
4+
nav_order: 6
5+
has_children: true
6+
permalink: contributing
7+
---
8+
9+
# Contributing
10+
{:.no_toc}
11+
12+
RAPIDS can only grow with community support and it is vital to include developers at all levels. Reporting bugs, fixing them, and/or creating new features are all vital for the success of RAPIDS. The following pages outline our approach for contributing to RAPIDS.
13+
{: .fs-6 .fw-300 }
14+
15+
## Getting started
16+
17+
Welcome! We are excited you are here! Before you begin, we ask that everyone review the [Code of Conduct]({% link resources/conduct.md %}) before contributing.
18+
19+
### Your first issue
20+
21+
1. Read the project's README to learn how to setup the development environment
22+
2. Find an issue to work on. The best way is to look for the <span class="label" style="background: #7057ff; color: #ffffff; text-transform: none">good first issue</span> or <span class="label" style="background: #008672; color: #ffffff; text-transform: none">help wanted</span> labels
23+
3. Comment on the issue saying you are going to work on it
24+
4. Code! Make sure to update unit tests!
25+
5. When done, [create your pull request]({% link contributing/prs.md %})
26+
6. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed
27+
7. Wait for other developers to review your code and update code as needed
28+
8. Once reviewed and approved, a RAPIDS developer will merge your pull request
29+
30+
Remember, if you are unsure about anything, don't hesitate to comment on issues and ask for clarifications!
31+
32+
### Seasoned developers
33+
34+
Once you have gotten your feet wet and are more comfortable with the code, follow these steps to find prioritized issues.
35+
36+
All RAPIDS projects have project boards for triaging [issues]({% link releases/triage.md %}) and planning [features]({% link releases/planning.md %}).
37+
38+
### More details
39+
40+
Review the [Code Contributions]({% link contributing/code.md %}) page.
41+
42+
## Issues or feedback
43+
44+
File an issue [here](https://github.com/rapidsai/docs/issues/new) for any unexpected problems encountered or general feedback with any of the information on this site.

‎contributing/issues.md

+80
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
---
2+
layout: default
3+
nav_order: 1
4+
parent: Contributing
5+
title: Issues
6+
---
7+
8+
# Issues
9+
10+
## Overview
11+
12+
Overview of the best practices for creating and updating issues for RAPIDS projects.
13+
14+
### Intended audience
15+
16+
Community
17+
{: .label .label-yellow}
18+
19+
Developers
20+
{: .label .label-green}
21+
22+
### See also
23+
- [Contributing Code]({% link contributing/code.md %})
24+
- [Pull Requests]({% link contributing/prs.md %})
25+
26+
## Create an issue
27+
28+
__Important:__ Before creating an issue, please search existing open & closed issues and pull requests to see if your issue has already been addressed.
29+
30+
Follow the steps [here](https://help.github.com/articles/creating-an-issue/) to start the process of creating an issue.
31+
32+
Issues in RAPIDS projects fall into four types. When creating the issue, select the best fit from these options:
33+
34+
| Issue type | Title Prefix | Description |
35+
|:-----------|:-------------|:------------|
36+
| Bug | `[BUG]` | Report a problem with the code |
37+
| Documentation | `[DOC]` | Report a problem or suggestion related to documentation
38+
| Feature | `[FEA]` | Suggest an new idea or enhancement |
39+
| Question | `[QST]` | Ask the RAPIDS team a question about the project |
40+
41+
If you have an issue which truly is not one of the above, you can select `Open a regular issue`. Use this sparingly.
42+
43+
Consider adding <span class="label" style="background: #7057ff; color: #ffffff; text-transform: none">good first issue</span> or <span class="label" style="background: #008672; color: #ffffff; text-transform: none">help wanted</span> labels to the issue if applicable.
44+
45+
## Format
46+
47+
### Title
48+
49+
Use the appropriate type prefix outlined above. This should be automatically populated when creating the issue.
50+
51+
The title should be succinct description of problem, feature, or question. If code related, try to include the class or function name in the title.
52+
53+
### Description
54+
55+
When using one of the four issue types, the description will be populated with a template which will guide how to describe the issue.
56+
57+
In general, you want to fully describe the issue so that someone can fully understand and reproduce the issue.
58+
59+
60+
#### Task list
61+
62+
Every `Bug`, `Documentation`, and `Feature` issue should have a [task list](https://help.github.com/articles/about-task-lists/), even if it is a single item.
63+
64+
If you are unsure of the task breakdown, include a comment stating help is needed to determine the tasks.
65+
66+
As a developer works on an issue, perhaps after creating a `[WIP]` pull request, they should update the task list and mark tasks completed.
67+
68+
#### Blockers
69+
70+
If an issue is blocked due to another issue or pull request do the following:
71+
- Add the <span class="label" style="background: #e07d6b; color: #44434d; text-transform: none">0 - Blocked</span> label
72+
- Add a task for each blocking issue to the top of the task list that says: `Waiting on issue ###`
73+
74+
## Lifecycle
75+
76+
Issues are either assigned by team leads or picked in priority order. If you are unsure what to work on, follow this [guide]({% link contributing/code.md %}#what-do-i-work-on).
77+
78+
When you begin work on an issue, update the labels to remove <span class="label" style="background: #bfd4f2; color: #44434d; text-transform: none">1 - On Deck</span> or <span class="label" style="background: #d4c5f9; color: #44434d; text-transform: none">0 - Backlog</span> and add <span class="label" style="background: #fef2c0; color: #44434d; text-transform: none">2 - In Progress</span>.
79+
80+
When the associated pull request is merged, the issue will automatically close.

‎contributing/prs.md

+85
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
---
2+
layout: default
3+
nav_order: 3
4+
parent: Contributing
5+
title: Pull Requests
6+
---
7+
8+
# Pull Requests
9+
10+
## Overview
11+
12+
Overview of creating a pull request for a RAPIDS project.
13+
14+
### Intended audience
15+
16+
Developers
17+
{: .label .label-green}
18+
19+
### See also
20+
21+
- [Issues]({% link contributing/issues.md %})
22+
- [Code Contributions]({% link contributing/code.md %})
23+
- [Changelog]({% link resources/changelog.md %})
24+
25+
## Create a pull request
26+
27+
Follow the steps
28+
[here](https://help.github.com/articles/creating-a-pull-request/) to create a
29+
draft pull request (PR) for the target repository.
30+
31+
Guidelines for managing forks and branches:
32+
- Use a [fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) of the upstream RAPIDS repository.
33+
- On your fork, create a branch with a name describing the planned work.
34+
For example, `fix-documentation`.
35+
- When opening the pull request, verify the target branch.
36+
By default, PRs target the next release branch.
37+
38+
Follow the format below for the title and description.
39+
40+
## Format a pull request
41+
42+
### Title
43+
44+
Pull request titles should be succinct and state how the PR addresses the issue.
45+
46+
- Use the present tense ("Add feature" not "Added feature")
47+
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
48+
49+
### Description
50+
51+
The description must start with `Closes #[issue number]`.
52+
If the PR [addresses multiple issues](https://help.github.com/articles/closing-issues-using-keywords/#closing-multiple-issues), use an unordered list and repeat `Closes #[issue number]` for each issue.
53+
For example:
54+
55+
```
56+
- Closes #45
57+
- Closes #60
58+
```
59+
60+
The description should also detail the implementations, challenges, and solutions so reviewers can understand the approach.
61+
Liberally reference related pull requests or related issues, especially if this pull request may affect them.
62+
63+
The description should provide any context not found in the issue description.
64+
65+
### Comments
66+
67+
All pull request comments and reviews must follow the [Code of Conduct]({% link resources/conduct.md %})
68+
69+
## Lifecycle
70+
71+
### Drafting and Testing
72+
73+
[Draft pull
74+
requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests)
75+
should be opened while work is in progress. This will run continuous integration
76+
(CI) without automatically requesting review. Once the pull request is ready, click "Ready for review" to get
77+
feedback on the changes.
78+
79+
### Reviewing and Merging
80+
81+
Once the pull request is ready, open the draft and reviewers will be requested automatically.
82+
83+
All pull requests must pass continuous integration [status checks](https://help.github.com/articles/about-status-checks/).
84+
85+
Once approved, a pull request can be merged by an approved reviewer.

‎maintainers/forward-merger.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@ title: Forward Mergers
1111

1212
The forward mergers are automated pull requests to merge a branch in burndown into the next versioned branch. For example merging `branch-22.12` into `branch-23.02`. This ensures all changes to the current branch are reflected in the next version.
1313

14-
The forward merger jobs are located here: https://gpuci.gpuopenanalytics.com/job/rapidsai/job/forward-mergers/
14+
The forward merger jobs are located here: [https://gpuci.gpuopenanalytics.com/job/rapidsai/job/forward-mergers/](https://gpuci.gpuopenanalytics.com/job/rapidsai/job/forward-mergers/)
1515

1616
### Intended audience
1717

0 commit comments

Comments
 (0)