Differences

This shows you the differences between two versions of the page.

--- framework_data_governance [2026/06/01 00:34] – [Update management (needs_update)] sophie
+++ framework_data_governance [2026/07/20 21:37] (current) – [Update management (needs_update)] marie
@@ Line 2: / Line 2: @@
 ## 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)
@@ Line 15: / Line 14: @@
 | 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 needs_update, Archive (upon decision of the steering committee) | @maintainers |
+| Maintainers | Ensure consistency between pages and monitor validation processes, Verify the data lifecycle, Raise alerts | Edit pages, Mark as `needs_update`, Archive (upon decision of the steering committee) | @maintainers |
-| Technical Review | Technical review / Data LCA | Approve level 1a (technical quality), Mark as needs_update |  @technical review |
+| Technical Review | Technical review / Data LCA | Approve level 1a (technical quality), Mark as `needs_update` |  @technical review |
-| Content Review | Check clarity and editorial quality (popularisation) | Approve level 1b (editorial quality), Mark as needs_update | @content 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 |
+| Support | Manage user feedback | Collect feedback. Mark as `needs_update` | @support |
 | Users | Use the data | View only | @members |
@@ Line 36: / Line 35: @@
 **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
@@ Line 55: / Line 55: @@
 Overview
-image à incerer
+{{ :framework_data_governance.png?direct |}}
 ### Page statuses
@@ Line 106: / Line 108: @@
 **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`)
-### 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**.
@@ Line 116: / Line 117: @@
 | deprecated | Content obsolete, no replacement | Marked and archived |
 | New draft | Major changes / overhaul | Create new page (old one will be automatically superseded) |
 ### Update management (needs_update)
-à ajouter
+  -  An authorised user marks the page as `needs update`
+  -  A discussion begins with the person who flagged the need for a change, who then changes the status to `update review`
+  - If the discussion confirms the need, the status changes to `update confirmation` and the **management committee** assigns a lead (after consulting the relevant **project manager**)
+    - The assigned manager changes the page to ‘draft’ and makes the changes
+    - The page returns to the normal validation cycle
+  - If the update is not necessary, no action is taken.
+  - If an update is required because the data is obsolete, but no project is feasible to replace it, the management committee is notified to decide whether the data should be deprecated.
+### Transition from deprecated towards superseded
+When a newly published page explicitly references a deprecated page as its replacement, the transition to ‘superseded’ is **automatic**.
+### End-of-life process
+Description of the end-of-life process for the data and its associated documentation page.
+^ Stage ^ Duration ^ Actions ^ Communication ^
+| Decision | - | Steering Committee approves deprecation | CR meeting |
+| Announcement | 3 months | ‘Deprecated’ tag, warning banner | Email to users |
+| Transition | 3–6 months | Migration support, redirection if superseded | FAQ, documentation |
+| Archiving | - | Maintainer moves to archive (upon decision of the Steering Committee) | Final notification |
+### Dashboards
+All dashboards required for the knowledge base to function properly.
+^ Dashboard ^ Description ^ Recipients ^
+| My Actions | Pages awaiting my action, based on my role(s) | All roles |
+| Steering Committee | Approved pages, awaiting publication decision | @steering |
+| Technical Review | Ready_for_approval pages, to be technically validated | @technical review |
+| Content Review | Tech-approved pages, to be editorially validated | @content review |
+| Interoperability Task | Approved data, to be made interoperable | @interoperability manager |
+| Packaging task | Validated data, to be made exportable | @packager |
+| Maintenance view | Pages with confirmed updates and pages to be archived | @maintainers |
+| My drafts | Drafts in progress for producers/documenters | @producers, @documenters |
+| Support | Feedback to be processed, flagged pages | @support |
+| List of update requests | List of update requests to be processed and initiation of discussions | @users, @maintainers |
+| Communications | Pages that have been modified/added/archived, requiring an announcement | @communicators |
+### Technical Proposal
+Proposal for technical components to implement the proposed lifecycle.
+**Plugins**
+  - **Approve** (https://www.dokuwiki.org/plugin:approve): Management of permissions, groups and file history
+    - Prerequisites: SQLite to manage the approval process
+    - **Note**: Check compatibility with the `tech_approved` status and the two-stage workflow
+  - **Notification** (https://www.dokuwiki.org/plugin:notification): Notify the various stakeholders of expected actions
+### Rights matrix
+Overview of the rights associated with each of the roles implemented in DokuWiki.
+^ Action ^ Producers ^ Documenters ^ Maintainers ^ Technical Review ^ Content Review ^ Interoperability Manager ^ Steering Committee ^ Packager ^ Communicator ^ Support ^  ^ Users ^
+| Create a page (draft) | yes | yes |  |  |  |  |  |  |  |  |  |
+| Edit a draft | yes | yes | yes |  |  |  |  |  |  |  |  |
+| Submit for validation | yes | yes | yes |  |  |  |  |  |  |  |  |
+| Approve level 1a (technical) |  |  |  | yes |  |  |  |  |  |  |  |
+| Approve level 1b (drafting) |  |  |  |  | yes |  |  |  |  |  |  |
+| Make interoperable |  |  |  |  |  | yes |  |  |  |  |  |
+| Approve Level 2 (publication) |  |  |  |  |  |  | yes |  |  |  |  |
+| Mark as packaged |  |  |  |  |  |  |  | yes |  |  |  |
+| Assign updates |  |  |  |  |  |  | yes |  |  |  |  |
+| Mark needs update | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes |
+| Mark update review discussion |  |  | yes |  |  |  |  |  |  |  |  |
+| Mark Update confirmation |  |  | yes |  |  | yes |  |  |  |  |  |
+| Mark deprecated |  |  |  |  |  |  | yes |  |  |  |  |
+| Archive (upon SC decision) |  |  | yes |  |  |  |  |  |  |  |  |
+| View published pages | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes |
+| View archives | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes |
+## Correspondence with DokuWiki groups
+^ DokuWiki Group ^ Permissions ^
+| @producers | Create, edit drafts, submit, view (published and archive) |
+| @documenters | Create, edit drafts, submit, view (published and archive) |
+| @maintainers | Edit drafts, submit, mark as needs update, archive, view (published and archive) |
+| @technical review | Approve level 1a, mark as needs update, view (published and archive) |
+| @content review | Approve level 1b, mark as needs update, view (published and archives) |
+| @steering | Approve level 2, assign updates, mark as deprecated, view (published and archives) |
+| @members | View published pages and archives |
+## Conclusion
+This document has outlined the data lifecycle and the associated documentation pages that will be integrated into the DocuWiki tool. As such, all functional and organisational roles, along with their associated rights, have been defined. The proposed processes for validating and updating the knowledge base content have also been described.
-  - test
-  * test