A document type (doctype) defines the properties and section for document instances. It also provides home and index pages. In Confluence these doctypes are implemented as page blueprints, usually with one template. This template is used to create new pages in Confluence.
- Short Name
- Doctype
- Relation
When information needs to be written down immediately two questions arise.
- Where do I put this new document?
- How do I structure the information in this document?
Authors should not need to think hard to answer these two questions. They should focus on the content, the information that needs to be published and be made available to stakeholders.
Naturally the structure of a document also supports to deliver the information. Therefore authors are allowed to change the structure to fit their needs.
The goal of document types is to provide a structure that fits most use cases and which may be good enough for the communication with stakeholders.
A document type (doctype) defines the properties and section for document instances. It also provides homepages and index pages. In Confluence these doctypes are implemented as page blueprints, usually with one single template. This template is used to create new pages in Confluence.
Specializations
- Entity Document Type
- Instances of this type provide information on an entity of the domain.
- Organizing Document Type
- Instances of this type organize documents by providing metadata.
Resources
- Document Types and Templates
- Document types (or doctypes for short) define a set of properties and sections. Each doctype matches at least one Confluence Page Blueprint. Confluence Page Blueprints are a collection of templates, but often the collection contains only one element.
- Doctypes
- Doctypes define properties and sections for documents. They are essentially Confluence Blueprints that help to create pages in your wiki based on templates.
- Document Instance
- A projectdoc document instance is based on a document type. Documents are created using page wizards provided by blueprints.
- Doctypes Overview
- List of all doctypes provided by add-ons. Provides an overview over doctype IDs and blueprint keys.
The projectdoc Toolbox provides a number of document types as separate doctype add-ons.
Some of the blueprints listed here are not yet publicly available. Please check the doctype add-ons for actual availability!
| # | Name | Short Description | Suite |
|---|---|---|---|
| 1 | Credentials for development systems where the password is known to all who have access to the Confluence wiki. |
||
| 2 | Type-specific category for access information. |
||
| 3 | This documents a possible option for a decision. Choose this document type to describe the alternative for a decision in more detail. This is typically a subpage of a decision document. |
||
| 4 | Group your alternatives by a self-defined type. |
||
| 5 | Announcements are a way to communicate an important piece of information with your team. |
||
| 6 | Describe your vision for one year. You plan will help you stay focussed to accomplish your goals. |
||
| 7 | Categories for annual visions. |
||
| 8 | Document your app for your users and customers. |
||
| 9 | Provide more detailed information about a component of a tool. |
||
| 10 | Document the purpose and usage of the components of this type. |
||
| 11 | Document your extension for your users and customers. |
||
| 12 | Document the purpose and usage of the extension of this type. |
||
| 13 | Applications provided functions required by services. Applications may be hosted on one or more systems. |
||
| 14 | Type-specific category for applications. |
||
| 15 | Document the purpose and usage of the macro. |
||
| 16 | Document the purpose and usage of the macros of this type. |
||
| 17 | A parameter is a configuration option. Parameter exist on different layers. Wizard and macro parameters are configuration options. Use |
||
| 18 | Document the purpose and usage of the app parameters of this type. |
||
| 19 | Document a platform for apps. |
||
| 20 | Document the purpose and usage of the platforms of this type. |
||
| 21 | Document a service provided by an app. |
||
| 22 | Document the purpose and usage of the app services of this type. |
||
| 23 | Document a tool provided by an app. |
||
| 24 | Document the purpose and usage of the app tools of this type. |
||
| 25 | Document the purpose and usage of the apps of this type. |
||
| 26 | The blueprint of the arc42 Template creates a tree of pages in the Confluence space. |
||
| 27 | Document a possible option for an architecture decision. Choose this document type to describe the alternative for a decision in more detail. This is typically a subpage of an architecture decision document. |
||
| 28 | Group architecture alternatives by their type. |
||
| 29 | Document an aspect of your architecture. Something orthogonal or cross-functional like logging, exception handling or configurability. |
||
| 30 | Group architecture aspects by their type. |
||
| 31 | The second chapter of the arc42 Template with information on constraints and conventions. |
||
| 32 | Document a architecture decision for an option. This is useful to state the reasons and the options that have been evaluated. Later other team members will have it easier to understand the decision. |
||
| 33 | Architecture decisions are group by their types. A commonly used decision type is 'Architecture'. |
||
| 34 | Document requirements you impose on artifacts. Artifacts are created by processes defined and used by the team. This includes assemblies created by the build process, source code artifacts or reports. |
||
| 35 | Artifact types categorize artifacts. |
||
| 36 | Explain an asset of your work. Add this document to a day in your diary. |
||
| 37 | Categories for assets. |
||
| 38 | Associates two documents. |
||
| 39 | Categorize associations by a type. |
||
| 40 | Document assumptions to assess risks and opportunities for the project. |
||
| 41 | Assumptions are grouped by their type. |
||
| 42 | Describe as a Blackbox the elements of a view where only the externally visible properties are relevant. |
||
| 43 | Group blackboxes by their type. |
||
| 44 | The blank template simply provides a minimal integration with projectdoc features. It is a quick starting point to use projectdoc. |
Native |
|
| 45 | The bookmarklets editor is a simple page that allows teams to create their bookmarklets more easily. It also provides access to some standard bookmarklets provided for the projectdoc Toolbox. |
||
| 46 | The fifth chapter of the arc42 Template with information on the local building blocks, and their dependencies and relationships. |
||
| 47 | Categories allow to set document instance of different doctypes in a hierarchy. |
||
| 48 | Categorize categories by a type. |
||
| 49 | Document a single change to configuration items or assets. |
||
| 50 | Add an severity to classify changes. |
||
| 51 | Add a status to categorize changes. |
||
| 52 | Add a theme to group changes. |
||
| 53 | Type-specific category for changes. |
||
| 54 | Describes an information need and use this description as a basis to create and maintain a document. |
||
| 55 | Categorize charters by a type. |
||
| 56 | A brief solution to a problem. |
||
| 57 | Categories for cheats. |
||
| 58 | Checklists allow to run manual tasks in a defined manner. It guides the user of the checklist through a process and helping to not forget a step. |
||
| 59 | Categorize checklists by type. |
||
| 60 | Describe the codes that are part of the product's API. |
||
| 61 | Code types categorize codes, used in logging or exception handling. |
||
| 62 | Components are part of a view on a system. A component may refer to a enclosed element or to a complete system of its own. |
||
| 63 | Component types categorize components. |
||
| 64 | Configuration items (CIs) may be (sub-)systems or components. Whatever may change and needs to be tracked may be documented as a CI. |
||
| 65 | Signals the status of an IT system, application, or a configuration item. |
||
| 66 | Type-specific category for configuration items. |
||
| 67 | The eighth chapter of the arc42 Template with conceptional information about the system. |
||
| 68 | Add cycles to group cycle phases. |
||
| 69 | Cycle phases define phases that are bound to a cycle, such as lifecycles or iterations. |
||
| 70 | Datasets are used as the input and output of processes. |
||
| 71 | Type-specific category for datasets. |
||
| 72 | Document a data type for properties and codes. |
||
| 73 | Data type types categorize data types. |
||
| 74 | Store relevant information discovered today in your developer diary. |
||
| 75 | Categories for days. |
||
| 76 | Document a decision for an option. This is useful to state the reasons and the options that have been evaluated. Later other team members will have it easier to understand the decision. |
||
| 77 | Group your decisions by a self-defined type. |
||
| 78 | Deployments provide information about updates on services and systems to users. |
||
| 79 | Record a deployment to a IT system. |
||
| 80 | Type-specific category for deployment records. |
||
| 81 | Type-specific category for deployments. |
||
| 82 | The seventh chapter of the arc42 Template with information about how the system is deployed. |
||
| 83 | The ninth chapter of the arc42 Template that explains the architecture decisions that led to the system. |
||
| 84 | The homepage of a developer's daily diary pages. Consider to add your diary to your personal space! |
||
| 85 | Categories for diaries. |
||
| 86 | Document the usage of a doctype for your users. |
||
| 87 | Document the purpose and usage of the doctypes of this type. |
||
| 88 | Document the usage of a document property for your users. |
||
| 89 | Document the purpose and usage of the properties of this type. |
||
| 90 | Document the usage of a document section for your users. |
||
| 91 | Document the purpose and usage of the sections of this type. |
||
| 92 | Document logical or physical groups of nodes. |
||
| 93 | Type of an environment used by the project to deploy the application or the solution. |
||
| 94 | Associated an event with a day. A event is a collection of associated information for your later reference. Information may further be organized by subject, tags, categories, and audience. |
||
| 95 | Categories for events. |
||
| 96 | Excerpts are abstracts of information found in a resource, such as a book. If you want to go into more detail for a given resource, there may be multiple excerpts as subpages of the resource document. |
||
| 97 | Categorize excerpts by a type. |
||
| 98 | Defines the context through which readers acquire skills. The level sets the expectation on the author's techniques to teach. |
||
| 99 | Categorize experience levels by a type. |
||
| 100 | FAQs help to record an answer to a frequently asked question concerning the project, the product, the system or the process. |
||
| 101 | Categorize FAQs by a type. |
||
| 102 | Documents a feature of the product. The top features define the main aspects of the product. |
||
| 103 | Feature types categorize features. |
||
| 104 | Generic Documents provide information where no other doctype matches. |
||
| 105 | Categorize generic documents by a type. |
||
| 106 | The last chapter of the arc42 Template lists terms of the domain and explains them. |
||
| 107 | Glossary items are part of the domain glossary for the project. Glossaries support the team to use terms of the domain consistently in conversations and documentation. |
||
| 108 | Categorize glossary items by a type. |
||
| 109 | Improvement proposals help to start the conversation within the team for process improvements. |
||
| 110 | Interfaces document how elements of the system communicate with elements of this and other systems. |
||
| 111 | Group interfaces by their type. |
||
| 112 | The first chapter of the arc42 Template with information on requirements, quality goals, and stakeholders. |
||
| 113 | IT Activities define activities for processes. |
||
| 114 | Type-specific category for IT activities. |
||
| 115 | IT Assets define assets required or produced by processes. |
||
| 116 | Type-specific category for IT assets. |
||
| 117 | Document an Iteration that may be linked from JIRA. Allows the team to set the goal and add notes relevant to a particular iteration. |
||
| 118 | Functions are specialized organizational units to support business processes. |
||
| 119 | Type-specific category for IT functions. |
||
| 120 | IT Procedures define procedures for processes. |
||
| 121 | Type-specific category for IT procedures. |
||
| 122 | Processes organize activities to create a defined business value. |
||
| 123 | Type-specific category for IT processes. |
||
| 124 | IT Services provide business relevant services for customers. |
||
| 125 | Classifiers to categorize services. |
||
| 126 | Type-specific classification for IT services. |
||
| 127 | Signals the status of an IT Service. |
||
| 128 | Type-specific category for IT services. |
||
| 129 | Systems are part of environments where products are deployed to. |
||
| 130 | Systems are categorized by their type. These types may be quite concrete since systems by nature reference a hard- or software system usually by their IP address or DNS name. Therefore a system type may be 'Artifact Repository' or 'Virtual Server. And types may build hierarchies. |
||
| 131 | Add lifecycles to group lifecycle phases. |
||
| 132 | Lifecycle phases define phases that are bound to a lifecycle. |
||
| 133 | Locations provide information about the whereabouts of assets, configuration items, and systems. |
||
| 134 | Type-specific category for locations. |
||
| 135 | Resources are identified by their media type. This may be the MIME type, but also a human readable string, that identifies the syntactic format. |
||
| 136 | Categorize media types by their type. |
||
| 137 | Metadata documents provide tables of simple key/value pairs. This information can be used as an aspect or as additional space properties to be available for reference on your wiki. |
||
| 138 | Categorize metadata documents by a type. |
||
| 139 | Record the action items of a meeting. |
||
| 140 | Group your minutes by a self-defined type. |
||
| 141 | Define a mission for your company or product. |
||
| 142 | Type-specific category for mission statements. |
||
| 143 | A documentation module is a fragment which is usually transcluded by other documents. The lifetime of a module document is independent of the lifetimes of the documents that reference it. |
||
| 144 | Categorization of document modules for single sourcing. |
||
| 145 | Plan and run a retrospective for your month of work. |
||
| 146 | Categories for months. |
||
| 147 | Nodes are part of environments where artifacts are deployed to. |
||
| 148 | Node types categorize nodes. |
||
| 149 | Open issues document what the team needs to know to proceed. |
||
| 150 | Open issues are grouped by the severity of their impact on the project. |
||
| 151 | Open issues are grouped by the status. |
||
| 152 | Group your open issues by a self-defined type. |
||
| 153 | Document and track identified opportunities for the project. |
||
| 154 | Opportunities are grouped by their type. |
||
| 155 | Information about organizations that take a part in the project. You may collect common information here for all persons that belong to an organization, such as address or homepage. |
||
| 156 | Categorize organizations by a type. |
||
| 157 | Out Items record topics that are out of the scope of the project. This is useful for project inception and for reference in the future. |
||
| 158 | Out item types categorize out items. |
||
| 159 | Document the purpose and usage of a page blueprint. |
||
| 160 | Document the purpose and usage of the page blueprints of this type. |
||
| 161 | Patterns provide solutions for problems in a given context. Patterns are usefull in multiple areas such as design, architecture, documentation, or process. |
||
| 162 | Patterns are divided into different domains to group patterns. |
||
| 163 | Categorize patterns by type. |
||
| 164 | Provides information about a person. This includes contact information (important if the person is relevant for the team) or information about the competences (if the person is an author about a topic relevant for the project). |
||
| 165 | Categorize persons by a type. |
||
| 166 | Document problems as a means to communicate the details and to use the information for reviews and retrospections. |
||
| 167 | Problems are grouped by their type. |
||
| 168 | Impacts define how the results of processes affect the world. |
||
| 169 | Type-specific category for impacts. |
||
| 170 | Outcomes define the results of processes. |
||
| 171 | Type-specific category for outcomes. |
||
| 172 | Product Backlogs are means to collect user stories. |
||
| 173 | Profiles provide views on documents via delegation. |
||
| 174 | Categorize profiles by a type. |
||
| 175 | Project Constraints limit the options of a project. |
||
| 176 | Project constraint types categorize project constraints. |
||
| 177 | Project Rules are defined by the team to enhance the collaboration and to define project standards. |
||
| 178 | Categorize project rules by type. |
||
| 179 | Frame the vision for a project or iteration. |
||
| 180 | Types to categorize vision statements for projects. |
||
| 181 | Properties are part of the configuration options of a system. |
||
| 182 | Property types categorize properties of products, such as parameters or configuration options. |
||
| 183 | Qualities describe desired aspects of the product. |
||
| 184 | The tenth chapter of the arc42 Template that lists scenarios to systematically evaluate the architecture against the quality requirements. |
||
| 185 | Quality Scenarios document required qualities. |
||
| 186 | Quality scenario types categorize quality scenarios. |
||
| 187 | Documents a quality target for a product. |
||
| 188 | Group quality targets by their type. |
||
| 189 | Quotes relevant for the project. Allows to store the content and metadata to the quote. |
||
| 190 | Categorize quotes by a type. |
||
| 191 | Organizes glossary items. |
||
| 192 | Categorize relations by a type. |
||
| 193 | Releases document the changes that are applied to a published version of a service. |
||
| 194 | Document changes provided by a release of a product. |
||
| 195 | Group your release notes by a self-defined type. |
||
| 196 | Type-specific category for releases. |
||
| 197 | Reports document what the team has decided or done. This is a generic document. |
||
| 198 | Group your reports by a self-defined type. |
||
| 199 | Documents requirements of a product. |
||
| 200 | Categorization of requirements for a product. |
||
| 201 | Resources are books, webpages, videocasts relevant for the project. Add important information to your project about resources that lie outside the control of your team. |
||
| 202 | Resources are identified by their type. This is not the MIME type, but human readable string, that identifies the semantic, rather than the syntactic format. |
||
| 203 | Record the discussion of the team about their last iteration. |
||
| 204 | Plan and run your review meeting. |
||
| 205 | A single act to show on the review. Use this only if you have a lot to show or you want to reference the review results later. Often a simple numerated list is sufficient. |
||
| 206 | Document and track identified risks for the project. |
||
| 207 | Document actions to prevent or reduce the negative impact on exceptions on a project. |
||
| 208 | Risk actions are grouped by their type. |
||
| 209 | Risks are grouped by the phase of their impact on the project. |
||
| 210 | Risks are grouped by the probability of having impact on the project. |
||
| 211 | The eleventh chapter of the arc42 Template lists risks and technical debt. |
||
| 212 | Risks are grouped by the severity of their impact on the project. |
||
| 213 | Document targets of risks. |
||
| 214 | Risk tagets are grouped by their type. |
||
| 215 | Risks are grouped by their type. |
||
| 216 | Defines a role with its responsibilities, tasks and requirements. Roles are incorporated by stakeholders who take interest in the project. The are also used to define the audience for documents. |
||
| 217 | Categorize roles by a type. |
||
| 218 | The sixth chapter of the arc42 Template with runtime information about the architecture. |
||
| 219 | Sections of a document are typically part of a document. But the size of sections may vary. To support a team to write collaboratively on the documentation, a larger document may be subdivided into external section documents. |
||
| 220 | Categorize sections by a type. |
||
| 221 | Announcements communicate with stakeholders information about a service. |
||
| 222 | Type-specific category for service announcements. |
||
| 223 | Describe a service level for a service. |
||
| 224 | Provide information about a service level agreement (SLA). |
||
| 225 | Type-specific category for service level agreements. |
||
| 226 | Describe a requirement in terms of a service level. |
||
| 227 | Type-specific category for service level requirements. |
||
| 228 | Type-specific category for service levels. |
||
| 229 | The fourth chapter of the arc42 Template explains the solution idea. |
||
| 230 | Document the purpose and usage of a space blueprint. |
||
| 231 | Document the purpose and usage of the space blueprints of this type. |
||
| 232 | Compile other documents, yet space indices are themselves projectdoc documents. So they can be tagged and grouped. |
||
| 233 | Categorize space indexes by a type. |
||
| 234 | Space properties hold metadata of a space. They may be inherited by delegate spaces. |
||
| 235 | Document the purpose and usage of the space properties of this type. |
||
| 236 | A party that takes interest in a project. The stakeholder is either a real person, an organization or group, or represents a class of individuals, groups or organizations. |
||
| 237 | Categorize stakeholders by a type. |
||
| 238 | Describes a single step of an activity. A step is a generic document that is associated with a document that describes a process. It may be a test log or a howto. |
||
| 239 | Categorize steps by a type. |
||
| 240 | Defines a strategy for an organization or product. |
||
| 241 | Type-specific category for strategies. |
||
| 242 | Subject documents allow to set document instance of different doctypes in a common context. |
||
| 243 | Categorize subjects by a type. |
||
| 244 | Work on strengths, weaknesses, opportunities, and threats. |
||
| 245 | Type-specific category for SWOTs. |
||
| 246 | The third chapter of the arc42 Template with information on context and external interfaces. |
||
| 247 | Document the semantics of a tag. May also be used to document Confluence labels. |
||
| 248 | Categorize tags by a type. |
||
| 249 | Document processes defined and used by the team. |
||
| 250 | Categorize team processes by type. |
||
| 251 | Technical Debts track issues to be paid back. |
||
| 252 | Technical Debts are grouped by the area they address. |
||
| 253 | Document a test case of your project. |
||
| 254 | Test case types categorize test cases. |
||
| 255 | Defines a charter to run an exploratory test session. |
||
| 256 | Test charter types categorize test charters. |
||
| 257 | Document data used for test cases. |
||
| 258 | Test data types categorize test data. |
||
| 259 | Documents the results of a test session for the sponsoring stakeholders. |
||
| 260 | Test report types categorize test reports. |
||
| 261 | Defines a document to collect information during a test session. |
||
| 262 | Test session types categorize test sessions. |
||
| 263 | Add a todo note to your developer diary. |
||
| 264 | Categories for todos. |
||
| 265 | Document tools used by the team. Add information about how to fetch, install and best practices using it. |
||
| 266 | Categorize tools by type. |
||
| 267 | A description of a given topic. A topic may describing or explaining a concept, a task to accomplish or a reference. There are a couple of topic types that set the expectations for the reader. Instances of the topic doctype usually have independent lifetimes from any referencing documents. |
||
| 268 | A topic type is a semantic type of the topic. It helps to set the expectations of potential readers. |
||
| 269 | Guided tours through existing information. This allows to aggregate topics for a given question or audience, thus providing a view on a topic. |
||
| 270 | Triggers define signals for activities and processes. |
||
| 271 | Type-specific category for triggers. |
||
| 272 | Defines a use case of the product. |
||
| 273 | Use case types categorize use cases. |
||
| 274 | User Characters are the actors of user stories. They include personas and extreme characters. |
||
| 275 | User character types categorize user characters. |
||
| 276 | User Stories document a requirement of a stakeholder with a specific business goal. It also provides an acceptance test. It is a representation of a unit of work. |
||
| 277 | Document a version of a product or service. |
||
| 278 | Categorize versions by a type. |
||
| 279 | Different views on the product help to document the system and its architecture. Typical views are building block, runtime, or deployment. |
||
| 280 | Groups the views at a system. |
||
| 281 | Describe your vision for your career. |
||
| 282 | Define the vision for your organization or product. |
||
| 283 | Type-specific category for vision statements. |
||
| 284 | Categories for visions. |
||
| 285 | Plan and run a retrospective for your week of work. |
||
| 286 | Categories for weeks. |
||
| 287 | Describe as a Whitebox the elements of a view where only the relations of internal elements are relevant. |
||
| 288 | Group whiteboxes by their type. |
||
| 289 | Work Instructions define procedures for processes. Provide the most detailed information here how tasks are to be executed. This includes best practices. |
||
| 290 | Type-specific category for work instructions. |
||
| 291 | Create a year in your Diary. |
||
| 292 | Categories for years. |