Book Sprints – Adam Hyde

Circles…

Well… I was driving from Cambridge (UK) to Newquay and chatting to my buddy Faith about all the things I have been working on (Faith is rewriting some of my website) over the last 10 years. I was commenting on how crazy circular it all is at the moment… I found myself documenting Editoria a few weeks ago, using Editoria to document it… which is just the kind of thing I started doing when I started FLOSS Manuals 10 years ago. And then this week I was in a Book Sprint this week as a participant for the first time whereas it was the first time as a facilitator 10 years ago… and this week I was with a team of Coko people writing a book about a Coko product and at the same time with a team of Book Sprints people helping Coko to write a book…and I started both organisations… its all so recursive….

Its been a bit weird. And as I’m chattn to Faith and driving through a lovely summer’s solstice day in the UK pondering this out loud and what do I accidentally discover?….

img_20180622_154608

img_20180622_154639

Y’know… that place with the rocks in a circle….And I didn’t even know I was near it…I don’t know… gotta take account of things like that I reckin..

Crossing the Line…

10 years ago I started on a new adventure – I was trying to work out how to produce books fast. Along the way came numerous open source book production tools and platforms, and the Book Sprint methodology.

Now, for the first time, I crossed the line from facilitator to participant in a Book Sprint about the Coko PubSweet product. It was a cool experience… at first I thought I was going to be trouble since I have facilitated facilitators before and it’s no fun. When you facilitate facilitators they can all ‘see’ the process, or they think they can, and they try and scramble madly to get meta on it. They can’t just be subjects to it, they need to get above it and can’t help suggesting better ways to do things. Its a real pain.

So I was trying very hard to not be that and I think I did pretty well. I asked our facilitator (Barbara, CEO of Book Sprints) if I could or should do stuff, and I mostly did what she said 🙂 Mostly…but no more or less compliant than your typical participant…I was a little proud of myself for that. I didn’t want to be a Diva.

So, from the other side I noted a couple of things. First of all… Book Sprints are fun. Second… they are tiring… but actually, its more tiring to be a facilitator than a participant. Also, as a participant you can time out from time to time which helps recharge… there is no such luxury for a facilitator…

Other things… good facilitation appears from the outside like there is nothing going on… Barbara is an excellent facilitator, as are all the Book Sprint team…but we (I own the Book Sprint company) see people come out of a Book Sprint thinking they can do the next one themselves. It doesn’t actually happen very often but when it does it fails. What I can understand now a little better is why they think they can do it… it is because they just can’t see the process. They think the facilitator is just some friendly person pointing them in the right direction every now and then… but there is way more going on…. but I can see how they can think there isn’t.

Also, I had some nice bonding experiences. I didn’t expect it, but it happened. When you are tired and in a room working side by side with people for many hours, your defenses just evaporate and I found myself being way more open to letting people get to know me than I usually am.

Also, watching the book you are creating improve as you go is very satisfying. Especially when the illustrations and book design start to land… it’s very cool…

Lastly, there are four other issues that were big take aways… number one – in one session me and two others (Bogdan and Peter) spent an hour hammering out a problem. We essentially were tackling a similar problem from different directions and not quite able to understand each other. The result was that we all got a much clearer shared understanding and together developed a ‘new’ way of describing the problem… that was very exciting and the model we came up with is something I will continue to use. Two – the design process gave us a whole lot of icons that we will also continue to use. That was wholly unexpected and crazy rewarding. Three – books really matter. One of the things I wrote about in the book was something I have been working on for the last months (Workflow Sprints) but the book now instantiates it as ‘a thing’… thats soooo interesting….and Four – the chapters I wrote on Workflow Sprints were added to and edited by others and as a result the description of the process is miles better and I have a much clearer understanding of the process too…

So, it’s interesting to me that I have always witnessed these takeaways in other sprints but I was an outsider to ‘the value’. But being on the inside, these things loom large in my mind, and I feel, walking away from the Book Sprint, that the value I took with me was greater than that printed on the pages of the book…

Off to Book Sprint!

A long time ago I started FLOSS Manuals to create free documentation for free software. It was my big get rich quick plan. Along that journey, which lasted 4 years or so, I had to come up with some things to make it all work… namely, I had to:

learn how to build community
build tools to help people collaborate to make books
come up with methodologies to make books fast

Out of this came the FLOSS Manuals community, many (open source) book production platforms (most notably Booktype), and Book Sprints – a method to produce books from zero in 3-5 days.

