Cheers Dennis, Ryan and Chris.
Agreed we should separate out software components and behaviours and characteristics and thanks for taking that on, Ryan.
To position the document, it was meant for the purpose of sparking up this debate. It includes all sorts and types of things at the moment. I find it helpful to look at the more standard deliverables such as users, user stories, sub systems, requirements and architecture against this type of document later on to make sure we haven't missed anything.
Dennis, here a quick answer to your questions:
- The overrides node captures the principle of overriding files we have discussed, i.e. the files which could be created by a developer and would be placed into the bespoke folder when the output is published. We mentioned that this could be customised versions of core JS/CSS files, which would override core code and this could also be used to place resources, such as PDFs, word docs etc into the published output.
- The maintain node captures the period of a project's lifecycle where it has been released and the time at which it's archived. In other words the project or course remains active and editable in the system after having been signed-off and released. There may not be any specific functionality attached to this period but I thought it might be useful to reflect this period in the design of the workflow. The use cases I can imagine are that content graphics may be replaced, typos may be fixed and new releases or version of the course may be created. Also, some organisations may decide never to delete or archive projects. Either way, if this workflow stage existed, developers could attach triggers for workflow plug-ins directly to it. For instance, if the tool was integrated to an LMS and a change was made to the content, developers could trigger a custom workflow plug-in which automatically published the content to the LMS.
Hope both of these make sense. We may not build any functionality (especially for the second item) but it would be good to consider these when designing the architecture.
In addition to the diagram, I'll aim to produce a document capturing thoughts / meanings of all the items on the sheet ASAP. Will upload here for further discussion.
Ryan, I'm open to changing the nomenclature away from project. I agree that project is not quite right. You have put forward some very good reasons. However, I feel there is something about 'course' that doesn't quite fit. For instance, we often call it modules, resources etc. The word course summons something quite big, containing a logical sequence. I think the industry has moved away from this notion and is now looking at smaller chunks. As a challenge, can anyone come up with suitable alternatives before we agree on 'course'?