Add some more reasoning. Split out unrelated issue.

diff --git a/doc/forum/cleaning_up_discussion_pages_and_the_like.mdwn b/doc/forum/cleaning_up_discussion_pages_and_the_like.mdwn
new file mode 100644 (file)
index 0000000..35ceae5
--- /dev/null
+++ b/doc/forum/cleaning_up_discussion_pages_and_the_like.mdwn
@@ -0,0 +1,11 @@
+For example in [[forum/ikiwiki__39__s_notion_of_time]], should one remove the
+text about the implementation bug that has been fixed, or should it stay there,
+for reference?  --[[tschwinge]]
+
+> I have no problem with cleaning up obsolete stuff in the forum, tips, etc.
+> --[[Joey]]
+
+That's also what I think: such discussions or comments on [[forum]] discussion
+pages, or generally on all pages' [[Discussion]] subpages, can be removed if
+either they're simply not valid / interesting / ... anymore, or if they've been
+used to improve the *real* documentation.  --[[tschwinge]]

diff --git a/doc/forum/ever-growing_list_of_pages.mdwn b/doc/forum/ever-growing_list_of_pages.mdwn
index 435b12c8c9511c8473e4ab83db90a1e0fc0eca53..9920e34bbca55d3df6bf334cc341e03e41060b2a 100644 (file)
--- a/doc/forum/ever-growing_list_of_pages.mdwn
+++ b/doc/forum/ever-growing_list_of_pages.mdwn
@@ -5,10 +5,6 @@ they're still present in the repository.
 Shouldn't there be some clean-up at some point for those that have been
 resolved?  Or should all of them be kept online forever?
 
-Likewise, for example in [[forum/ikiwiki__39__s_notion_of_time]], should one
-remove the text about the implementation bug that has been fixed, or should it
-stay there, for reference?
-
 --[[tschwinge]]
 
 > To answer a question with a question, what harm does having the done bugs
@@ -18,5 +14,16 @@ stay there, for reference?
 > running older versions of the Ikiwiki software may find the page explaining
 > that the bug is fixed if they perform a search. -- [[Jon]]
 
-> I like to keep old bugs around. OTOH, I have no problem with cleaning up
-> obsolete stuff in the forum, tips, etc. --[[Joey]]
+> I like to keep old bugs around. --[[Joey]]
+
+So, I guess it depends on whether you want to represent the development of the
+software (meaning: which bugs are open, which are fixed) *(a)* in a snapshot of
+the repository (a checkout; that is, what you see rendered on
+<http://ikiwiki.info/>), or *(b)* if that information is to be contained in the
+backing repository's revision history only.  Both approaches are valid.  For
+people used to using Git for accessing a project's history, *(b)* is what
+they're used to, but for those poor souls ;-) that only use a web browser to
+access this database, *(a)* is the more useful approach indeed.  For me, using
+Git, it is a bit of a hindrance, as, when doing a full-text search for a
+keyword on a checkout, I'd frequently hit pages that reported a bug, but are
+tagged `done` by now.  --[[tschwinge]]