**This is an old revision of the document!**
Governance Processes and the Lifecycle of Data and Associated Documentation
Introduction
\ The purpose of this document is to outline the data lifecycle and the associated documentation within the framework of data governance for the naKnow organisation’s knowledge base. Topics covered include the definition of the various roles involved, their rights, the lifecycle of data and data documentation pages, as well as all the associated validation and update processes. Functional roles are assigned within the project team, with the method left to the discretion of those involved. By contrast, organisational roles (project manager and partner manager) are assigned by the management committee.
Roles
\
Functional roles (with DokuWiki group)
This section describes the various roles associated with groups within the technical infrastructure. It is important to note that a single individual may hold several roles simultaneously.
| Role | Description | Actions | DokuWiki group |
|---|---|---|---|
| Producers | Create raw scientific content (research, experiments) | Create/edit pages | @producers |
| Documenters | Format content into a standard format (on the same pages as the Producers). Aim to make content accessible to a wider audience. A parallel can be drawn with editors in the scientific process | Edit pages, finalise drafting | @documenters |
| Maintainers | Ensure consistency between pages and monitor validation processes, Verify the data lifecycle, Raise alerts | Edit pages, Mark as needsupdate, Archive (upon decision of the steering committee) | @maintainers | | Technical Review | Technical review / Data LCA | Approve level 1a (technical quality), Mark as needsupdate | @technical review |
| Content Review | Check clarity and editorial quality (popularisation) | Approve level 1b (editorial quality), Mark as needs_update | @content review |
| Interoperability manager | Ensure compatibility between data and calculators to guarantee their integrated operation within the naKnow ecosystem | Convert data format for interoperability between calculators | @interoperability manager |
| Steering Committee (SC) | Validate strategy, coordinate | Approve Level 2 (publication). Assign updates. Mark as deprecated | @steering |
| Packager | Ensure data is formatted to be compatible with other databases/software | Convert data format for export prior to publication | @packager |
| Communicator | Inform the community of updates, archiving and changes made to the database | Communicate changes within the database | @communicator |
| Support | Manage user feedback | Collect feedback. Mark as needs update | @support |
| Users | Use the data | View only | @members |
Note: The role of packager could just as easily be fulfilled within naKnow, or by the developers of the tools or databases that wish to integrate with it.
Organisational roles (without a DokuWiki group)
The roles required for the organisation but which do not require a specific rights group within the infrastructure are as follows:
| Role | Description | Actions | Link to DokuWiki |
|---|---|---|---|
| Project Leaders | Lead and manage a specific technical area | Oversee, document decisions, consulted by the management committee regarding assignments | Coordination outside the wiki |
| Partner Manager | Source data from research organisations / industry | Coordinate with external parties | Coordination outside the wiki |
Note: Project managers have autonomy over decisions within their own areas of responsibility. The management committee handles cross-functional decisions and consults with them to assign updates.
DokuWiki Groups
Summary of the groups to be created within DokuWiki corresponding to the various roles.
| Group | Description | Typical members |
|---|---|---|
| @producers | Raw content producers | Researchers, analysts |
| @documenters | Technical writers | Writers, popularisers |
| @maintainers | Maintainers | Update and archiving managers |
| @technical review | Technical review | Senior experts |
| @content review | Editorial approvers | Proofreaders |
| @interoperability manager | Standardisation of template format (in naKnow) | Developers |
| @steering | Steering Committee | Decision-makers, representatives |
| @packager | Export format conversion | Developers |
| @communicator | User notifications | Communications team |
| @support | User support | Customer support team |
Page lifecycle
Overview image à incerer
Page statuses
Tags associated with documentation pages intended for the general public. Their purpose is to inform the user and do not necessarily correspond to a stage in the data lifecycle. The date of the last tag change will be accompanied by a modification date to enable the user to track the page’s timeline. The validity period for pages is set at one year, after which they are automatically set to ‘needs_update’. However, individual teams may choose to extend or reduce this period based on their expertise.
| Status | Description | Visible to | Action required |
|---|---|---|---|
| needs update | Update identified as necessary | Contributors | Discuss the need for an update |
| under review | Currently being updated | Everyone | Await review result |
| deprecated | Obsolete, do not use (no current replacement) | Everyone (with warning) | None |
| superseded | Replaced by a new version | Everyone (automatic redirection) | Follow the redirection |
| archived | Archived for historical purposes | Everyone | None (view archive) |
Data statuses
Tags for internal data lifecycle management.
| Status | Description | Visible to | Action required |
|---|---|---|---|
| draft | Proposal for new data or modification | Contributors | Submit a proposal |
| ready for approval | Data submitted for validation, awaiting technical review | Contributors, Reviewers | Await technical review |
| tech approved | Technically validated, awaiting editorial validation | Contributors, Reviewers | Await Content Review validation |
| approved | Technically validated AND correctly documented | Contributors, Interoperability Manager | Await interoperability work |
| interoperable | Data provided is interoperable with the ecosystem | Contributors, Steering | Await Steering validation |
| validated | Approved by the Executive Committee | Contributors, Steering | Ready for packaging |
| packaged | Packaged for export | Contributors, Steering | Ready for publication |
| published | Data published | Everyone | None |
| needs update | Update identified as necessary | Contributors, maintainers | Await review of request |
| update review | Assessment of actual need for identified update | Contributors, maintainers | Await confirmation of need |
| update confirmation | Validation of need to initiate an update | All | Await assignment by the steering committee |
| deprecated | Obsolete, no longer in use (no current replacement) | All (with warning) | None |
| superseded | Replaced by new version | All (automatic redirection) | Follow redirection |
| archived | Archived for historical purposes | All | None (archive consultation) |
Who can flag a page as needing updating
All stakeholders. As any stakeholder can flag a page as needing updating, a discussion is initiated to assess whether an update is actually required before the process is formally launched. This discussion can be started in the wiki comments.
Details of the validation process
| Stage | Resulting status | Role | In case of rejection |
|---|---|---|---|
| Submission | ready for approval | Producer / Documenter / Maintainer | - |
| Technical validation | tech approved | Technical Review | Returned as draft (technical corrections) |
| Interoperability work | interop implementation | Interoperability manager | Remains techapproved (compatibility corrections only) | | Editorial validation | approved | Content Review | Remains techapproved (text corrections only) |
| Strategic validation | validated | Steering Committee | Return draft if major revisions |
| Packaging | packaged | Packager | - |
| Publication | published | Automatic after the packaging phase | - |
Key point: The tech_approved status remains after editorial rejection. Only textual corrections are required; technical validation is not needed again (unless the technical content is modified).
Periodic review (needs_update)
The periodic review is triggered by the data lifecycle. The content is marked as requiring an update. If the need for an update is confirmed, the new page is not visible to @members.
| Status | Condition | Action |
|---|---|---|
| Published OK | Content still valid | No changes required |
| update_confirmation | Changes required | Assigned by the management committee (after consultation with the project manager), returned to draft |
| deprecated | Content obsolete, no replacement | Marked and archived |
| New draft | Major changes / overhaul | Create new page (old one will be automatically superseded) |
Discussion