Added a comment

doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_1_2f13e023228fa4938dd314e040a8ec10._comment

@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2020-04-07T15:30:54Z"
+ content="""
+As of 7.20200202.7, initremote and enableremote will refuse to accept
+unknown values:
+
+```
+$ git annex initremote d type=directory directory=/$PWD../dir/ autoenable=yes encryption=none
+initremote d                                         
+git-annex: Bad value for autoenable (expected true or false)
+failed
+git-annex: initremote: 1 failed
+```
+
+Here's your [todo][0] related to those changes.
+
+Rejecting invalid values isn't the more liberal casting of boolean
+values that you're asking for here, but the above behavior would stop
+an initremote caller from misconfiguring the remote, preventing cases
+like the report you link to.
+
+Assuming that taking multiple values for a boolean is a good thing in
+general, it seems like it'd be problematic to switch special remote
+parameters over to this behavior.  The stored config is used when
+enabling it in other repos, so an older version of git-annex would
+see, say, autoenable=yes and not treat it as autoenable=true.  To
+avoid that, I suppose git-annex could map the value onto the currently
+accepted form when storing the config, but I'd guess at that point
+support for multiple ways to say true isn't really worth the
+trade-off.
+
+[0]: https://git-annex.branchable.com/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/
+
+"""]]