diff --git a/doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment b/doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment
new file mode 100644
index 0000000000..b7edd53e40
--- /dev/null
+++ b/doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717"
+ nickname="vrs+annex"
+ avatar="http://cdn.libravatar.org/avatar/74219abcec6eece8e2c9d4351c2c912c"
+ subject="comment 2"
+ date="2018-04-05T21:01:51Z"
+ content="""
+I have no opinion about what backend to use. If doing it via the metadata system significantly slows down things though and is generally awkward, why not build a separate subsystem?
+
+I don't know what you mean by \"look over all the merged changes and go off and frob timestamps\", but as long as n is on the order of [number of files changed in the commit], updating n files' timestamps sounds reasonable? There's the question of which timestamp has preference in a merge, but that sounds solvable.
+
+I made this a separate bug because it's a specific design proposal; I consider [[todo/does_not_preserve_timestamps]] a tracking bug/user story.
+
+proposal re [[/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/#comment-2ea94161228f0653917b91d4f999153f]]: File and symlink timestamps, after `git-annex-get` or `git-checkout`, are set to whatever's in the repo and then considered immutable. The user can of course change them with `touch`, but if the file is locked while that happens, that's considered a corruption like editing an object file and will be caught by `git-annex-fsck`.
+"""]]
diff --git a/doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn b/doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn
new file mode 100644
index 0000000000..9e6d7654f5
--- /dev/null
+++ b/doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn
@@ -0,0 +1,15 @@
+Hi all,
+
+I've written a simple tool in Python to re-podcast from an annex:  [recastex](https://github.com/stewart123579/recastex)
+
+Starting with the [downloading podcasts](https://git-annex.branchable.com/tips/downloading_podcasts/) page, I've got a number of podcasts on my laptop, but they were not really synced to my podcast app on my phone.  Not a problem any longer.
+
+The app uses the metadata associated with *locally available* files to generate feeds for each of your "subscribed" podcasts - and collects anything else you have (like individual files) into a catch-all feed.
+
+It's designed with git-annex + limited network + privacy in mind separating the public internet queries from the things that can be done over git-annex.
+
+*(As the author of [git-annex-metadata-gui](https://git-annex.branchable.com/tips/a_gui_for_metadata_operations/) said...)*  I hope these can be useful to someone other than myself.
+
+
+
+