Basic documentation

docs/developer/README.md

@@ -369,8 +369,16 @@ Though minimally, our application uses [Django signals](https://docs.djangoproje
 Per Django, signals "[...allow certain senders to notify a set of receivers that some action has taken place.](https://docs.djangoproject.com/en/5.0/topics/signals/#module-django.dispatch)" For the vast majority of our use cases, [pre_save](https://docs.djangoproject.com/en/5.0/ref/signals/#pre-save) or [post_save](https://docs.djangoproject.com/en/5.0/ref/signals/#post-save) are be sufficient.
 
 ### When should you use signals?
+(TODO - do some prelim research on this)
+Generally, you should use signals in two scenarios:
+1. When you want an event to be synchronized across multiple areas of code at once (such as with two models or more models at once) in a way that would otherwise be difficult to achieve by overriding functions
+2. You need to perform some logic before or after a model is saved to the DB. (TODO improve this section)
 
 ### Where should you use them?
 This project compiles signals in a unified location to maintain readability. If you are adding a signal, you should always define them in [signals.py](link to signals.py). The reasoning for this is that [signals give the appearance of loose coupling, but they can quickly lead to code that is hard to understand, adjust and debug](https://docs.djangoproject.com/en/5.0/topics/signals/#module-django.dispatch). With the exception of rare circumstances (such as import loops), this should be adhered to for the reasons mentioned above. 
 
-### Why use signals at all?
+### How are we currently using signals?
+To keep our signal usage coherent and well-documented, add to this document when a new function is added for ease of reference and use.
+
+#### Function handle_profile
+This function hooks to the post_save event on the `User` model to sync the user object and the contact object. It will either create a new one, or update an existing one by linking the contact object to the incoming user object.