Now… 10 years later…. here I am traveling to the Cambridge, UK, to be part of a Book Sprint facilitated by the CEO of the company I started, to write a book about PubSweet (a publishing toolkit for building publishing platforms built by Coko, which I co-founded), and the book will be written by the Coko team and Coko community…and written using Editoria – a book platform built ontop of PubSweet BY the Coko community!!!

Talk about recursive…. its like dog fooding on steroids…

Production Facilitation

I had an interesting chat with Dirk Slater from Fabriders yesterday. It was a live online interview/discussion about the work I’ve done since FLOSS Manuals which I started 10 years ago.

Here are a few points I want to distill out from my experience evolving the Book Sprints, the Cabbage Tree Method, Workflow Sprints and others…

Production Oriented Facilitation is not the same as ‘unconf’ Facilitation
I like to differentiate facilitation of processes that produce products over a fixed timeline (books, software, workflow designs) from the typical kind of facilitation related to unconfs (etc). They are not the same thing, the former employs some of the tools of the later but also has tools of its own. Importantly, if you bring a (dare I call it ‘too respectful’) unconf tone to a production processes, you won’t get anything done. So don’t expect because you can do unconfs, that you have the tools and right approach to facilitate production processes. Mistaking one for the other is a category mistake.
Remote Facilitation doesn’t work
Facilitation of production events of the type that enjoys radical efficiencies like Book Sprints is not something you want to do remotely. You can’t get the same attention and commitment. Nor can you get the ‘full spectrum’ communication between all members of the group that you need if you are working remotely. At Book Sprints we believe this so much to be the case we don’t like to have even one person working remote.
Not everyone is a facilitator
Facilitation is one of those skills that people think they can ‘just do’. Doesn’t need any ramp-up time or experience, its just someone telling everyone else what to do in a ‘nice way’ right?… I have seen this time and time again. If you think like this, thinking you can facilitate with no experience, then you are at a bad starting point because it is clear you don’t know what facilitation is. Don’t experiment on your friends, family, or colleagues if this sounds like you.
Good facilitation can only be learned by experience
Experience is the only way to learn to be a facilitator. You can’t learn it from a book. So how do you learn? By apprenticeship. Find a mentor that can take you through the process in situ. It is the only way. Don’t expect it to be a quick process.
Technology is not the answer
So many times I have people ask me what tools Book Sprints uses. What is the software? It is not asked from the position of trying to make sense of the ecology of items that are needed as tools, it is asked in the Silicon Valley sense of ‘software solves everything’. Book Sprints is not about the software. Its about the methodology and the facilitation. We could do Book Sprints without the tech we use (and we have in the past). But if you believe you just need to install the software and stand back and watch the magic happen, then you are wasting your time. Sure the software helps us run things smoothly, but it does not automagically ‘provide’ a Book Sprint.
Don’t put people in a room and expect it to work
In the case of Book Sprints I have seen many orgs try and emulate it by just putting a whole bunch of people in the same room and expecting the magic to happen. If you have tried this, I know you have failed. It doesn’t work and you are missing the point. It’s all about the facilitation.
A method is a compass, not a religion
Facilitation methodologies are not religious texts that must be followed to the letter. Unfortunately that is how too many book-learning facilitation courses approach facilitation. It’s very sad to see. Methods are instead merely navigational instruments. However, they are useless in the hands of someone that does not know how to use them. You need to be an experienced facilitator, with experience of that particular method, for everything to work. A facilitator who is experienced with a particular method and knows how to use it will not only be amazingly good, they will also know when the method doesn’t give them what they need, and how to improvise towards true north.

And as a last coda, a note on who makes a good facilitator… I do believe some people, through a combination of nature and nurture, will make excellent facilitators, while others should really not even attempt it. I must say that this is a very hard thing to determine before training someone. I have some clues as to what qualities may contribute to being a great facilitator but it’s still largely a mystery to me. You never really know it until you see it, which is why I prefer to train people with the option of stopping if I can see it won’t work out.

I will say however, that I have found that most unconf facilitators do not make good ‘production’ facilitators. My best attempt to understand this hasn’t got me very far, although I’d say it has something to do with the two processes looking like they overlap a great deal, but in reality they overlap less than you imagine. Consequently the internal rationale and ’emotional position’ you take, as well as the facilitation tools and tricks, don’t actually transfer, and, worse, will probably lead you in entirely the wrong direction. You need to be rewired, and I haven’t seen this work (yet). This my best take on it and is purely anecdotal – garnered from training several people who knew how to facilitate unconfs only to abandon the effort to facilitate production part way through. I can’t entirely explain it, but there you are – take it for what it’s worth.

Its all about workflow…

