.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Asking for Help
+    url: https://github.com/bcpierce00/unison/wiki/Mailing-Lists
+    about: Please direct questions the unison-users@ list, or unison-hackers@ if reading source code is helpful.
+  - name: Feature Requests (not fully worked out)
+    url: https://github.com/bcpierce00/unison/wiki/Mailing-Lists
+    about: Please bring up feature requests that are not fully designed on a mailing list.

.github/ISSUE_TEMPLATE/defect.md

@@ -0,0 +1,49 @@
+---
+name: Defect Report
+about: Create an issue that argues that there is a bug in unison
+title: ''
+labels: defect
+assignees: ''
+---
+
+# Instructions
+
+The issue tracker is not a help system.  Before using the issue
+tracker, please read the following page thoroughly and follow the
+guidelines it expresses:
+
+https://github.com/bcpierce00/unison/wiki/Reporting-Bugs-and-Feature-Requests
+
+Pleaes delete the following dashed line and the text above it, leaving the
+statement that you have read the wiki page.
+----------------------------------------
+I have thoroughly read the [Reporting Bugs and Feature Requests](https://github.com/bcpierce00/unison/wiki/Reporting-Bugs-and-Feature-Requests) wiki page.
+
+# Meta
+
+Bug reports must be about a minimized configuration, as described in the wiki page.
+
+People filing bug reports will be expected to follow up and perhaps
+test proposed fixes.
+
+# Environment
+
+  - Unison version
+  - OS, version and CPU
+  - ocaml version
+  - TUI or GUI
+  - local, ssh, socket, or ?
+  - use of fsmonitor?
+
+# Reproduction Recipe
+
+[Describe how to reproduce the bug.  This must be the smallest
+configuration you can find that exhibits the bug, and you should
+include the largest working configuration also.  Generally this means
+local sync, TUI, no watcher, unless e.g. the bug is phrased as
+"Without the watcher, behavior is correct, but on adding
+fsmonitor-foo, ....".]
+
+# Expected behavior vs actual behavior
+
+[Describe the actual behavior.  Argue that the behavior is incorrect.]

.github/ISSUE_TEMPLATE/feature.md

@@ -0,0 +1,56 @@
+---
+name: Fully-designed Feature Request
+about: Create a fully-specified feature request
+title: ''
+labels: enhancement
+assignees: ''
+---
+
+# Instructions
+
+Before using the issue tracker, please read the following page
+thoroughly and follow the guidelines it expresses:
+
+https://github.com/bcpierce00/unison/wiki/Reporting-Bugs-and-Feature-Requests
+
+If your feature request is not fully formed, please post on
+unison-users@ or unison-hackers@ instead.
+
+Pleaes delete the following dashed line and the text above it, leaving the
+statement that you have read the wiki page.
+----------------------------------------
+I have thoroughly read the [Reporting Bugs and Feature Requests](https://github.com/bcpierce00/unison/wiki/Reporting-Bugs-and-Feature-Requests) wiki page.
+
+# Motivation
+
+Explain what you want to do.
+
+# Background
+
+Explain why the documentation and current behavior do not permit
+achieving your goals.  For near misses, explain.
+
+# Scope
+
+Discuss whether the proposed behavior is aligned with unison's historical scope and why it is a reasonable change.
+
+If there are portability concerns, discuss them.
+
+# Will you write code?
+
+Say whether you intend to implement the feature.  (If so, it is
+entirely reasonable to ask first if it would be accepted if written,
+if you don't want to spend time on a feature that won't be merged).
+
+# Operation of the new feature
+
+Explain how the new feature will behave, enough that someone else (who
+is familiar with unison) could implement it.
+
+Discuss problems that will arise and how they should be handled.
+
+# Complexity vs Benefit
+
+Discuss the tradeoff of complexity in the code base and documentation
+vs the benefit to users.  Generally, proposed features should be of
+fairly broad interest.