Back to the schedule
Previous: A day in the life of a janitor
Next: One effective CS grad student workflow

Emacs Research Group, Season Zero: What we did together with Emacs in 2 hours a week for a year

Noorah Alhasan, Joe Corneli, Raymond Puzio, Leo Vivier

Duration: 10:23

This talk was also streamed at an alternate time for APAC hours: https://libreau.org/past.html#emacsconf21

If you have questions and the speaker has not indicated public contact information on this page, please feel free to e-mail us at emacsconf-submit@gnu.org and we'll forward your question to the speaker.

Talk

Download video, 10:23, 33.7M

Download .org
Download --compressed56.webm (11MB)
Download --main.vtt
Download --chapters.vtt
Download --main--chapters.vtt
View on Toobnix

00:00 Introduction
01:46 Background and technology: Emacs Research Group
02:53 Prerecorded demo
05:13 Organising metaphor
05:35 Timetable
06:00 Project Action Review
06:32 Causal Layered Analysis
07:02 Design Patterns and Next Steps
07:42 Projects
07:53 Patterns of Patterns (PLoP 2021)
08:24 PLACARD Workshop roles
08:57 Initial user studies
09:38 Broader context
10:08 Conclusion

Q&A

Download video, 14:05, 40.1M
Download --answers--compressed32.webm (35.7MB)

Description

The four of us met at EmacsConf 2020, and joined together around a common interest in Emacs and research. Since then, we have convened as the Emacs Research Group for weekly meetings. During these meetings, we took notes collaboratively, using a ‘conflict-free replicated data type’ package (crdt.el); at the end of each session, we debriefed using a template that we call a Project Action Review (PAR). As as a meta-review of our sessions, every six weeks we prepared a Causal Layered Analysis (CLA), which gave us a different perspective on what we had done. We reflected further on our experiences and methods, linking our CLA to plans and design patterns. As a formal research output, we contributed a write-up of these matters to a joint paper which we presented at the Pattern Languages of Programs Conference (PLoP 2021). The paper included an interactive workshop, in which we explored roles in real-time problem solving and collaboration.

In our short talk we share information about these methods, making a case for other people getting together and creating their own small research communities similar to ours.

Discussion

Transcript