In the last 2 years, I have been very privileged to see inside the workflows of many publishers (book, journal, micropubs), aggregators, and preprint servers.

As a system designer, or one that facilitates others to design their own systems, this provides incredible insights into common struggles all of these organisations have. Recently this has given me pause to think about the system design process. So below is a little emergent theory of the importance of mental models in the process of workflow design….

Who better to ask about an organisation’s workflow than the publishing staff themselves?
There isn’t anyone better! Publishing staff are experts in what they do and they know every nook cranny of their workflow. They know the broken parts *intimately* since they live the pain on a day to day basis. They also know what works and what cannot be sacrificed.
Publishing staff are the best placed to know how to improve their workflow (if given the chance)
In order to be able to improve a workflow you need to first know it intimately. As above, there is no one better to do that than the publishing staff themselves. If you want to solve the problems, publishing staff need to be at the core of the design of solutions. By publishing staff I mean the actual people doing the publishing work.
Publishing staff don’t design their own solutions
This may seem like an oxymoron, but hear me out. In order to design an improved workflow you need a *perfect* mental model of the current workflow and what needs to be done. You need the first so you make sure you aren’t missing anything, you need the later so you know exactly what you can miss (what can be left out, what needs to stay)… Often I have seen one person given this job, and that person comes in from outside the org, or they are from within the organisation but have never done the publishing work directly. That leads to an imperfect mental model and pure speculative theory as to where and how the flow can be improved. It simply doesn’t work but it is the way it is done everywhere.

So… the heart of what I am trying to get at here are these three questions that lead on from the above which I am currently asking myself – why it is we don’t involve the publishing staff intimately in the design of better workflows? What is this mental model stuff and why is it so important? Why do I have this growing gut feeling that it’s all about workflow?

So… as a first, rather rough and quick response to myself on the above three issues…

why it is we don’t involve the publishing staff intimately in the design of better workflows?
Ok… I might actually sound rather nutty when I say this out loud. I believe the problem lies in the history of software development… First of all, these days we conflate workflow with software. They are not the same thing, but we make the mistake of equating the solution to workflow as software. This is far from the truth… but it is what it is…so, this is where the problem starts. To compound the problem, I’m going to go out on a limb and say that I think software dev today, including ‘Agile’ and Lean etc… repeat the same mistakes as older methodologies like, for example, ‘Waterfall’ and Xtreme Programming etc… That mistake is simple – the solutions providers are outsiders to the problem. I have at times, to be sure, been that person in the past. So I’m not pointing any sticks here…well at least, if I am its also at a past me. Waterfall treated the ‘users’ as research objects. That will only give you an outsider’s solution. Agile (etc) make me a little crazy because they try and cross that divide with tricks like ’empathy maps’ and creating avatars (which is, literally, a process of drawing pictures of the ‘users’ and guessing what they want). It’s no good. Why use avatars when you can actually just ask a real, living, experienced, member of the publishing staff? I have a lot more to say on this…but I’ll leave it here for now, suffice to say these problems situate the ‘end user’ at the end of the process ie. when the software is designed and / or delivered.
What is this mental model stuff and why is it so important?
This is a new insight for me. In a former life, I was a Book Sprint facilitator, and I own Book Sprints Ltd (though I have little to do with the operations). Recently the staff there have been pondering how to communicate the value of Book Sprints and interviewing people that love the process. One such interviewee hit so many deep points I was astounded (I’ll ask if I can share her name and credit her here). Her core point was this – Book Sprints, as a highly immersive collaborative model for book production where the experts (usually programmers) write the book together — [in this paarticular case we are talking about corporate documentation of highly complex software systems], gets to a shared mental model of the complex system exceedingly fast – less than 2-3 days. This is shared as a book so others can ‘get inside’ that mental model. If the same company hires an experienced tech writer to do the same thing, they will take at least 6 – 8 months to arrive at the same level of understanding. It will take them that long to develop the same mental model of the system. That’s the point. (Also, the collaborative effort will simply pull in more nuance, at a deeper level of understanding, that the lone contractor can, arguably, ever do).That is quite an insight, and when I heard it, I recognised the truth in it right away. The same is true for our workflow design processes. If you want the best workflow design you first need a perfect mental model of the problem. It is critical. So, get the staff involved, and if you want to save money and get the quickest design process possible, get them involved early.
Why do I have this growing gut feeling that it’s all about workflow?
Well… because publishing is not about technology, nor is it about formats, nor is it about a confused lexicon that we all think is stable (how many different types of Editor roles are there? what do you mean by peer review?). Publishing is about none of this. It is about how you get a document, how you improve it, and how you get it to others. That’s it. And that is all about workflow…

