Add some more reasoning. Split out unrelated issue.

master
Thomas Schwinge 2009-10-17 14:43:11 +02:00
parent 69a1ebce16
commit 31633c7add
2 changed files with 24 additions and 6 deletions

View File

@ -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]]

View File

@ -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 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? 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]] --[[tschwinge]]
> To answer a question with a question, what harm does having the done bugs > 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 > running older versions of the Ikiwiki software may find the page explaining
> that the bug is fixed if they perform a search. -- [[Jon]] > 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 > I like to keep old bugs around. --[[Joey]]
> obsolete stuff in the forum, tips, etc. --[[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]]