id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
30801	Improve guidance for making good use of signals.	Aymeric Augustin	Joseph V Zammit	"This is a follow-up to https://github.com/django/django/pull/11814 and https://groups.google.com/d/msg/django-developers/c5sFZ5BEujI/jVLsfSYBAwAJ.

I have two suggestions to improve the documentation of signals.

1. In ref/signals.txt, for each signal, document the alternatives, which will usually be more robust and  maintainable:

    - Instead of a model signals, you can override the corresponding method in the model class — unless that model is provided by a library and cannot be swapped
    - Instead of request/response signals, you can provide a middleware.
    - As far as I can tell, other signals don't have a great alternative. You could replace `connection_created` by a custom database backend but that's a lot more work.

2. In the introduction of topics/signals.txt, replace the list of signals with a good example. In my opinion, `setting_changed` is likely the best example: many pluggable apps need it in their test suite."	Cleanup/optimization	closed	Documentation	dev	Normal	fixed		Adam Johnson	Ready for checkin	1	0	0	0	0	0