It Always Amazes Me…

Book Sprints is something that popped out of my brain and a lot of experimentation. It’s now its own thing and it constantly surprises me.. .here for example is a post about a Book Sprint last week, where my friend and colleague Barbara Rühling facilitated Cisco to produce a book in 5 days. It had 100 illustrations (!) and will be printed next week…incredible..

https://www.booksprints.net/en/blog/catalyst-9000-done/

I currently don’t facilitate Book Sprints as my Shuttleworth Fellowship requires me to focus on Coko, which is fine with me. It is in good hands 🙂

Mugabe is done

I didn’t ever think I’d see the day…. Mugabe is gone. I feel a slight connection to Zimbabwe as I did a Book Sprint there about 4 or 5 years ago with a local activist organisation. It was an amazing experience and gave me something of an insight into how beat up and broken the country is. Activists have to be very careful in Zimbabwe, they can be in serious trouble easily and are at the whim and mercy of the powers that be. We did the Book Sprint at an old game ranch so it was off the radar… we had a generator as there was no electrical infrastructure, and the wonderful cooks made everything in wood stoves by candlelight. It was a pretty amazing experience.

A few snippets come to mind from that visit… walking into the airport under a huge picture of Robert Mugabe….finding porcupine needles on a path through the bush…it felt like treasure…rare (to me) and beautiful… also tramping through an old abandoned game ranch with friends from South Africa and Zimbabwe…finding out as much about the country as I could… making a stupid joke about not being scalped by a leopard (they scalp people) only to find out that the husband of one of the crew suffered exactly that fate not 6 months earlier…

Also the animals… beautiful… and the stories of mobs with sticks that would come through a town and beat everyone… the 5 billion Zim dollar note I still have on my bookshelf. Victoria Falls. Careening down rapids on the Zambezi in a kayak, hippos straight ahead. The wait we had at the airport as Mugabe commissioned the one and only Air Zim plane to go for a little ride, leaving us bewildered while our fellow passengers just saw it as sort of expected… the horror stories we heard from people that lived there, the horror stories I read about later in many books.

I don’t hold much hope that things will dramatically improve. But I am glad Mugabe has gone. One less evil bastard. One more that didn’t get away with it. It might be a late victory, but I’ll take it.

I love Book Sprints

Sigh…I don’t have much to do with Book Sprints these days. It is its own company now, I’m still the owner and founder, but it is it’s own thing. It’s own thing run by some amazing folk. Anyways…photos like those you find here from a Book Sprint happening right now in Capetown make me miss it sorely!

https://www.flickr.com/photos/129798087@N03/albums/72157686618588024

Some samples from that album below.

36375029644_8474e2cb3f_z

36397459153_cd0fa218c1_z

37069587571_8c7f92ac23_z

37211952675_347e7a32f3_z

36814068670_2b01a9b834_z

37039827852_05f14a60b7_z

37069600851_87461cdce2_z

The Road to PubSweet 1.0

We are pretty close to our PubSweet 1.0 with the RFC now out for PubSweet 2.0, and a PubSweet dev site release next week.

pubsweet

It has been an amazing effort, particularly by Jure Triglav, the lead dev for PubSweet at Coko, but also fantastic work from Richard Smith-Unna, Alf Eaton, Yannis Barlas, and Christos Kokosias. Also more recently some great contribution from Alex Georgantas.

So, we are pretty much there and I’m presenting in San Francisco this week as part of a small Coko event to reflect on the future of the framework and discuss the RFC. For this purpose I’d thought I’d write a post to help me think through the thinking that got us here.

So…the thinking behind PubSweet started when I came back from Antarctica around 2007 or so (I was there setting up an autonomous base for artist-scientist collaborations).

5jan2007-2

I decided I wanted to give up the art world and try something new. The something new turned out to be FLOSS Manuals – a community writing free manuals about free software. I started it when I was living in Amsterdam somewhere around 2007. In order to execute on this mission I needed to get a couple of things sorted. Namely, learn how to build community, work out processes for rapid book production, and work out the tooling.

The tooling started with me scratching around with TWiki. A wiki written in Perl that happened to have the best plugins for rendering PDF. I scratched around, writing some Perl and cutting and pasting a whole lot more, and added some crazy .htaccess URL rewriting to produce a basic system for producing books. It was pretty scratchy but it actually worked. Later a buddy helped extend the system and later still I was able to pay him and others to extend it.

At the time it pretty much comprised a page (per book) for creating a table of contents.

developed_blog_chapterlist

