projectdoc assumes that spaces are created frequently. If you want to de=
lve into a new topic, alone or with your team, it is easy to create a new s=
pace to copy all the new information into. After you have found all the inf=
ormation you need, you may then decide whether you want to reorganize your =
current space, move the most relevant information to another space, or arch=
ive the working space. This frees your mind from constantly considering whe=
re to place a particular information in an area of knowledge you are not ye=
t familiar with.
The Core Add-on provides four kinds of space blu=
eprints for organizing information:
- The workspace is designed to store information as you go and b=
e probably archived at the end of your research.
- The topic space is designed to keep information that is releva=
nt for you and your team for a longer period of time.
- The index space is designed to hold common information, like the tags a=
nd types to use.
- The attachment space is designed to hold specific information, like a l=
ibrary or an address book.
Workspaces are quick-and-easy and will not require any maintenance. Topi=
c spaces are used to organize information for your team so expect to have t=
ime to budget to constantly work on this space. The information in topic sp=
aces needs to be kept up-to-date. For more information on space types, plea=
se refer to Using Spaces.
Each of our add-ons for projectdoc typic=
ally provide one or more space blueprints. These spaces help teams to organ=
ize their information quickly. Spaces are designed to be created and ready =
to work with.
Document Typ=
es and Templates
A document type is a logical concept, while a page blueprint is an implementation =
of a document type in Confluence. We use the te=
rms page blueprint and template often interchangeably and=
always refer to the implementation that is the basis for creating a new do=
cument of a given type. Strictly speaking a page blueprint may contain a co=
llection of templates. Often the collection contains only one template.
The document itself is sometimes called document instance to di=
stinguish it from the document type.
A projectdoc document is a Confluence page with properties and sections. Every projectdoc d=
ocument is a Confluence page, but it is not required that every Confluence =
page is a projectdoc document. Confluence pages that are not projectdoc doc=
uments are not take into account for searches (for example with the Display Table Macro)=
by the projectdoc add-on.
projectdoc specifies a simple property called Doctype<=
/em> to define the document type for a document instance. The property is p=
art of the Document Properties Marker Macro that is required on the top of =
every projectdoc document. In addition to the property, a Confluence page a=
lso requires a label with the document type's value.
Doctype Homepages
The documents of a given doctype are organized in homepages. Most of the=
doctypes have a homepage where the central documents of their types are st=
ored. For each doctype that provides a homepage, the blueprint wizard to cr=
eate a document provides a checkbox to store the new document as a child of=
the doctype homepage.
Confluence index pages collect each document created with a given bluepr=
int wizard. Homepages of doctypes reference only those documents that are s=
end to them. There are two kinds of documents that are not stored on the ho=
mepage:
- documents that are children of a document of the same type (with their =
root parent being a child of the doctype homepage)
- documents that are children of documents a different type
While the first imposes a natural organization of documents and subdocum=
ents (think of roles where the subdocuments refer to specialized roles of t=
heir parents), the second usage implies a close relationship between the do=
cuments. This close relationship defines that the subdocument has to be del=
eted when the parent document is deleted. That is: they have the same lifes=
pan.
Homepages may change their structure over time. Some doctypes will only =
contain a very limited number of documents (e.g. their are typically only a=
few roles in a small project), but others may have large numbers (e.g. the=
minutes of meetings may get plenty for larger teams). Therefore expect tha=
t the homepage may have subpages to organize documents matching certain cri=
teria. The documents will always be stored as children of the type homepage=
.
Delegate Space
Some documents are relevant to more than one space. If you have a large =
project with multiple large components you may want to have a space for eac=
h component you describe. Each component may share the same roles and topic=
types. So there is no need to have them copied around spaces. Instead have=
them stored in a collaboratively used delegate space. The index s=
pace is by definition a default delegate space. But you may declare any spa=
ce as the delegate space of a given space by adding the space property Delegate Space.
Once you have one (or more) delegate space(s) declared, you may remove t=
he homepages of those document types you want to store in the delegate spac=
e. If a user selects as the target location of a new page via the "Send to =
Homepage" parameter, projectdoc automatically selects the homepage from the=
nearest delegate space.
Search Space
The search space is defined by the Search Space space property. It defines for all =
projectdoc query macros the spaces to search for documents. Per default the=
search space is the same as the delegate space. You may change that by the=
use of the space property Use Delegate Space as Search Space.
If you want to list all documents with some criteria of a given doctype,=
then all documents from the spaces listed as search space that match these=
criteria are in the result set.