Raymond Puzio: Hello, I'm Raymond Puzio. I first learned about Emacs and Lisp at an enrichment program for high school students. When I studied physics at the university, I used Emacs and Tex to write mathematical documents. Later on, I became active in Emacs and Lisp user groups where, among other things, I learned about Org mode for reproducible research. Nowadays, I am working on synthesizing Emacs and other programs into an end-to-end platform for scientific research and collaboration. Joe Corneli: I'm Joe Corneli. I also started using Emacs in high school in a course on C programming, and now I'm technically a computer scientist. My research background is in mathematics and online communities. Noorah Alhasan: Hi, I'm Noorah Alhasan. I'm a member of the ERG group and a PhD student at UT Austin studying climate policy. So for this talk, the four of us met at EmacsConf 2020 last year with a common interest in Emacs and research. we've met almost every week since then because we wanted to keep the conversation going. In this short talk, we share information about the methods we use. Here's the outline of our talk. First, we'll tell you about the technologies we use and show a short demo video from one of the meetings. We'll then focus on the time and content structuring methods we use in our live sessions. Finally, we'll talk about what came out of all this work. For example, we wrote a paper for the Pattern Languages of Programs conference, and we designed a workshop using the knowledge we created together. Very practically, this has improved the quality of our own collaboration and we have some lessons about how you can create a research community similar to ours. Joe: You'll have noticed that we all have different research backgrounds and we do think that transdisciplinarity is important for solving big problems. However, if you have people from different research backgrounds working together, they need some scaffolding, both in terms of tools and methods, to have good conversations. And of course, as Emacs users, we wanted to have Emacs at the center of that. Being in a meeting, taking real-time notes collaboratively with Emacs realizes a dream that some of us have been entertaining (and experimenting with) for a while. The package crdt.el by Qiantan Hong makes this easy. We take notes in our meetings using Org Mode. Since we've seen this before in talks on reproducible research, and since Leo is the maintainer of org-roam, it was a natural choice for us. It allows us to put our notes online using git and the static state generator Firn. And lastly, of course, we need a real-time meeting tool. For that purpose, we use BBB in our weekly sessions (in fact, we use the same server that's used by EmacsConf, thanks again to Leo). All of these tools are free/libre/open source. However, BBB does have some intensive hardware requirements. Next up, here's a short pre-recorded snippet from one of our recent meetings so you can get a sense of how they go. Demo - Leo Vivier: Are we okay pushing the demo to the end? That kind of presupposes a different structure that you would usually have in a presentation. Generally you have... You introduce the demo, you do the demo, and then you do the conclusions, or what was good about the demo. Does that make sense to everyone? Ray: Let's see. When you usually do that, that's because whatever you're demonstrating is the main point of your talk, so if this was a talk about action reviews, that would make sense, but isn't it not ERG? Leo: But it's because we are telling... For me, I think it's a compound element. Yes, we are demonstrating the power, but we are also demonstrating how we're working together by... Yes, we might have introduced CRDT before in the presentation itself, but if we need to be doing the power, and also showing tools like CRDT, obviously, we're not... probably not going to be talking about... oh by the way, here we are using CRDT and stuff like this. It feels like cramming a lot of stuff into this demo at the end. Joe: So I think demo to me is less about demoing one of the methods, because then people will get a bit hung up on that. I think the demo... You know, to be honest, here's another thing. What we could do-- this would be very clever-- we could make this the demo, what we're doing right now, writing this talk is the demo, and just go back into the video and just get out a two-minute section, so we say, look we tried to write this talk, we went around, had a discussion, we had these things and then we just take... We're going to pick two minutes out of this video and show you that as a demo of how we actually work and then we'll go back to the talk. I mean, it'd be very funny, and then we've already done the demo. It's just, like... uh yeah, then we're good to go. And it's got neural lines on the floor. It's like a perfect writer's room. It's a total amazing writer's room scenario, specifically because she's lying on her back on the floor. Anyway. I mean, I think this would be fine. Leo: I think I particularly like the idea of taking the snippet, the two minutes before the realization that we could be using this as the demo, and then seeing the... well my face light up because it feels like a good idea, and Joe gets excited about this. I think this could be a good demo, and I think this would be a very genuine demonstration of how we work here and how we get excited about some of our ideas sometimes. Noorah: In the demo, you saw a very improvised free-flowing conversation. In order to have this kind of conversation and still get things done, we need a pretty rigorous structure in place at the bigger scale of the meetings. This involves both a timetable for the meetings and some review and planning processes. Joe: Just to say a little bit more about the timetable, if you could go back, the meetings are generally following a structure as we have up on the screen of informal check-ins followed by any announcements, and then two topics, at most two topics, with a break in the middle. The whole thing takes about two hours, and we meet weekly. The consistency of these meetings is really important for how the group works. Ray: At at the end of every meeting, we ask and answer a series of questions adapted from the ‘After Action Review’ developed by the United States Army in their training programs, and also used in some business contexts. The adaptation we use here came out of the Peeragogy project, which some of us have been involved with since 2012, and it's designed to be less hierarchical than the army's review. By writing down and sharing these reviews, we create a resource for further peer learning later down the line. Joe: So, specifically, every six weeks or so, we look at the transcripts from the previous action reviews using a four-layered framework that comes from future studies, and we use this to better understand the underlying themes that surface in the reviews and to develop the deeper motivations for ongoing work together. This helps us get a big-picture sense of where we're going, and we can keep that up to date at a slower pace than we do in the weekly meetings. This also helps us tie our work into a broader context and gives us some hope that over time we can contribute to solving big problems. Ray: Going back to solving larger problems. When we carry out the analysis, we don't just think about what happened at previous meetings, but we also take a longer view, thinking about things such as structuring a community of collaborators, or building platforms for scientific research. We want to think about how what we have been doing fits into broader historical patterns and trends. In the past, the pattern is a historical pattern; in the present, we contextualize what we learned about designed futures; towards the future, we use these patterns to augment our big-picture analysis with the next steps. This helps keep us on track. Noorah: Okay. So we have been working on several projects: a paper for the pattern conference mentioned earlier, a workshop, and a user study, and we'll say a little bit more about these. We co-authored a paper that touches on all of the topics we mentioned earlier and presented it at the leading conference on Design Patterns for programs and programming. One of the case studies in the paper sums up the way we work in ERG. The paper puts ERG in context with other peer learning communities, and we aim to describe our way of working in a way that others would find accessible and potentially useful. We are also developing an interactive workshop based on the ideas in the paper, which we piloted at the PLoP conference. Our intent with the workshop was to build a method for rapid problem solving, which could, at least in principle, expand beyond the workshop setting to distributed networks. The workshop involves made-up roles, like a kaiju communicator who helps understand problems as they arise. We also realize that it has given us a lot of wealth for thinking about the roles we take on in our weekly meetings. Ray: Free software may be lacking on ‘user’ aspects. People too often program to scratch their own itches, and assume others will do the same. To deal with this, we did several things. We looked at user experience and development together to see how the process went and where the gaps might be. We compared Emacs with other platforms, not just a technical level, but also at the user experience level. We had guest sessions, where we've started to gather user stories. Building on these conversations, we would like to do more research in all these topics, and eventually be able to say something like: ‘If you are someone who does X, these are the packages that would work for you.’ Joe: Putting these ideas into practice, our PLoP paper and the plans it contains become a /template/ for some of the other things we want to work on as we go forward. If we imagine things in 2-3 years, what would it actually take to realize the vision from that paper? Thinking about the future: this is one of the main reasons why we want to share these ideas and invite other people into this way of working. There's no way we can actually achieve everything in our vision if we work all by ourselves. What we've been focusing on in Season Zero of the Emacs Research Group is methods that people can use to organize their own research groups. We decided to share this talk so that folks can learn from our community. Our goal has been to share how we've been doing things, and we hope this information is useful for you in your own communities and collaborations. Thank you. captions by speakers and sachac

Back to the schedule
Previous: A day in the life of a janitor
Next: One effective CS grad student workflow