Hi Paul,


> 1)       Is bugs.mantisbt.org the best place to showcase ideas? – I personally think ‘no’.

I agree to your point, however, the reasons I put it there are:

- The installation involved the following steps which has minimal effects on Mantis:

            - Install the Wiki.

            - Add a couple of confg entries to config_inc.php

            - Add wiki_api.php and wiki_dokuwiki.php.

            - Add a link to the view pages.


That’s it.  Most of the work is done in the Wiki to make it integrate with Mantis and use Mantis for authentication and authorisation.  I also think it will be very useful in helping us to design some of the big tasks we are working on and have the design available for our users for review.


> 2)       Core/dokuwiki à ‘core’ isn’t a location from which files should get served – as a side note, on our

> install on bugs.mantisbt.org we should probably have apache forbid requests directly to the /core directory.

Agreed.  I’ve add a section on the wiki page which includes the recommended places for installing the wiki.


>  “Namespace” – I can’t recall the behaviour with regards to subprojects – but the id=mantisbt:7075 – that should

> probably be a project ID rather then ‘mantisbt’ – this would enable two projects to have the same name, and still be referenced correctly.

Do we allow two projects to have the same name?!  Using the id will also be useful when a project is renamed.  But it won’t be easy or intuitive to use ids.  However, it may end up being the chosen option!


What is the intention here?


> That it’s possible for users to add a chosen wiki engine to mantis ? or that the mantis installation itself could come with support for a wiki?

The idea is to support multiple wiki engines, however, there we will be supporting one engine, the rest will be done by contributions to the project.  Initially we may not include a wiki as part of the Mantis installation.


> does the storage of wiki data go to the database or filesystem or both ?

This will depend on the Wiki engine used and may depend on how the user sets it up.  As far as Mantis is concerned, we don’t care.  Only the driver that integrates with a specific engine _may_ need to know about this (typically it shouldn’t).


> From my point of view, I’m not sure I necessarily see having wiki links as a benefit – The danger I see is that at

> the moment, it is clear by looking at a page exactly what an issue is about – having a separate page to go to,

> means that information might get missed.


I’ve planning to have an icon show up on the page (similar to the sponsorship icon) that appears when the page already has a wiki page associated with it.  This will altert the user to visit the wiki for details.  I would also expect notes to be referring to the wiki page, if it exists.


> *IF* the intention is to ship the functionality with mantis as a core product, I’d be inclined to do the following:


> * Take a wiki library, that provides the link/formatting functionality

> * In the same way that we have a collapsible div frame etc for notes, where a wiki document exists related to a given bug, create a new collapsible window which contains an IFRAME (is this too nasty?), into which you provide the linked pages.

> * Any Updates/Creation of wiki pages should update the issue history

> * It should be possible to both store the wiki content against the filesystem, and against the adodb database.


There is a lot of features in a wiki that won’t be available by using a rendering option.  Creating a web of pages, revision history, search, etc.  I think we will gain more by integrating with a proper wiki.


> I quite like wiki’s in terms of quickly linking groups of pages together, I’m just trying to work out whether

> what we’re trying to implement is to allow someone to link a group of wiki pages to a bug containing a

> specification, OR to allow users to format text that they provide as a description of an issue.


My goal is to provide a way to include detailed documentation and design, my goal is not just a way of formatting text.