chore: add gh issue and pr templates #164
Conversation
| @@ -0,0 +1,13 @@ | |||
| --- | |||
| name: 📕 Documentation Issue | |||
There was a problem hiding this comment.
Nit: Use sentence case for issue names
There was a problem hiding this comment.
This isn't the name of the issue created it's the template name. You can see an example by going to the java sdk and clicking on create issue
| @@ -0,0 +1,37 @@ | |||
| --- | |||
| name: Feature Request | |||
There was a problem hiding this comment.
Nit: Use sentence case for issue names
| @@ -0,0 +1,37 @@ | |||
| --- | |||
| name: Feature Request | |||
There was a problem hiding this comment.
Suggestion: If you're going to use emojis for 📕 Documentation issue and 🐛 Bug report, I suggest you go with 💡 Feature request here!
.github/pull_request_template.md
Outdated
| @@ -0,0 +1,15 @@ | |||
| <!--- Provide a general summary of your changes in the Title above --> | |||
|
|
|||
| ## Issue # | |||
There was a problem hiding this comment.
Fix: The trailing # doesn't render on GitHub because headings have optional closing hashes. Use either ## Issue \# or possibly ## Issue # #.
docs/debugging.md
Outdated
| @@ -0,0 +1,55 @@ | |||
| # Debugging SDK Requests | |||
There was a problem hiding this comment.
Suggestion: This doc covers more than just requests. We could simply call it "Debugging" or "Debugging the SDK".
docs/debugging.md
Outdated
| ```kotlin | ||
|
|
||
| try { | ||
|
|
||
| ... | ||
| } catch(ex: AwsServiceException) { | ||
| val httpResp = ex.sdkErrorMetadata.protocolResponse as? HttpResponse | ||
| if (httpResp != null) { | ||
| println(httpResp.headers) | ||
| println(httpResp.body.readAll()?.decodeToString()) | ||
| } | ||
| } | ||
|
|
||
| ``` |
There was a problem hiding this comment.
Nit: Unnecessary vertical whitespace
.github/ISSUE_TEMPLATE/bug_report.md
Outdated
|
|
||
| <!--- Include full errors, uncaught exceptions, stack traces, and relevant logs --> | ||
| <!--- To turn on SDK logging, follow instructions here: http://github.com/aws-sdk-kotlin/tree/main/docs/debugging.md --> | ||
| <!--- If service responses are relevant, please include wirelogs --> |
There was a problem hiding this comment.
suggestion
some warning about sensitive data in wire logs. Maybe "If service responses are relevant, please include wirelogs after removing any sensitive content"
.github/ISSUE_TEMPLATE/bug_report.md
Outdated
| <!--- If service responses are relevant, please include wirelogs --> | ||
|
|
||
| ## Steps to Reproduce | ||
| <!--- Provide a self-contained, concise snippet of code that can be used to reproduce the issue --> |
There was a problem hiding this comment.
comment/suggestion
Sometimes this just isn't possible or reasonable given the customer's level of understanding of the SDK. Maybe prefix like "If possible, provide a self-contained and concise snippet of code that can be used to reproduce the issue"
|
|
||
| * Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request | ||
| * Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request | ||
| * If you are interested in working on this issue, please leave a comment |
There was a problem hiding this comment.
comment
This is outside of the scope of the PR but do we want to first tag issues as "help wanted" or "contributions welcome" or something to indicate what types of issues we'd like help with? If we go this route, then we make the first choice as to what we'd be interested in taking from the community. On the other hand, this kind of gating could reduce 3P participation.
There was a problem hiding this comment.
I don't think they are mutually exclusive. If someone wants to pick up an issue that isn't marked as "help wanted" then I say go for it. (Also we have a help wanted label already FYI)
| <!--- A clear and concise description of the feature you are proposing --> | ||
|
|
||
| ## Is your Feature Request related to a problem? | ||
| <!--- A description of the issue, e.g. I'm always frustrated when... --> |
There was a problem hiding this comment.
nit
this seems unnecessarily negative. how about "A description of the issue, e.g. wouldn't it be great if..."
| <!--- Any alternative solutions or features you've considered --> | ||
|
|
||
| ## Additional Context | ||
| <!--- How has this issue affected you? What are you trying to accomplish? --> |
There was a problem hiding this comment.
nit
Maybe reword as "How has the lack of this feature affected you?"
| @@ -23,7 +23,7 @@ reported the issue. Please try to include as much information as you can. Detail | |||
| ## Contributing via Pull Requests | |||
| Contributions via pull requests are much appreciated. Before sending us a pull request, please ensure that: | |||
|
|
|||
| 1. You are working against the latest source on the *master* branch. | |||
| 1. You are working against the latest source on the *main* branch. | |||
| The log level can be adjusted up as needed to DEBUG, INFO, WARN, or ERROR. [See here](http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html) for all properties for the simple logger. | ||
|
|
||
|
|
||
| #### CRT Logs |
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.