and an interface to edit the content (chapters). I ripped out the native wiki markup editor and replaced it with a WYSIWYG editor, I think it was TinyMCE…

developed_fm_farsi

As you can see Right-to-Left content (in this case, Farsi) was also supported. There were also some basic things in place for keeping track of the status of a chapter, the version number, side by side diffs, side by side translation interfaces, and, later, dynamic table of contents organisation and edit locks.

Coupled with some basic PDF rendering stuff and a way to push the content from the ‘draft’ to the publishing front end and we were away.

flossmanuals-1

It actually had some other pretty cool stuff, such as side by side translation interfaces…

flossmanuals-howtotranslate-sideby-en

Remix…

..a built in live chat for talking with collaborators…

booksprints-remotecontrib-chat-en

and even a way to send books between different instances (eg for sending a book from the FLOSS Manuals French community site to FLOSS Manuals Finnish for translation)….

flossmanuals-xchange-xchange_1-en
We could even render book formatted PDF and push to the lulu.com print on demand services. I just now checked and some of the books are still there!

Not bad for a Perl-based system, built on top of a wiki that wasn’t supposed to do this kind of thing, and built very with very few resources. The TWiki extensions were contributed back upstream to the TWiki repo and it was all open source but it was pretty hard to rebuild and no one I knew actually had a similar use case.

After this, I embarked on a journey to replace the system with a custom built solution specifically for book production. I can’t remember exactly when this started, maybe 2008 or 2009 or something. It was originally called Booki…

…which later became Booktype. Booki (and later Booktype) replaced the FLOSS Manuals tooling, although you can still see the working old tool here. That ole Perl code is still functional with no maintenance after 10 years, I can hardly believe it. The docs on how to use it also still exist.

Booki was built with Django (python) and pretty much had all the same stuff. Although the look and feel was changed quite a bit in the transition. There aren’t too many images around of Booki although I did find these screenshots of Booki taken by someone using it on the OLPC XO! (FLOSS Manuals did all the docs for OLPC/Sugar OS etc).

readingandsugar-booki-en

readingandsugar-booki5-en

It was hard to get financial support for it. Internet Archive gave us $25,000 at the time which seemed like a fortune. The evolution of Booki to Booktype represented me taking the project to a buddy’s in Berlin (I was living there at the time) based org (Sourcefabric) and parking it there so I could get more resources to build it out.

Booki/Booktype pretty much had, and has, the same stuff as the FLOSS Manuals system, just purpose built. So it had, a table of contents manager

images-cms-image-000003634

And a book (chapter) editor…

booktype_version_2_editor_screenshot

…chat…

booktype_2-0_edit_communication_tabs_chat

And the other stuff. Perhaps the only new features (compared to the FLOSS Manuals system) were a dashboard…

booktype_1-6-1_my_dashboard_740x429_1

…groups…

all_groups

and an interesting way to have Twitter-like messaging to pass snippets from chapters to other users.

figure-7_reference

Before I left Sourcefabric I wanted to get some other innovations built but didn’t get there. I did build some prototypes though. There was a task editor…

booktype-1024x531

…and live in-browser book design…

developed_booktype4-1024x768

Booktype is still going strong, now it is its own company (based in Berlin) and they also run the Omnibook commercial service using the software.

I left because John Chodacki and Kristen Ratan from PLoS invited me to come work for PLoS to design a new web-based journal submission system. I agreed…

But, before I leave the book story behind for a bit..I had set up Book Sprints as a company and put a small amount of my own money into building two new book production systems somewhere between leaving Sourcefabric and starting at PLoS. These two systems were PHP-based and Juan Gutierrez built them over some months.

juan

I wanted to do this because I was a little frustrated by Booktype not moving forward and also the platform was becoming more difficult to use. We were using it for Book Sprints but after I left the product took a new UI direction and I was finding Book Sprints participants were not enjoying using the system. So I built a Book Sprints specific system called… PubSweet… the namesake of the current Coko system which has eventually turned into something of a prototype for the new PubSweet… this new system was a lot simpler and easier to use than Booktype. It was initially meant to be modular but I think we lost that somewhere along the way. Cleanly modular systems take a lot of extra effort and time to produce so we gave in for speed of development’s sake.

The old PubSweet had a dashboard….

screenshot-from-2017-07-15-18-37-13

..table of contents manager…

ps1

and editor. Just like before!

screenshot-from-2017-07-15-18-40-08

We also introduced some new innovations including visualisations of the book production process…

developed_seo

Plus annotation (using Nick Stennings annotator software)…

screenshot-from-2017-07-15-18-48-01

