Source Management for Docs and Tests

Keep test case doc and test script in a separate branch from the Score Source branch that never merge with the master. Test case doc needs not be browsable. It is not so inconvenient to edit Test case doc directly in HTML. We can convert the current MS Word into HTML and then edit Test case doc in plain HTML. We lose the autonumber and ease of referencing test assertions when writing test step in the test case doc (but I think we don’t do that anymore).

• >>> So Hakju suggested to keep this in the same score repo under Tests folder. So I guess we will make folders like Test/UI Driven Test/Test Document and Tests/UI Driven Test/Test Script.

• There is issue about non-public content in the test script repo like OAGIS data.

User Guide

• Use another repo, i want user guide to be browsable without score deployment, so it should be Github Pages. I looked at Gitbook a bit. I am not sure if I want the user guide content to be hosted somewhere else not inside the application. In interest of time, we can keep user guide with the application for now.  We can look into other benefits Gitbook may bring later. At this point, we upload the Word doc to a Wiki page and the generated HTMLs to the repo. If Sakis can help me move User Guide to Gitbook b/f he leave, I think I might be fine. I don’t know how to sync the release though.

• User Guide needs to be in another repo because I want Contribution Guide to be browsable as well but I don’t want Contribution Guide to be included in the release. But GitHub Pages can only point to one root.

Contribution guide should be browsable as well, but don't want it in the release. So it should be Github Pages as well. Contribution Guide should be in a separate branch call Github Pages branch. ReadMe file can have a link to that. The Score repo GitHub Pages will be set to point to contents related contribution guide.

>>>So if User Guide and Contribution Guide are in the same Score repos, they should be both subdirectories of docs.

The Release Detail page including upgrade. It is convenient to be browsable because people might want to read before download or more importantly it can be read when deployment is via docker. Since the content is cumulative, it does not benefit much from the version control system. Also, we may still want to update the release detail page after the release. In the past, we usually have something to add to help people with the deployment. It is better to keep the content on the Wiki. Put a link to this page in the ReadMe.

Installation Guides - move this to User Guide. Going forward installation guide can include non-docker installation. Installation guide is separate from the Release Detail b/c the content is relatively static across version and this refers to only brown field installation. Going forward there has to be installation w/o any standard content and then there is a reference to data loader.