urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
doc/forum/cleaning_up_discussion_pages_and_the_like.mdwn 100644
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]]

19
doc/forum/ever-growing_list_of_pages.mdwn
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
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]]