Add issue templates (#3872)

This commit is contained in:
Fred Silberberg 2020-09-10 09:54:59 -07:00 committed by GitHub
parent 41a28555bf
commit 09aecc2f74
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 53 additions and 0 deletions

5
.github/ISSUE_TEMPLATE/config.yml vendored Normal file
View file

@ -0,0 +1,5 @@
blank_issues_enabled: false
contact_links:
- name: Open a Discussion
url: https://github.com/dotnet/csharplang/discussions/new
about: Please open new proposals as discussions if they are not fully specified.

View file

@ -0,0 +1,48 @@
---
name: Language Proposal
about: Fully specified language proposal
title: "[Proposal]: [FEATURE_NAME]"
---
<!--
New language feature proposals should fully fill out this template. This should include a complete detailed design, which describes the syntax of the feature, what that syntax means, and how it affects current parts of the spec. Please make sure to point out specific spec sections that need to be updated for this feature. If you do not have the knowledge or experience to fill this out completely, that's perfectly alright: please open this proposal as a Discussion instead (https://github.com/dotnet/csharplang/discussions/new) and the community can generally discuss the proposal in less formal terms.
-->
# FEATURE_NAME
* [x] Proposed
* [ ] Prototype: Not Started
* [ ] Implementation: Not Started
* [ ] Specification: Not Started
## Summary
[summary]: #summary
<!-- One paragraph explanation of the feature. -->
## Motivation
[motivation]: #motivation
<!-- Why are we doing this? What use cases does it support? What is the expected outcome? -->
## Detailed design
[design]: #detailed-design
<!-- This is the bulk of the proposal. Explain the design in enough detail for somebody familiar with the language to understand, and for somebody familiar with the compiler to implement, and include examples of how the feature is used. Please include syntax and desired semantics for the change, including linking to the relevant parts of the existing C# spec to describe the changes necessary to implement this feature. An initial proposal does not need to cover all cases, but it should have enough detail to enable a language team member to bring this proposal to design if they so choose. -->
## Drawbacks
[drawbacks]: #drawbacks
<!-- Why should we *not* do this? -->
## Alternatives
[alternatives]: #alternatives
<!-- What other designs have been considered? What is the impact of not doing this? -->
## Unresolved questions
[unresolved]: #unresolved-questions
<!-- What parts of the design are still undecided? -->
## Design meetings
<!-- Link to design notes that affect this proposal, and describe in one sentence for each what changes they led to. -->