Old style meeting workflow

Guidelines

 * There is a "speaker" for every topic who introduces it; preferably the speaker has prepared some notes so he can give his presentation right away without needing to make up his mind as he writes
 * While there is no formal speakers list, we should try to find the right balance between immediate inquiries while the topic is still introduced and questions that are better to be asked once the introduction is done and we've moved into feedback mode
 * Feedback mode starts as soon as the speaker has ended his introduction; (s)he should point out that his / her introduction is over with some kind of tag, e.g., _end_, END, done, or something along these lines; this way we avoid extra waiting time
 * Discussion on each topic should not exceed 15 minutes; this is a rule of thumb that depends on the total number of topics; meetings that take longer than 60 minutes tend to become more and more exhausting than productive
 * The person who introduced the topic should act as moderator in case the topic exceeds the time limit; in this case he should summarize the different point of views introduce by the developers and propose how to continue (shift discussion to the forums, the next meeting or to the time after the official part of the meeting has ended)
 * The job of the timekeeper can also be assigned to one specific meeting moderator who would take care of reminding the developers about the time limit for all topics
 * Once the meeting is over the project management department is responsible for adding a link to the meeting log at the specific paragraph; in case the IRC logging bot is down, the meeting logs need to be uploaded to the wiki instead and a link to the specific file is added at the log paragraph instead

Meeting summarization

 * The results of the discussion and how to continue need to be written down under the results paragraph, preferably by the developer who introduced the topic; it does not apply to cases when a developer introduces two topics after each other; in this case another developer of the department will hopefully volunteer for the task or propose to juggle topics to avoid these kind of problems
 * The results should clarify if there either was a speaker who introduced the topic or if it was a round table discussion (subject just put on the agenda and discussion started right away)
 * Introduced arguments and opinions should NOT be personified in the summarization; this will help us to rather focus on the arguments themselves rather than on the latent authory of the developers who are arguing for one option or another
 * The only exception to this rule of thumb is the summarization of tasks that were agreed upon; in this case it's necessary to state who actually plans to take care of a certain task