2 files changed, 37 insertions, 0 deletions

diff --git a/issues/gnbug/add-convenience-templates.gmi b/issues/gnbug/add-convenience-templates.gmi
new file mode 100644
index 0000000..41eb975
--- /dev/null
+++ b/issues/gnbug/add-convenience-templates.gmi
@@ -0,0 +1,29 @@
+# Add convenienve templates
+
+* feature-request
+
+WDYT of adding a subcommand called `report` to generate a template for a bug report?
+
+I was thinking of an interface like the following:
+
+```
+gnbug report feature-request "New feature: IPFS Downloads"
+```
+
+Or expressed as generic command parameters:
+
+```
+command subcommand tag(s) title
+```
+
+Which creates a file in issues/binderlite directory with a template like the 
+following:
+
+
+```
+# New feature: IPFS Downloads
+
+* feature-request
+```
+
+Might be bloat but might be nice and convenient also. WDYT?
diff --git a/issues/gnbug/add-linter.gmi b/issues/gnbug/add-linter.gmi
index 7992753..1a8a301 100644
--- a/issues/gnbug/add-linter.gmi
+++ b/issues/gnbug/add-linter.gmi
@@ -14,3 +14,11 @@ support.
 I am not sure. Pjotr is of the philosophy that we should keep the text as unstructured and unrestrictive as possible, and I agree with this philosophy. Linters are likely to annoy users more than help them. They might discourage casual use of the issue tracker. Especially with tags, we don't really want to restrict the user from coming up with new tags.
 
 WDYT? Am I missing some scenario where the linter could be essential?
+
+Nope, it was just something I thought could be convenient if we wanted to restrict 
+the format for tags, etc...
+
+If we'd like to "keep the text as unstructured and unrestrictive as possible" I'm
+fine with that too.
+
+I was just worried about using "invalid" tags. Now, I know it's ok :)