[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]