adding more docs

README.md

@@ -11,7 +11,7 @@ This is a dummy server for testing sending and receiving of data from an endpoin
    - A "Study" is a collection of series
 
 
-Although we have groupings on the level of study, images will be generally moved around and processed on the level of Series.
+Although we have groupings on the level of study, images will be generally moved around and processed on the level of Series. For high level overview, continue reading. For module and modality specific docs, see our [docs](docs) folder. If anything is missing documentation please [open an issue](https://www.github.com/pydicom/sendit)
 
 
 ## Configuration

docs/README.md

@@ -0,0 +1,20 @@
+# SendIt Documentation
+
+## Overview
+The Sendit application is intended to be a modular application that includes the following:
+
+ - a data folder that is watched for complete DICOM datasets.
+ - an (optional) pipeline for de-identification, meaning removing/replacing fields in the header and image data.
+ - (optionally) sending data to storage, meaning an Orthanc server, and/or Google Cloud Storage/Datastore
+
+Reasonable updates would be:
+
+ - to add a DICOM receiver directly to the application using `pynetdicom3`, so instead of listening for datasets on the filesystem, we can receive them directly.
+
+
+## Module-specific Documentation
+
+ - [Management](manager.md): an overview of controlling the application with [manage.py](../manage.py)
+ - [Logging](logging.md): overview of the logger provided in the application
+ - [Watcher](watcher.md): configuration and use of the watcher daemon to detect new DICOM datasets
+ - [Deidentify](deidentify.md): the defaults (and configuration) for the de-identification step of the pipeline (under development)

docs/manager.md

@@ -0,0 +1,67 @@
+# Django's Management
+Django is primarily controlled via `manage.py`, the file sitting in the base of the repo. You will see it's use in several scripts such as [run_uwsgi.sh](../run_uwsgi.sh) to do things like `makemigrations` and `migrate`. These commands in particular are used to update the database (given any changes in a `models.py` files that define the tables. Generally, you can run commands to control user generation, database updates and dumps, and even your own custom. The commands that I use most often are `shell` and (sometimes) `dbshell` to immediately get an interactive shell for the python application (shell) or the postgres database (dbshell). With `--help` we can see everything that `manage.py` can do:
+
+```bash
+[auth]
+    changepassword
+    createsuperuser
+
+[contenttypes]
+    remove_stale_contenttypes
+
+[django]
+    check
+    compilemessages
+    createcachetable
+    dbshell
+    diffsettings
+    dumpdata
+    flush
+    inspectdb
+    loaddata
+    makemessages
+    makemigrations
+    migrate
+    opbeat
+    sendtestemail
+    shell
+    showmigrations
+    sqlflush
+    sqlmigrate
+    sqlsequencereset
+    squashmigrations
+    startapp
+    startproject
+    test
+    testserver
+
+[djcelery]
+    celery
+    celerybeat
+    celerycam
+    celeryd
+    celeryd_detach
+    celeryd_multi
+    celerymon
+    djcelerymon
+
+[guardian]
+    clean_orphan_obj_perms
+
+[sessions]
+    clearsessions
+
+[sitemaps]
+    ping_google
+
+[staticfiles]
+    collectstatic
+    findstatic
+    runserver
+
+[watcher]
+    watcher_start
+    watcher_stop
+```
+
+For example, the last set of commands for the `watcher` we defined by adding a `management/commands` to our watcher application.