and other stuff…I think threaded discussions, outline views, review page, an in-browser book renderer, book stats and I can’t remember what.

Anyway …I also built a platform on top of this old PubSweet for the United Nations Development Project. It was called Lexicon. Lexicon was pretty interesting as it opened my mind for the first time to the idea that an editor is not an editor is not an editor. Different content types (in a book) may require different editors or production environments.

Lexicon was produced to collaboratively produce a tri-lingual (Arabic, French, English) lexicon of electoral terms for distribution in Arabic regions.

screenshot-from-2017-07-15-19-09-11

Lexicon had all the same stuff as the old PubSweet but with one major innovation, you could create chapters that were WYSIWYG based, or you could create a chapter which enabled you to add and sort individual terms and provide translations.

screenshot-from-2017-07-15-19-09-34

It was a pretty interesting idea and we were able to make a really cool book which the UNDP printed and distributed across many Arabic-speaking countries. I still have the book on my bookshelf.

The other interesting thing was that the total cost for building this on top of the old PubSweet was $10,000 USD. This was mostly because we could leverage all the existing stuff and just build the difference…interesting idea!

Ok, so then I dropped book production systems around 2013 or so for a while and went to work for PLoS on a system that was called Tahi and then became Aperta. The name Tahi came from the name of the street I was living on in New Zealand before I had a US work visa and was designing the system – Reotahi Road (cool road). Reotahi means ‘one voice’ and ‘tahi’ means ‘one’ in Maori. It was built on Rails with Ember. Essentially the front end and backend were decoupled although it was really pushing the technology at the time to do this. I designed the system and moved to San Francisco to manage the team to build it.

Tahi (Aperta) had a dashboard (surprise!) and editor, just like the book production systems but I introduced two major innovations – Cards, and card-based workflow management interfaces. Unfortunately, while I was asked to come and build an open source system, things went a little weird at PLoS and they closed the repos, effectively making it a closed platform. So I quit. That also means I don’t have any screenshots to show you. Pity. If you sign an NDA with PLoS I believe they might show it to you.

However, you can picture it a little – imagine something like Trello, or Wekan – these are card based kanban systems. But imagine if you could custom make cards to do anything. Effectively cards were first class citizens of the platform and could access the db, perform system operations, make external calls, do validations, whatever you wanted. In hindsight, I think they were as close to an idea of an ‘app’ that you could have in a browser platform, although that wasn’t the way I thought about them at the time. Additionally, cards were imported into the system since each card was actually a gem file. This meant any publisher could custom make their own cards to do whatever they wanted and place them within the kanban-like workflow space (task manager). Pretty neat.

So, cards could be surfaced and used anywhere in the system. We used them for authors to enter submission data, but also for production staff to perform operations, for reviewers etc etc etc. They could also be placed on a kanban board to make a workflow. Cards could be moved around the workflow and deleted or new ones added at any time.

To manage all this my other idea was to let these cards flow through a TweetDeck-like interface. So you could sort cards, per role, per user, at volume.

Tahi essentially had four spaces – a dashboard, a submission page (which displayed the manuscript in an editor, and submission data could be entered through cards), a task manager (workflow for the article, using cards as tasks), and a ‘flow manager’ (the TweetDeck-like interface for sorting all your cards across all your articles). While the FLOSS Manuals, Booki and Booktype platforms were pretty much monolithic systems, the old PubSweet was sort of modular. However, Tahi did decouple the front end and back end but I wanted to also break these four spaces into discreet components. That would have given the system enormous flexibility but unfortunately I wasn’t able to do this before I left.

Anyways, Tahi/Aperta is a little old now but it was pretty cool. I don’t know what happened to Aperta but I believe it is now being used for PLoS Biology.

After I left PLoS I was offered a Fellowship by the Shuttleworth Foundation to continue on the mission to reform publishing. So I started Coko with Kristen Ratan (who was the publisher at PLoS)….

img_9224_792x445

So there are some themes from building the past 7 or 8 publishing systems (depending on how you count it… there were also some other interesting experiments in between). First, the next system you build is always better. That is for sure. It’s an important thing to realise because when I developed the FLOSS Manuals system I thought that was it. Nothing could be better! But I was wrong. Then Booki/Booktype and I felt the same thing. I was so proud of it and nothing could be better! haha… you get the picture. The reason why it’s important to understand this is because I think it gives someone like me a bit of freedom. I can take some risks with systems knowing you get some stuff right, you get some stuff wrong. But the next system will get that bit you got wrong, right. Taking this attitude also takes the pressure off and you can have more fun which is good for your health, the team you are working with, and the system.

