Differences

This shows you the differences between two versions of the page.

--- meetings_how_to [2020-06-01 14:34] – [Actual content follows] adq
+++ meetings_how_to [2020-08-10 09:26] (current) – river
@@ Line 1: / Line 1: @@
 ====== How to Meeting ======
-This page is intended to develop a guide for how to have better meetings in the hacklab. It is a draft - contributions invited. If you are interested and would like to discuss it further, you may like to add your name below.
+This page is intended to develop a guide for how to have better meetings in the hacklab. Contributions are welcome.
-=== People who would like to have a meeting to discuss the terms of reference for the formation of a committee for the formation of a working group on administrative affairs and the writing of guidance on how to have meetings: ===
-  * River
 ===== Meeting facilitation training =====
-Would you like to learn how to run better meetings? I have been to a training session on this and found it worthwhile. It was run by someone who understands community organisations and was not unpleasantly corporate. If you would like to attend one please add your name below and if there are enough people I will organise it.
+Would you like to learn how to run better meetings? I (river) have been to a training session on this and found it worthwhile. It was run by someone who understands community organisations and was not unpleasantly corporate. If you would like to attend one please add your name below and if there are enough people I will organise it.
   * River
@@ Line 24: / Line 19: @@
   * Meetings should have a purpose.
   * Send out an agenda ahead of time, so that the purpose of the meeting is clear to all attendees and they can come prepared if necessary. Ideally this should include a quick background paragraph/links on the topics.
-  * After the meeting has finished, create a quick list of actions and distribute to attendees.
+  * Create a list of actions during the meeting and distribute to attendees afterwards.
   * Discuss this action list at the start of the next meeting if there is one.
   * Agree on a time limit in advance (eg an hour max) and try and stick to it: Better to have two shorter meetings with fresh people than one enormous mega-meeting that burns everyone out.
   * If someone starts discussing something unrelated, keep note of it, and politely ask to discuss it after the current discussion is finished. Make sure to actually do so though! (even if its just to get more information and add to the agenda for next meeting).
   * If you're presenting something, spend some time preparing in advance rather than going in "rambling". I actually found making myself write brief sets of slides (yes, //I know, slides, yuck//) made me much better. It forces you to consider the way you are communicating your point to others, as well as helping spot and answer common questions in advance. They also give a single place for people to refer back to later, esp if you've provided useful links to further resources etc.
+===== Widening participation =====
+It has been suggested (at one of the meetings leading to the draft comfort & conflict resolution proposal) that we could record the meeting as a 'podcast'.
+This might help widen participation as in 2020 we are not limited to text communications. However a recording would obviously need the agreement of everyone participating and possibly limited editing, rather like minutes do.
+===== Avoiding Bikeshedding =====
+Some general points on how to collaboratively solve problems. Key thing is to consider the problem fully before we all jump in with possible solutions.
+See also: [[bikeshed|]]
+=== Think Problems ===
+  * Understand the problems in detail before considering solutions
+  * Listen to all stakeholders, not just the loudest
+  * Use techniques such as shadowing, brainstoming
+  * Prioritise solving problems that are urgent, pervasive and valuable
+  * Write don and communicate the problems - e.g. user stories, use cases, personas, problem statements
+=== Think Requirements ===
+  * Remember there are multiple stakeholders - anyone with an interest has a voice (e.g. suppliers, potential users, others with opportunity cost)
+  * Document the problems as  requirements that can be validated against when considering solutions
+  * Consider implicit requirements that are not communicated – and check them with stakeholders (e.g. tea must be in a mug)
+  * Remember specifications describe solutions and requirements describe problems
+=== Think Emergence ===
+  * Understand how your solution works in the end application - how does it interface, what is its boundary?
+  * Consider the environment in which it is operating and how it may interact - what negative or positive behaviours or consequences may emerge?
+  * Identify how it may go wrong and mitigate those effects
+=== Think Analysis ===
+  * Consider multiple possible solutions and analyse trade-offs against the requirements you have gathered
+  * Iterate - start with simple quick proof of concepts and use them to learn
+=== Think Validation ===
+  * Validate early to identify changes and errors as soon as possible
+  * Constantly communicate with stakeholders in case their needs change
 ===== Bibliography =====