Skip to content

Commit 87779dc

Browse files
committed
Initial commit
0 parents  commit 87779dc

9 files changed

+478
-0
lines changed

.github/ISSUE_TEMPLATE/bug_report.md

+26
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
---
2+
name: Bug report
3+
about: Create a bug report to help us improve ___PROJECT___
4+
title: "[BUG]"
5+
labels: "? - Needs Triage, bug"
6+
assignees: ''
7+
8+
---
9+
10+
**Describe the bug**
11+
A clear and concise description of what the bug is.
12+
13+
**Steps/Code to reproduce bug**
14+
Follow this guide http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports to craft a minimal bug report. This helps us reproduce the issue you're having and resolve the issue more quickly.
15+
16+
**Expected behavior**
17+
A clear and concise description of what you expected to happen.
18+
19+
**Environment details (please complete the following information):**
20+
- Environment location: [Bare-metal, Docker, Cloud(specify cloud provider)]
21+
- Method of ___PROJECT___ install: [conda, Docker, or from source]
22+
- If method of install is [Docker], provide `docker pull` & `docker run` commands used
23+
24+
25+
**Additional context**
26+
Add any other context about the problem here.
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
---
2+
name: Documentation request
3+
about: Report incorrect or needed documentation
4+
title: "[DOC]"
5+
labels: "? - Needs Triage, doc"
6+
assignees: ''
7+
8+
---
9+
10+
## Report incorrect documentation
11+
12+
**Location of incorrect documentation**
13+
Provide links and line numbers if applicable.
14+
15+
**Describe the problems or issues found in the documentation**
16+
A clear and concise description of what you found to be incorrect.
17+
18+
**Steps taken to verify documentation is incorrect**
19+
List any steps you have taken:
20+
21+
**Suggested fix for documentation**
22+
Detail proposed changes to fix the documentation if you have any.
23+
24+
---
25+
26+
## Report needed documentation
27+
28+
**Report needed documentation**
29+
A clear and concise description of what documentation you believe it is needed and why.
30+
31+
**Describe the documentation you'd like**
32+
A clear and concise description of what you want to happen.
33+
34+
**Steps taken to search for needed documentation**
35+
List any steps you have taken:
+20
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
---
2+
name: Feature request
3+
about: Suggest an idea for ___PROJECT___
4+
title: "[FEA]"
5+
labels: "? - Needs Triage, feature request"
6+
assignees: ''
7+
8+
---
9+
10+
**Is your feature request related to a problem? Please describe.**
11+
A clear and concise description of what the problem is. Ex. I wish I could use ___PROJECT___ to do [...]
12+
13+
**Describe the solution you'd like**
14+
A clear and concise description of what you want to happen.
15+
16+
**Describe alternatives you've considered**
17+
A clear and concise description of any alternative solutions or features you've considered.
18+
19+
**Additional context**
20+
Add any other context, code examples, or references to existing implementations about the feature request here.
+10
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
---
2+
name: Submit question
3+
about: Ask a general question about ___PROJECT___
4+
title: "[QST]"
5+
labels: "? - Needs Triage, question"
6+
assignees: ''
7+
8+
---
9+
10+
**What is your question?**

.github/PULL_REQUEST_TEMPLATE.md