As far as technical lessons learned… well… after looking back at all these systems when we started Coko, I realised that the idea of independent ‘spaces’ for publishing workflows had a heap of currency. How many systems did I have to build with baked in dashboards, task managers, editors, table of content managers, etc etc etc before I could realise it doesn’t make sense to do this over and over. I wanted to take the idea of these kinds of spaces forward and not have to build them again and again… so some kind of system where you could include whatever spaces/components you wanted would be ideal… This would have two very important side benefits:

I could learn so much because if the next system you build is always better, what about a framework that would allow you to easily build a whole lot of systems at once! Or build a lot quickly over a short amount of time… just imagine how much you could learn…
It would open the door for others to innovate. I have since given up the idea that my system (so to speak) was the best ever and no one could top it. That’s just the testosterone talking. I’m kinda over it (sorta). I want other people to be able to make better stuff than what I have produced so far, to bring in innovations I never thought of. I want to make that easy for them and now I understand a whole lot better how publishing workflows actually work I’m in a very good position to do that.

That was a lot of the thinking behind the new PubSweet – PubSweet 1.0. But there is some other stuff too. Through my time at PLoS, I came to understand just how many variables affect workflow choices in journal publishing and that each publisher has slightly different conditions and roles that affect this. That means that the access control is complex. We might think there are various roles – author, editor, reviewer etc that shepherd an article through a process but it’s not that simple. Any number of conditions can affect who gets to see or do what and when. So we need to have a very sophisticated way to set and manage this.

There was a lot of other stuff to take into account to but I mention these two specifically because recently when I was talking to Jure (lead PubSweet dev) about PubSweet 1.0 and reflecting on how far we came he nailed it, he identified the two major innovations of the system being:

reusable/sharable components (spaces)
attribute-based access control

I agree entirely. I think I might add another:

developer experience

It is pretty easy, and getting easier, for developers to develop publishing platforms/workflows (call them what you will) with PubSweet. I think it is pretty astonishing and I think these 3 characteristics put together enable us to build multiple publishing systems fast and in parallel (with small teams) as well opening the door for other to do the same and huge opportunities for innovation.

If we are successful at building community this will be a huge contribution to the publishing sector.

In a future post, I’ll break PubSweet spaces / components down in more detail. There were also a lot of other similar stories regarding technical innovations on the way (eg Objavi->iHat->INK), but I’ll break them down into posts on another day.

I meant to also talk about Editoria here, the monograph production system built on top of PubSweet, and xpub – the PubSweet-based Journal system.

2016-06-28_15-41-37

They are both pretty amazing and leverage so much more than the previous systems identified above.

I think the main thing with them is that we are working extremely closely with publishers using the method I developed – the Cabbage Tree Method.

Editoria Design Session

This means that I am no longer involved in building, what I would call, naive publishing systems. Naive in the sense that publishers could use, for example, Booktype, but it’s not really built for publishers. It’s a general book production system built by someone who didn’t know much about publishing at the time. That’s great of course, there is a place for it. However, Editoria is not a naive system. It is designed by publishers for publishers and the difference is enormous.

But I will leave a longer rant about this for another post.

I do however, want to say that I didn’t, of course, build any of the above systems by myself. There were many people involved and I have credited them elsewhere in this blog. I’m not going to do another roll call here except for Jure Triglav.

Jure and I sat down just over 18 months ago to discuss some of the lessons I learned as explained above. We jammed it out over post-its, whiteboards, coffee, and food in Slovenia and you can read a little more about that process in the PubSweet 2.0 RFC. But Jure trusted me, and I trusted him, and he took these ideas and, with a small team in very good speed, made them a reality. As a result, I think PubSweet is an exciting system and will only get better. Congratulations Jure, you deserve special thanks and recognition for the absolutely amazing job you have done.

dsc00516-1

Thoughts on Facilitation

I’ve been sitting on the beach trying to not think about work, which means of course I thought about work…. but in the way where clearing the mind brings up new insights almost ‘out of the blue’. It happens to me a lot when I get away, which is why I sometimes do my best thinking on trains, or at the beach.

I have been pondering facilitation. So here are a few thoughts. The following is very much a sort of scratch pad of ideas / stream of consciousness. I’ll put structure to it and flesh it out later.

First, I have been pondering what makes a good facilitator. How do you know when someone might be good at this. I think there are 2 personal characteristics that might seem contradictory but are essential:

they are very open
they are very controlling

