Ansible is capable of handling many powerful automation tasks with the flexibility to adapt to many environments and workflows. While Ansible is not specifically opinionated software, a philosophy behind its design.
In this document we detail how that philosophy applies to effectively developing and delivering informal training on Ansible in the same spirit that it has become known for and highly successful.
Keep it simple and don't try to be too clever. Training is to teach and not show how smart you are. Keep it basic. Keep it practical. Focus on common scenarios.
Do just enough but no more. Ask yourself "what am I trying to communicate here?" and then do the least to demonstrate it within best practices norms. Sometimes that means using with a different example than the one you'd like. Using tool X might be cool to you or something you want to sell but if it has a lot dependencies, doesn't have the module support it needs or is a general pain to install it's not the right thing to use for teaching.
Keep it progressive. Don't try to show too much at once. Don't overwhelm the audience that they can't process what you're trying to teach them. Iterate and slowly reveal the full power of the tool as time allows. Teaching a man to fish so they never go hungry is an effective approach to teaching.
Be consistent. When you're not consistent in your examples and style it confuses students, raises questions and takes away mental energy and time from the presentation to sort out the differences. Let them sort out different workflows and styles once they are familiar with what you are trying to teach them.
Optimize for readability and always demonstrate best practices. This in some ways runs counter to "do just enough but no more" but consider that your audience is likely to take what you give them and copy it. Best you start them with good habits.