diff --git a/doc/bugs/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_4_7bd5a28d5ba1eefd5a96483b5f00a89e._comment b/doc/bugs/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_4_7bd5a28d5ba1eefd5a96483b5f00a89e._comment
new file mode 100644
index 0000000000..842fefc8d7
--- /dev/null
+++ b/doc/bugs/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_4_7bd5a28d5ba1eefd5a96483b5f00a89e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2020-10-11T13:51:28Z"
+ content="""
+the mystery is that to our knowledge we do close the stdin (and stdout) of [git-annex process right before](https://github.com/datalad/datalad/blob/master/datalad/cmd.py#L1339), so pipe should have not remained open, unless something else may be somehow keeps it open...  And I cannot reproduce the bug ATM neither locally or on smaug where I did prepare you the reproduced case!
+
+Indeed though I agree that pretty much any timeout could not generally be \"sufficient\".  That is why we need to figure out what is happening/why some times batched processes do not quit.  Either the later \"reproducer\" was exactly the same situation as in the original reported (where it was a few out of 1000s of batched processes) -- I do not know.  may be there are multiple issues.
+"""]]
diff --git a/doc/forum/Cannot_get_unlocked_file_contents/comment_1_1905d2a9ae0142838f42aff4efd5c643._comment b/doc/forum/Cannot_get_unlocked_file_contents/comment_1_1905d2a9ae0142838f42aff4efd5c643._comment
new file mode 100644
index 0000000000..f4e50decc8
--- /dev/null
+++ b/doc/forum/Cannot_get_unlocked_file_contents/comment_1_1905d2a9ae0142838f42aff4efd5c643._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-10-11T14:01:35Z"
+ content="""
+First, you should try \"git annex get\" on that file and see if works. If it simply outputs nothing, then you indeed somehow committed a hash link. Use \"git log --stat\" and look for the commit that changed the file, then copy the commit-id of the commit before that. Then you can get the old version of the file with \"git checkout <commit-id> -- <file>\".
+"""]]
diff --git a/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_1_716cbfe900552a453965ac4abd44e7a4._comment b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_1_716cbfe900552a453965ac4abd44e7a4._comment
new file mode 100644
index 0000000000..e735f48c10
--- /dev/null
+++ b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_1_716cbfe900552a453965ac4abd44e7a4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-10-11T14:08:27Z"
+ content="""
+I don't think your problem is related to the \"git fsck\" error. Also, it doesn't look like the failure of \"git annex repair\" is related to the \"git fsck\" error either.
+What does \"git status\" say in the repo that is missing files?
+"""]]
diff --git a/doc/todo/memory_use_increase/comment_1_854006a91f114775797c7c332b2ad83f._comment b/doc/todo/memory_use_increase/comment_1_854006a91f114775797c7c332b2ad83f._comment
new file mode 100644
index 0000000000..484391527b
--- /dev/null
+++ b/doc/todo/memory_use_increase/comment_1_854006a91f114775797c7c332b2ad83f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-10-11T14:17:47Z"
+ content="""
+I guess commit de3d7d044d237999c0a16eb51c79625f904dd60d could be the culprit as the list of files could become large if \"git cat-file\" has a large delay between the request and the response.
+"""]]