The second one sounds bad I know. I will work out a better way to state this. But in my experience every good facilitator I know is in some way a bit of a control freak. They are also very (very) open. That might seem like a difficult mix to get right – it is! Which is why I’m kinda leaning towards this theory because I have trained several facilitators and the ones that don’t make it don’t strongly represent simultaneously in these 2 categories.

Second, pretentiousness or a ‘high minded’ attitude *does not cut it*. I say this because you can have the above two characteristics right but I’ve seen this attached to a much removed holier than thou attitude and that is the worst. No good facilitator is above the fray in this way.

Ok.. I was about to break out in a rant there… phew…

Alrighty…

Next the facilitator’s role – what is the facilitators job? I see it as this. The facilitator’s role is to maintain process and to pass decisions to the participants over substance.

Sounds simple. But in no way is this simple. To maintain process the facilitator needs to find ways for the group to invest in an artificial culture that is born on the spot. The rules of that culture are almost completely evoked and maintained by the facilitator. This small little bubble, or micro universe with its own rationale and rules, is what the facilitator instantiates and maintains. It more or less comes down to these two things:

methodology (more important than you think, but also not nearly as important as you think).
shaping human dynamics

In other words, your job is to manage what is done (methodology eg. the Book Sprint Methodology), and how it gets done (shaping the internal behaviors).

I think number two is the hardest to master since you can’t be good at any methodology unless you know how to shape human dynamics. And this is all about who you are and finding your own voice as a facilitator. There are so many tricks and techniques here I don’t even know where to start. Maybe a subject for other posts. But what I’d like to point out is that these two things put together equal process. Facilitators manage process so the participants can focus on the substance of what it is they are deciding/creating etc.

I say this because sitting on the beach has made me aware of one of the biggest issues with facilitation that I have experienced. When I used to facilitate Book Sprints I used to ponder why it was that Humanities academics and facilitators were the hardest people to facilitate. Also, in other Book Sprints, staff documentation writers would often prove difficult when I did Book Sprints that focused on documentation. Ponder ponder… now I think I sorta see it. It is because these groups have a strong opinion on process. Academics are experienced in writing books, so they believe they know how books are written. You come at them with something else, another way of doing it, and many of them just flatly freak out. I had one academic who literally said “you can’t just make up how you make books”. That was a pretty extreme example. I was able to bring her round but it was hard work. Facilitators also think they know facilitation process, so you involve them in something new and they almost always think they can see better ways to do it. They are almost always wrong (mainly because no path works the same for any two facilitators because of the need for each and every facilitator, in themselves, to be the instantiation for a temporary, micro, but very real culture). . Same with documentation writers… involve them in a doc sprint and you might very well be asking for trouble.

It is the facilitator’s job to bring the process to the people. If the people are domain experts (ie. know a lot about the topic) then no sweat, they will usually get in there quickly and invest in the mini culture you lay down. But if the participants have opinions on the process you get into all sorts of trouble.

So, that means there are two categories of people that need to be kept in mind:

domain experts – good to go, you should be able to get them inside of the bubble no problems
process experTs – spelled with a capital T for Trouble 🙂

Ok…. so I want to say one last thing before I go practice falling off a surf board inelegantly. There is a group of people that are also difficult to keep inside this bubble. They are, for want of a better word, the ‘power retainers’. These are people that either hold sway with the group because of their massive cultural capital (eg the elder states-person in a sector, or they are the boss), or they have such big egos they think they know whats best (usually they also don’t know when to shut up).

There are three possible ways these people can go:

they give the power away – they step back and let other people in, are careful not to dominate, they get in there shoulder to shoulder with others, really listen, go with the flow
you coach the power away – this can be exhausting, but it works more often than not and when it does it can be dramatic. I’ve seen people swing around from being destructively blocking to being the biggest advocates of the process within a day.
they don’t give it up – i have rarely seen this. Interestingly the two examples that come to mind have been Ministers (I won’t name the country or position!). The way they avoided ‘being one of the people’ was just to disappear from the process entirely. Maybe that’s their job – professional avoiders (hoho). Sigh.

I have to say, when I see people migrate from 2 -> 1 (above) they do nothing but earn my utmost respect. That is humility and human connectedness at its best right there.

But if someone is stuck on 3… that is really trouble and you might need to ask them outside for a talking to. In the past I have threatened to remove them from the process. That’s a tough tough call right there, but you have to get the rest of the group to where they need to be in the time they have. If you don’t make these tough calls you won’t make it. I have, by the way, only had to sideline people for a while. I’ve never had to remove anyone and I even had one elder statesman front up the next day and apologize to me and recognise why things had to flow the way they had to flow. That dude earned a place in my heart forever.

Anyways…back to the beach 🙂 ….