I am just discovering XWiki and I am looking for some advice from more
experienced users on how to structure my wiki.
I am a data analyst at a hospital and would like to introduce a wiki into
our team. I feel XWiki is the best wiki engine for us to use because of the
WYSIWYG editor and the Office importer, which should help in the initial
adoption stage.
The aim of introducing a wiki would be to improve supporting documenting and
create more robust documentation on the following areas:
1. Definitions of measures - what it means, how it is calculated, what may
be excluded from this measure
2. Supporting user documentation to reports produced - how to navigate the
interactive reports, what the various graphs and charts represent
3. Document SQL databases/data warehouse - there are a whole host of
databases in the organisation that either no-one has no knowledge or one
person has knowledge of it. Documentation on the schemas, tables, views,
stored procedures, relationships etc.
4. Procedure information on how to produce reports - step by step on how to
produce a report extract. This documentation already exists in word
documents hosted in SharePoint libraries.
5. Technical documentation on how to produce reports - this would document
the inner workings DTS/SSIS packages or Microsoft Access databases that are
run as part of the procedure information.
Let me give you an example which may help you understand the situation
better.
There are various spreadsheet reports produced based on the number of weeks
patients have waited for treatment, referred to as 18 weeks, with numerous
measures used throughout.
The current documentation on how to produce these reports are split over
multiple word documents as the process is run in two stages on a Monday and
Thursday, both are very lengthy around 30 pages each. The documentation is a
step by step guide on how to produce the reports/extracts e.g. open this
file, copy and paste this, run this DTS package etc. To produce these
reports, another set of procedures need to be complete before as some of the
data produced by this process supports the 18 week process.
The entire process is based on a Microsoft Access database which an
ex-employee created and no-one knows anything about it's inner workings nor
is there any documentation on this database. Having looked at it briefly,
the database connects to an SQL server and uses data stored in some tables
which are produced by scheduled DTS packages - again which aren't
documented.
Thinking about how to logically store all this information within XWiki and
provide some clear structure, my thoughts were as follows:
Create virtual wikis which are based on the target audience/purpose
Create spaces for each of the subject areas/databases
Use tags to provide further categories, in particular for documenting
databases.
This would look something like this:
An XWiki for consumers of reports, this would contain documentation on
measures and supporting documentation on interpreting the various reports
produced. This wiki would be split into various spaces based on the subject
area, e.g. 18 Weeks, Inpatient, Outpatient.
An XWiki for procedural documentation on how to produce the various reports.
This would be split into various spaces based on the same subject areas as
the previous XWiki.
An XWiki for technical documentation on databases/DTS/SSIS packages. This
would be split into spaces for the various databases and would use tags to
distinguish between the different type of pages within the space e.g.
documentation on tables, views, stored procedures, functions.
Whilst the first two XWikis make sense and I don't see any issues with the
structure, it is the technical documentation part which I think may be
difficult to navigate. Perhaps the DTS/SSIS packages would need there own
XWiki as they are at a server level and not database level.
I am hopeful to hear your thoughts on the suggestions above.
Any help if greatly appreciated.
--
View this message in context:
http://xwiki.475771.n2.nabble.com/Looking-for-advise-on-structuring-XWiki-t…
Sent from the XWiki- Users mailing list archive at
Nabble.com.