Comment 2 for bug 1183890

I like the idea of tracking issues (and documentation) within a project using zim.

I can think of a grand and lofty way of doing this using guids and fundamental zim changes... but (IMO) the best cost/benefit approach (read easy yet effective) would actually not even require a plugin.

That is, to try splay out the *workflow* of the bug, and sacrifice individual identifiers.

Suppose you had bob and alice working on issues with the following workflow:
* NEW -> CONFIRMED -> IN_PROGRESS -> COMMITTED -> CLOSED

I think a zim+src layout might look like:

/ -- the project root is also the zim root...
/.git -- b/c git>hg , and docs+issues linked to current state
/.zimignore -- /src ? Or could it be okay to link zim pages into the source code?!?
/src -- probably a hazard if auto-saving;
/docs/HowTo/FileaBug -- b/c let us not kid ourselves, this is a bit strange... is also a zim page :docs:HowTo:FileaBug
/issues/new/VeryTerseTitle <-- generally okay to accept merges with new entries in /issues/new (absent large attachments), but noob questions can be dealt with directly in the forum that the patch/merge is presented
...
/issues/Confirmed/Future/CantPrintFromZim
/issues/Confirmed/Plugin/AttachmentBrowser/NoDeleteOption
...
/issues/InProgress/alice/SomethingAliceIsWorkingOn
/issues/InProgress/bob/BobsSpecialInterest
...
/issues/Committed/Plugin/Journal/AddContextMenu
..
/issues/Closed/Visual/NewIconForUnderlineBecauseItHighlights

-

Most of the "tracking" work, then, is actually moving pages around; and most of the 'history' work is following implicit git move/rename/annotate paths.

IMO, if such a layout were to include any non-trivial organizational depth, it would be feasible only after:
* https://bugs.launchpad.net/zim/+bug/1674785
** (so that you can easily keep any organization hierarchy when moving bug report pages that differ only by one path segment)

Other hazards?
* broken links wherever these pages are hosted, whenever pages are moved about