Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kriya and process implications: Versioning and history information and dates #26

Open
Melissa37 opened this issue Aug 11, 2016 · 2 comments

Comments

@Melissa37
Copy link

See 0bc1262

This new requirement has big implications for the workflow.

  • Exeter will need to know of ALL previous versions of PoA content and add them to the XML (dates of publication and URL links)
  • Kriya will require the addition of two new fields - publication date for PoA'd content (add the new VoR date)
  • Kriya will need a new field so production can add a note if publishing a new version of a VoR so they can indicate the changes made
@gnott
Copy link
Member

gnott commented Aug 12, 2016

These dates could be all available from Lax I think. Is it possible ExeterPremedia can consume that data directly?

We could also look at whether this can be added automatically to the XML by the bot when it is processed.

Can we discuss on our next call agenda?

@Melissa37
Copy link
Author

Yes lets chat about it on Tuesday - I did think option 1 would be easiest, but the need to add comments to versions would probably prevent that.

The main problem for Exeter would be PoA versions and picking up versions of PoA, and also the comments production would add.

This is also an issue for the PoA workflow too - if we do a V2 adding a comment about the change.

@gnott gnott removed their assignment Mar 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants