diff --git a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn
index b1f8ed2b3..4ce257252 100644
--- a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn
+++ b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn
@@ -33,3 +33,8 @@ Patch[[!tag patch]]:
      
 
 -- [[Jon]]
+
+> Strictly speaking, a `<ul>` with no `<li>`s isn't valid HTML either...
+> could `map` instead delay emitting the first `<ul>` until it determines that
+> it will have at least one item? Perhaps refactoring that function into
+> something easier to regression-test would be useful. --[[smcv]]
diff --git a/doc/bugs/nested_raw_included_inlines.mdwn b/doc/bugs/nested_raw_included_inlines.mdwn
index 792bc843c..33433e235 100644
--- a/doc/bugs/nested_raw_included_inlines.mdwn
+++ b/doc/bugs/nested_raw_included_inlines.mdwn
@@ -24,3 +24,11 @@ In my real world situation, page1 is actually listing all pages that match a cer
 Whenever a page got tagged, it will appear on page1 but not on page0.
 
 Am I missing something? Is this a bug or Ikiwiki not supposed to support this use case?
+
+> Perhaps the inline plugin isn't being clever enough about dependencies -
+> strictly speaking, when a page is inlined with full content, the inlining
+> page should probably inherit all the inlined page's dependencies.
+> That might be prohibitively slow in practise due to the way IkiWiki
+> currently merges pagespecs, though - maybe the patches I suggested for
+> [[separating_and_uniquifying_pagespecs|todo/should_optimise_pagespecs]]
+> would help? --[[smcv]]
diff --git a/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn b/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn
index 1e2030b23..85a206bc0 100644
--- a/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn
+++ b/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn
@@ -8,22 +8,10 @@ The git commit (in my `openid` branch) says it all:
 
 This bug affects ikiwiki.info (my commits show up in [[RecentChanges]] as http://smcv.pseudorandom.co.uk/ rather than smcv [pseudorandom.co.uk]).
 
-> Cherry picked, thanks. --[[Joey]] 
+> Cherry picked, thanks. --[[Joey]]
 
-Relatedly, the other commit on the same branch would be nice to have:
+Relatedly, the other commit on the same branch would be nice to have
+(edited to add: I've now moved it, and its discussion, to
+[[todo/pretty-print_OpenIDs_even_if_not_enabled]]). --[[smcv]]
 
-    Allow the openid plugin to be loaded but disabled, for its side-effect of defining IkiWiki::openiduser
-    
-    On various sites I have two IkiWiki instances running from the same
-    repository: one accessible via http and only accepting openid logins,
-    and one accessible via authenticated https and only accepting httpauth.
-    Ideally, the https version should still pretty-print OpenIDs seen in
-    git history.
-
---[[smcv]]
-
-> I wonder if an option is the best approach. Maybe it would be better to
-> simply move `openiduser` into `userlink`, and thus always support openid
-> usernames whether the plugin is enabled or not. --[[Joey]] 
-
-[[!tag patch]]
+[[!tag done]]
diff --git a/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn b/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn
index 111ade8dd..430d65a3f 100644
--- a/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn
+++ b/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn
@@ -28,3 +28,5 @@ Prettydate creates strings like this: _Last edited in the wee hours of Tuesday n
 > --[[Joey]]
 
 >> fair enough, I think I can get converted to a warped time perspective. --ulrik
+
+>>> Perhaps we can consider this [[done]], then? --[[smcv]]
diff --git a/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn
index ca80c93f4..7599e71e5 100644
--- a/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn
+++ b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn
@@ -65,3 +65,5 @@ index 0bf100a..77b467a 100644
 >>>> If the end if "1" you should see the "Wiki Setup" button, if not the
 >>>> problem is not in determining if you're an admin, but elsewhere..
 >>>> --[[Joey]]
+
+I was being incredibly stupid and missed that websetup is a **plugin** and thus needed to be enabled.  Many thanks for your patient assistance, by helping me eliminate the unlikely it eventually led me to the obvious.  Cheers.  -- [[Adam]]
diff --git a/doc/plugins/anonok.mdwn b/doc/plugins/anonok.mdwn
index a3fec4d89..497ca07c8 100644
--- a/doc/plugins/anonok.mdwn
+++ b/doc/plugins/anonok.mdwn
@@ -6,7 +6,7 @@ anonymous web users, who have not signed in, to edit any page in the wiki
 by default.
 
 The plugin also has a configuration setting, `anonok_pagespec`. This
-[[PageSpec]] can be used to allow anonymous editing of matching pages.
+[[ikiwiki/PageSpec]] can be used to allow anonymous editing of matching pages.
 
 If you're using the [[comments]] plugin, you can allow anonymous comments
 to be posted by setting:
diff --git a/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn
new file mode 100644
index 000000000..373c120a6
--- /dev/null
+++ b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn
@@ -0,0 +1,24 @@
+A feature I originally requested on
+[[a_related_bug|bugs/openid_no_longer_pretty-prints_OpenIDs]]:
+
+    Allow the openid plugin to be loaded but disabled, for its side-effect of defining IkiWiki::openiduser
+    
+    On various sites I have two IkiWiki instances running from the same
+    repository: one accessible via http and only accepting openid logins,
+    and one accessible via authenticated https and only accepting httpauth.
+    Ideally, the https version should still pretty-print OpenIDs seen in
+    git history.
+
+--[[smcv]]
+
+> I wonder if an option is the best approach. Maybe it would be better to
+> simply move `openiduser` into `userlink`, and thus always support openid
+> usernames whether the plugin is enabled or not. --[[Joey]]
+
+>> OK, implemented that as 'smcv/always-openid'; if you don't think that's
+>> bloating the IkiWiki core too much, please consider merging. The poll on
+>> [[news/openid]] indicates fairly strong support for *only* accepting OpenID
+>> logins, so I think recognising OpenIDs can reasonably be considered core
+>> functionality! --[[smcv]]
+
+[[!tag patch]]