Guidelines/Rules for an Good Tutorial  

Hans Vangheluwe's Ideal Tutorial Rules

I have compiled these rules over the years, tremendously enjoying excellent tutorials, but also being frustrated by tutorials which were a waste of everyone's time.

There are different styles of tutorials. Some take the form of a lecture, while some have a hands-on component. In the following, I focus on the lecture type of tutorials.

In the context of a conference, the purpose of a tutorial is commonly to bring attendees (often junior researchers) to a level of understanding of the tutorial topic that allows them to fully understand research papers at that conference.

Some of the following rules also apply to Summer/Training Schools.

The criteria for organizing a tutorial at venue X about topic (typically, a formalism, technique or application) Y are:

  • Topic Y is sufficiently mature, both from a theoretical and from a usability (of, e.g., tools) point of view.
  • Topic Y is of relevance to the X community (or more specifically, the anticipated audience at X). This is the WHY.
  • Topic Y is well defined, in purpose and (restricted) scope. This is the WHAT.
  • How to use topic Y and/or what its detailed semantics is (in the case of a formalism) is precisely and concisely given, by preference also through examples. This is the HOW.
  • The heterogeneous (and often minimal) background of the audience is taken into account. In the simulation community, a heterogenous audience is common. The background of and what industry participants are looking for may be very different from the background and interests of academic participants.
  • A tutorial is not a research presentation (and certainly not a recycled rejected conference paper)!
  • A paper and/or technical report on the topic of the tutorial must be available. In conferences such as ANNSIM and WinterSim, and sometimes at MoDELS, it is possible (and even required at Wintersim) to publish such a paper. In some cases, it is sufficient to refer to a paper authored by someone else.
    This also implies that the tutorial is not necessarily about your own work (though you should be an expert on the topic). A technical report with (much) more detail (than given in the tutorial) is useful to take someone whose appetite has been whet to the next level. This should be publicly available and could for example be published on arxiv.org
  • The (mature) simulators/tools/... are generally available online, possibly on a website created for the tutorial. What is posted there must be complete, with full documentation, and easy to install.
  • All the material (presentation, tool(s), examples) of the tutorial must be available online (and possibly handed out on a USB stick when in a location with limited internet access/bandwith). In case of difficult to configure toolsets, use a virtualbox image or a docker container.
  • Extra material (in particular, examples) must be available.

For MSDL: our (MSDL) best example is our series of DEVS tutorial(s). Other examples: Modelling Language Engineering, Rule-Based Model Transformation, Statecharts, co-Simulation, Modelling Physical Systems for Software Modellers (including a-causal modelling with Modelica and an introduction to CBDs and PID control), Model Validity, Twinning (unifying Digital Model/Shadow/Twin). Other presentations from the DSM-TP Summer Schools and the MPM4CPS Training School could, with minimal effort, be brought up to the above standard. Other material from MoSIS and MDE courses would require more effort to satisfy all the above criteria.


Maintained by Hans Vangheluwe. Last Modified: 2026/09/30 18:57:42.