Hello Naoki,

Thank you for your question.
Let me try to express our way of thinking when designing Publication Hub.

When we designed Publication Hub, our goal was to offer practical solutions to customers’ everyday challenges. Recognizing that each organization and team has unique working styles, we focused on addressing fundamental needs. We envisioned Publication Hub as a platform where publication leaders could initiate projects, form teams, and monitor the progress of the publication creation process. Tracking this progress is crucial not only for the publication leaders but for everyone within the organization.

You can imagine an in-office variant of the Publication Hub as a whiteboard with a list of currently running projects and assigned responsible people for each of them. Often, the assignment representatives are leaders of different teams: Writers, Reviewers, SMEs, and Linguists. These leaders organize the process around the publication release within the context of their area of responsibility.

In the end, it might and usually will require the involvement of more people to cover activities in their area. Each contributor performs their own task(s). Usually, the general process of releasing a publication is not linear. Content can be reviewed and sent back to the editing phase, while some parts can already be sent for translation. After that, the translation review process could also be mixed into the list. So, there are usually multiple parallel tracks that are ongoing.

You can visualize such tracks in project management tools like Jira as separate stories of your epic (publication release) that have tasks with dependencies between each other. Tasks will have assignments and can be moved back and forth on the dashboard. You can imagine how complex it might be to build a proper project management tool, taking into account various requirements and needs of different customers and their teams. Instead, as mentioned above, we focused on essential needs.

The parallel tracks are represented as assignments to the project, usually led by team leaders. As soon as a track is finished, it should be signed off by the responsible person. When all tracks are signed off, the project is closed.

Assuming that you could extend the list of project states while it is not possible currently, what action would trigger a project state change? Is it the sign-off action from a specific person, for example, the Lead Writer? Or maybe the Publication Captain would be responsible for moving the project between states?

What is your process of releasing a publication? Is it linear? Do you have cases when a publication might need to be moved back in the workflow process, like Editing -> Reviewing -> Editing?

By the way, I recommend reading the blog from my colleague Gizem about the Publication Hub concept as well as watching a bootcamp recording:  Let's Make Your Work Easier: Meet Publication Hub!  

Hope that helps and makes sense. 

Hello Naoki,

Thank you for your question.
Let me try to express our way of thinking when designing Publication Hub.

When we designed Publication Hub, our goal was to offer practical solutions to customers’ everyday challenges. Recognizing that each organization and team has unique working styles, we focused on addressing fundamental needs. We envisioned Publication Hub as a platform where publication leaders could initiate projects, form teams, and monitor the progress of the publication creation process. Tracking this progress is crucial not only for the publication leaders but for everyone within the organization.

You can imagine an in-office variant of the Publication Hub as a whiteboard with a list of currently running projects and assigned responsible people for each of them. Often, the assignment representatives are leaders of different teams: Writers, Reviewers, SMEs, and Linguists. These leaders organize the process around the publication release within the context of their area of responsibility.

In the end, it might and usually will require the involvement of more people to cover activities in their area. Each contributor performs their own task(s). Usually, the general process of releasing a publication is not linear. Content can be reviewed and sent back to the editing phase, while some parts can already be sent for translation. After that, the translation review process could also be mixed into the list. So, there are usually multiple parallel tracks that are ongoing.

You can visualize such tracks in project management tools like Jira as separate stories of your epic (publication release) that have tasks with dependencies between each other. Tasks will have assignments and can be moved back and forth on the dashboard. You can imagine how complex it might be to build a proper project management tool, taking into account various requirements and needs of different customers and their teams. Instead, as mentioned above, we focused on essential needs.

The parallel tracks are represented as assignments to the project, usually led by team leaders. As soon as a track is finished, it should be signed off by the responsible person. When all tracks are signed off, the project is closed.

Assuming that you could extend the list of project states while it is not possible currently, what action would trigger a project state change? Is it the sign-off action from a specific person, for example, the Lead Writer? Or maybe the Publication Captain would be responsible for moving the project between states?

What is your process of releasing a publication? Is it linear? Do you have cases when a publication might need to be moved back in the workflow process, like Editing -> Reviewing -> Editing?

By the way, I recommend reading the blog from my colleague Gizem about the Publication Hub concept as well as watching a bootcamp recording:  Let's Make Your Work Easier: Meet Publication Hub!  

Hope that helps and makes sense. 

Hello Andriy,

I have read the blog post and watched the bootcamp video. As a non-native English speaker, I may have missed some important information. It would be helpful for Japanese users if this information were available in Japanese.

I understand that the Publication Hub specification was determined by balancing various requirements and policies. I would like to inquire about the possibility of customization.

I am not requesting major changes, but I would like to add some statuses to the Publication Hub and include an exporting function for the registered information. This would help us manage our documentation process more efficiently. For instance, if there are many 'Pending' jobs, the manager cannot tell if staff have started the work or if they missed the assignment. If staff are unaware of their assignments, the manager will need to inform them.

If customer-specific statuses can be added to the Publication Hub and if the information can be exported as an Excel or CSV file, we can reduce management time.

I hope this clarifies the customer's needs.

Hello Naoki,

If your requirements are not yet available in the product (new), you best raise them as ideas here:  Tridion Docs Ideas 
Other customers may have similar requests and can then join the conversation. This idea area is monitored by the Tridion Docs product team and these product ideas are considered (not guaranteed !) for inclusion on a regular basis.

Regards,
    John

Hello Naoki Hirai ,

Thank you for providing more information.

Indeed as John already mentioned it is best to raise product improvements/enhancements at Tridion Docs Ideas .
I saw that you already reported two for Publication Hub. 

Thank you for that.