Learning Bayesian Statistics, the baby way
| Session | Date | Document | Status |
|---|---|---|---|
| 1 | 3 April 2019 | pretty raw | In review |
| 2 | - | - | - |
| 3 | - | - | - |
| 4 | - | - | - |
Any group of people that gets together to learn Bayesian Statistics from the ground up, without much prior experience in statistical modelling (Bayesian in particular).
The first Bayes Babies group started at Newcastle University, in the School of Computing. We've published here the material that we used to guide ourselves through the learning process, so that we can re-trace our steps and others can benefit from it as well.
We believe that this kind of study group should remain relatively small (no more than 5, even 4 people -- if there is a total of 6 people then you can break that into two groups of 3 and so on). The rationale is that group elements to take the most out of each session, they have to be active participants. In a big group, each person has less opportunities to actively participate and engage.
There should be one or two people in each group responsible for organising and moderating the meet-ups. Group moderators should also make sure that the session documents are drafted and ready before the meet-ups, in the agreed format and with adequate content (right amount of content, not too easy or too hard).
A session document describes a self-contained small-size project designed to guide learning and group discussion. Groups are responsible for organising the frequency of meet-ups, in which they share/discuss solutions to the problem and their understanding of the underlying theory/subject. The content of a session should (more often than not) be designed for a single meet-up. However, this is only a general guideline. Sessions can be split between several meet-ups depending on a variety of factors (time constraints, amount of preparation, etc).
- Highlights the learning goals for the session.
- Proposes a motivating problem.
- Identifies a sequence of tasks that should be performed in order to solve the problem.
- Provides relevant references and bibliography.
- May provide hints and tips for solving specific tasks.
The tasks should specify what the user has to do, but should not tell the user how to do it! The person or persons responsible for drafting the session document usually have a concrete idea of what the solution to the problem is or what they want the users to take away from the session. Hence, the tasks should be designed in such a way that users arrive at the knowledge/solution by themselves, rather than being told. As no prior knowledge is assumed, don't be afraid to be verbose and using layman's terms in your session document.
- Follow a clear set of goals/exercises (usually described in a session document).
- Not last for hours on end (2 hours max as a rule of thumb).
- (Optionally) be preceded by preparatory work.
- Start with an overview of the problem and input from each member of the group.
- Be moderated so that the individual learning interests of each member are preserved and the meet-up stays on course according to the session plan and learning goals.
- End with a summary of lessons learned, and a quick discussion on follow-up content and times for the next meet-up.
Preparatory work includes reading the session document and thinking/attempting to solve the problem (or part of it). Preparatory work should remain optional and should not be enforced in such a way that group elements that fail to prepare the session beforehand are excluded from the session/group or discriminated against. Nevertheless, group members should be aware that their session productivity will increase if they invest time in preparing it. Ultimately, it's up to every element of the group to self-organise and find a time to meet that best suits all, or the majority of the group (another reason why study groups should remain relatively small).
Everyone can contribute towards the drafting of session documents and related content (e.g. summary of lessons learned at the end of each session). GitHub offers the right platform for this. If you're not familiar with GitHub and pull requests, please check the online documentation. It boils down to:
- Fork this repository
- Make commits and push them to the master branch of your fork.
- Create pull request
We'll use issues and pull requests to discuss, draft and add content (i.e. sessions and other material).
You can read our manifesto here. But don't take it too seriously :)
Mailing list: [email protected]
Moderator: [email protected]