Workflow management system: Difference between revisions
(Created page with "== Goal == * Take content from an internal project page, edit it and move it to the stakeholder side for a similar page. ** There may be politically and commercially sensitive content the team has uncovered on the internal side that has to be edited before it can be put into the more public stakeholder side of a project. *** We need a vetting/approval process between team leaders and facilitators in order to discuss what should be posted on the stakeholder side. *...") |
|||
(6 intermediate revisions by the same user not shown) | |||
Line 9: | Line 9: | ||
** Figure out the appropriate info and questions to ply stakeholders into contributing. | ** Figure out the appropriate info and questions to ply stakeholders into contributing. | ||
** Right now this is done via the IntelliSynthesis Q and A model. The KB should take that Q and A model alittle further. | ** Right now this is done via the IntelliSynthesis Q and A model. The KB should take that Q and A model alittle further. | ||
* Include notification system and workflow reporting metrics | |||
== Workflow Process == | |||
Specific to staging and transferring pages from the Internal side to the Stakeholder side | |||
* Four levels of participators | |||
*# Chief Facilitator: approves a page for transfer to the Stakeholder side | |||
*# Chief Subject/Page facilitator: Responsible for page being reviewed and moved to stakeholder side | |||
*# Facilitator: Any facilitator who may be involved in page review process | |||
*# Security administrator: insures that when page is transferred to the stakeholder side, that there are no security leaks that allow a faciliatory to get to the Internal side | |||
* Four versions of a page | |||
*# Draft: lives on the internal side only and is the functional place where facilitator record information about the subject | |||
*# Review: Page has been put into review mode for so the internal team can consider it for transfer to the stakeholder side | |||
*# Approved: Approved for transfer | |||
*# Transfer: Actually transferred | |||
== Questions and Answers == | == Questions and Answers == | ||
Line 31: | Line 47: | ||
- Define the workflow stages and transitions based on your knowledge base's requirements. Common stages might include: | - Define the workflow stages and transitions based on your knowledge base's requirements. Common stages might include: | ||
- Draft: The initial stage where users create and edit pages. | '''- Draft: The initial stage where users create and edit pages.(keep this page as the internal page for future use)''' | ||
- Review: The stage where designated reviewers assess the content for accuracy and quality. | ''' - Review: The stage where designated reviewers assess the content for accuracy and quality.''' | ||
- Approved: The final stage where the content is approved and becomes visible to all users. | ''' - Approved: The final stage where the content is approved and becomes visible to all users.''' | ||
- Determine the user roles and permissions associated with each stage. For example, who can create drafts, who can review, and who can approve. | - Determine the user roles and permissions associated with each stage. For example, who can create drafts, who can review, and who can approve. | ||
'''- Primary subject facilitator''' | |||
'''- Chief editor''' | |||
'''- Staff assistant''' | |||
4. Workflow Configuration: | 4. Workflow Configuration: | ||
Line 75: | Line 97: | ||
- Consider integrating the workflow management system with other tools or extensions used in your knowledge base. | - Consider integrating the workflow management system with other tools or extensions used in your knowledge base. | ||
- For example, you can integrate with a notification system to send alerts when workflow events occur or with a reporting tool to generate workflow-related metrics. | - For example, you can '''integrate with a notification system''' to send alerts when workflow events occur or with a reporting tool to generate workflow-related metrics. | ||
== Notes == | |||
=== [[Facilitator:Staging Processes|Staging Process]] === | |||
* Staging is what staff do when they prepare pages and content for publication in stakeholder KBs. | |||
* This is where we plan and operate staging techniques | |||
* It seems like the easiest way to get started with staging is to have pages with the prefix: stage. The facilitator for that subject goes in there and puts inn content for the stakeholder page its going to become and when the facilitator is ready to go public with it he converts it to that named stakeholder page. |
Latest revision as of 12:33, 20 June 2024
Goal
- Take content from an internal project page, edit it and move it to the stakeholder side for a similar page.
- There may be politically and commercially sensitive content the team has uncovered on the internal side that has to be edited before it can be put into the more public stakeholder side of a project.
- We need a vetting/approval process between team leaders and facilitators in order to discuss what should be posted on the stakeholder side.
- There may be politically and commercially sensitive content the team has uncovered on the internal side that has to be edited before it can be put into the more public stakeholder side of a project.
- Generate content on Stakeholder KBs that engage them with SRF staff in developing the project.
- Information stakeholders might be willing to input into their side of the KB in addition to us going out and finding it.
- Figure out the appropriate info and questions to ply stakeholders into contributing.
- Right now this is done via the IntelliSynthesis Q and A model. The KB should take that Q and A model alittle further.
- Include notification system and workflow reporting metrics
Workflow Process
Specific to staging and transferring pages from the Internal side to the Stakeholder side
- Four levels of participators
- Chief Facilitator: approves a page for transfer to the Stakeholder side
- Chief Subject/Page facilitator: Responsible for page being reviewed and moved to stakeholder side
- Facilitator: Any facilitator who may be involved in page review process
- Security administrator: insures that when page is transferred to the stakeholder side, that there are no security leaks that allow a faciliatory to get to the Internal side
- Four versions of a page
- Draft: lives on the internal side only and is the functional place where facilitator record information about the subject
- Review: Page has been put into review mode for so the internal team can consider it for transfer to the stakeholder side
- Approved: Approved for transfer
- Transfer: Actually transferred
Questions and Answers
Generated on claude.ai: How do I design workflow management into a MediaWiki knowledge base?
1. Extension Selection:
- Choose a workflow management extension that suits your requirements. Some popular options include:
- Approve: Allows users to submit pages for approval and enables designated approvers to review and approve or reject the changes.
- Workflow: Provides a flexible workflow system with customizable states and transitions.
- SemanticWorkflow: Integrates with Semantic MediaWiki to enable workflow functionality based on semantic properties.
2. Extension Installation:
- Ensure that the extension is compatible with your MediaWiki version.
3. Workflow Design:
- Define the workflow stages and transitions based on your knowledge base's requirements. Common stages might include:
- Draft: The initial stage where users create and edit pages.(keep this page as the internal page for future use)
- Review: The stage where designated reviewers assess the content for accuracy and quality.
- Approved: The final stage where the content is approved and becomes visible to all users.
- Determine the user roles and permissions associated with each stage. For example, who can create drafts, who can review, and who can approve.
- Primary subject facilitator
- Chief editor
- Staff assistant
4. Workflow Configuration:
- Configure the installed workflow extension according to your designed workflow.
- Define the workflow states, transitions, and user permissions using the extension's configuration options.
- Customize notification settings to inform relevant users about workflow events, such as when a page is submitted for review or approved.
5. Template Modification:
- Modify the templates used in your knowledge base to incorporate workflow-related elements.
- Add placeholders for workflow metadata, such as the current workflow state, the assignee for review, or the approval date.
- Customize the templates to display workflow-specific actions, such as buttons to submit for review or approve changes.
6. User Training:
- Educate your users about the workflow process and their roles within it.
- Provide documentation or training sessions to explain how to create, edit, and manage pages using the workflow system.
- Encourage users to follow the defined workflow stages and provide feedback on the process.
7. Monitoring and Refinement:
- Regularly monitor the usage and effectiveness of the workflow system.
- Gather feedback from users and analyze the workflow data to identify any bottlenecks or areas for improvement.
- Refine the workflow configuration and templates based on the insights gained from monitoring and user feedback.
8. Integration with Other Tools:
- Consider integrating the workflow management system with other tools or extensions used in your knowledge base.
- For example, you can integrate with a notification system to send alerts when workflow events occur or with a reporting tool to generate workflow-related metrics.
Notes
Staging Process
- Staging is what staff do when they prepare pages and content for publication in stakeholder KBs.
- This is where we plan and operate staging techniques
- It seems like the easiest way to get started with staging is to have pages with the prefix: stage. The facilitator for that subject goes in there and puts inn content for the stakeholder page its going to become and when the facilitator is ready to go public with it he converts it to that named stakeholder page.