+44
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
<!--
2+
3+
Thank you for contributing to ___PROJECT___ :)
4+
5+
Here are some guidelines to help the review process go smoothly.
6+
7+
1. Please write a description in this text box of the changes that are being
8+
made.
9+
10+
2. Please ensure that you have written units tests for the changes made/features
11+
added.
12+
13+
3. If you are closing an issue please use one of the automatic closing words as
14+
noted here: https://help.github.com/articles/closing-issues-using-keywords/
15+
16+
4. If your pull request is not ready for review but you want to make use of the
17+
continuous integration testing facilities please label it with `[WIP]`.
18+
19+
5. If your pull request is ready to be reviewed without requiring additional
20+
work on top of it, then remove the `[WIP]` label (if present) and replace
21+
it with `[REVIEW]`. If assistance is required to complete the functionality,
22+
for example when the C/C++ code of a feature is complete but Python bindings
23+
are still required, then add the label `[HELP-REQ]` so that others can triage
24+
and assist. The additional changes then can be implemented on top of the
25+
same PR. If the assistance is done by members of the rapidsAI team, then no
26+
additional actions are required by the creator of the original PR for this,
27+
otherwise the original author of the PR needs to give permission to the
28+
person(s) assisting to commit to their personal fork of the project. If that
29+
doesn't happen then a new PR based on the code of the original PR can be
30+
opened by the person assisting, which then will be the PR that will be
31+
merged.
32+
33+
6. Once all work has been done and review has taken place please do not add
34+
features or make changes out of the scope of those requested by the reviewer
35+
(doing this just add delays as already reviewed code ends up having to be
36+
re-reviewed/it is hard to tell what is new etc!). Further, please do not
37+
rebase your branch on master/force push/rewrite history, doing any of these
38+
causes the context of any comments made by reviewers to be lost. If
39+
conflicts occur against master they should be resolved by merging master
40+
into the branch used for making the pull request.
41+
42+
Many thanks in advance for your cooperation!
43+
44+
-->

CHANGELOG.md

+13
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
# ___PROJECT___ 0.0.0 (DD Mon YYYY)
2+
3+
## New Features
4+
5+
- ...
6+
7+
## Improvements
8+
9+
- ...
10+
11+
## Bug Fixes
12+
13+
- ...

CONTRIBUTING.md

+53
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
# Contributing to ___PROJECT___
2+
3+
If you are interested in contributing to ___PROJECT___, your contributions will fall
4+
into three categories:
5+
1. You want to report a bug, feature request, or documentation issue
6+
- File an [issue](https://github.com/rapidsai/___PROJECT___/issues/new/choose)
7+
describing what you encountered or what you want to see changed.
8+
- The RAPIDS team will evaluate the issues and triage them, scheduling
9+
them for a release. If you believe the issue needs priority attention
10+
comment on the issue to notify the team.
11+
2. You want to propose a new Feature and implement it
12+
- Post about your intended feature, and we shall discuss the design and
13+
implementation.
14+
- Once we agree that the plan looks good, go ahead and implement it, using
15+
the [code contributions](#code-contributions) guide below.
16+
3. You want to implement a feature or bug-fix for an outstanding issue
17+
- Follow the [code contributions](#code-contributions) guide below.
18+
- If you need more context on a particular issue, please ask and we shall
19+
provide.
20+
21+
## Code contributions
22+
23+
### Your first issue
24+
25+
1. Read the project's [README.md](https://github.com/rapidsai/___PROJECT___/blob/master/README.md)
26+
to learn how to setup the development environment
27+
2. Find an issue to work on. The best way is to look for the [good first issue](https://github.com/rapidsai/___PROJECT___/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
28+
or [help wanted](https://github.com/rapidsai/___PROJECT___/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) labels
29+
3. Comment on the issue saying you are going to work on it
30+
4. Code! Make sure to update unit tests!
31+
5. When done, [create your pull request](https://github.com/rapidsai/___PROJECT___/compare)
32+
6. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed
33+
7. Wait for other developers to review your code and update code as needed
34+
8. Once reviewed and approved, a RAPIDS developer will merge your pull request
35+
36+
Remember, if you are unsure about anything, don't hesitate to comment on issues
37+
and ask for clarifications!
38+
39+
### Seasoned developers
40+
41+
Once you have gotten your feet wet and are more comfortable with the code, you
42+
can look at the prioritized issues of our next release in our [project boards](https://github.com/rapidsai/___PROJECT___/projects).
43+
44+
> **Pro Tip:** Always look at the release board with the highest number for
45+
issues to work on. This is where RAPIDS developers also focus their efforts.
46+
47+
Look at the unassigned issues, and find an issue you are comfortable with
48+
contributing to. Start with _Step 3_ from above, commenting on the issue to let
49+
others know you are working on it. If you have any questions related to the
50+
implementation of the issue, ask them in the issue instead of the PR.
51+
52+
## Attribution
53+
Portions adopted from https://github.com/pytorch/pytorch/blob/master/CONTRIBUTING.md

0 commit comments

Comments
 (0)