Restructure sar-status repo to sar-status-personnel about sar-status-personnel

[Anders55]

+1

[kengu]

Decision
Since @Anders55 is +1 for both alternatives, I've decided to go for alternative 2.

Reason
Although it is best practice to isolate each components in it's own repo, this makes the sar-status service more complex to maintain, understand, document, track dependencies and issues using GitHub alone. New devs need the lowest possible threshold for on-bording the project. Moving all three repos into one impose the need for more on pulls (more commits are inbound) before push. The careful placement of each component in subdirs should only result in a higher pull frequency by each developer before push. The actual conflict rate should not increase however, which would be a more serious problem.

[kengu]

Alternative methods for merging repos, see https://stackoverflow.com/questions/1425892/how-do-you-merge-two-git-repositories

[kengu]

After talking with @RobertSasak, our devops consultant, I've decided to go for alternative 1 instead. This solution still have the challenges described above, but is better aligned with the deploy strategy supported by our hosting solution at heroku.com.

[kengu]

Progress

• Rename sar-status to sar-status-personnel
• Moved files in sar-status-personnel/sar-user to repository root