workflow sprints

What is xPub?

So, there are a lot of product names at Coko – PubSweet, Editoria, XSweet, INK, xPub etc etc etc… so becoming tricky to track, but I wanted it seems there are quite a few people interested in xPub right now.

xPub is not really a product as such, it’s more a group of products – each of which relates to Journal workflows. The names for each product indicyae those relationships: xpub-collabra, xpub-elife, xpub-faraday (Hindawi) and xpub-epmc

Each of these is a platform, so yip, you read it right – there are actually no less than 4 journal platforms being developed in the Coko community, not including the Micropublications platforms (of which there are two – one developed with Wormbase, and the other with the Organisation for Human Brain Mapping).

So, right from the get go our ‘offer’ is not standard. We don’t offer one platform to rule them all – there are many journal platforms in production. All of these are built on top of PubSweet… PubSweet is a kind of ‘headless’ publishing platform….it’s more or less the backend brains in that it is a kind of framework that ‘thinks like a publishing system’ but has not determined a workflow for you. So, each of the xpub-* platforms are actually publishing platforms built to meet a specific workflow and built on top of PubSweet…

Here is a crappy diagram (drawn in haste) to get the basic idea across:

In the above, you see a PubSweet platform (eg. xpub-elife). PubSweet itself is the whole app – it sort of ‘encapsulates’ everything. Really though, you get the PubSweet core and then extend it with front-end components to meet your workflow needs. A typical front-end component might be a login screen, or a dash, a submission info page, a reviewer form etc.

You can also extend PubSweet on the back end as well (eg to enable integration with external services etc). The following is a more accurate but slightly techy architectural overview (you can skip this image and the following paragraph if you want to avoid the slightly techie part of this article).

ps2

In case you are wondering – everything is written in Javascript. Why did we choose JS? It was a deliberate choice to go with a language that was prolific. Almost every dev around these days needs to know some Javascript (it’s the most popular language by far on Github), this makes finding a developer to work on your project is as easy as we could possibly make it. JS is also a phenomenal language these days. Fast, sophisticated and more than capable of supporting large-scale publishing requirements. I mean, if it’s good enough for Paypal, Netflix, Linkedin, Uber and ebay, then it is good enough for you.

So each PubSweet platform has its own collection of front and back end components to meet the workflow of someone’s dreams… the idea is that to achieve the platform of your dreams you can reuse what others have already built and then just build what isn’t already available. In a sense, you can ‘assemble’ your platform from existing parts.

c1e22edf10cd018c9d1a697c29fbd891

The nice thing about this is that each of the organisations building Journal platforms are sharing the following:

the same back end/framework (PubSweet)
various front (and back) end components
lessons learned…

Each organisation has a vision of their ideal Journal workflow. They then design and build this on top of PubSweet, but as they do, they build various components (either page-based components such as a dashboard, or smaller UI components we call atoms and molecules) and they share these components with everyone. Hence, you should check the list of components before you start building in case the component you need already exists.

We have various agreed-upon ways to build and share components (see this as an example). These best practices are continuously evolving but you can read some of the latest discussions about this approach here – https://gitlab.coko.foundation/pubsweet/pubsweet/issues/408

Of course, all code is reusable in the Coko community because it’s all open source. The best practices are there to make the code easy to reuse.

All agreements as per above are made by consensus by the community. It is actually a pretty snappy process – don’t believe every crappy thing you read about how open source is built. Open source community processes can be elegant and fast, and the resulting code can beautiful. Coko is a good example of this – a community of professionals collaborating together to make fantastic open source software.

So… back to the xPub story. To make these decisions on how to share components etc, we have regular meetings with various workgroups (we keep the numbers in each group small so we can move fast), and we also have quite a few in-person meetings. Not only do we have PubSweet community meetings where all of these organisations meet, but we have various get-togethers on various topics if required. For example, we met in Cambridge recently to discuss Libero (the eLife delivery product), before that EBI there was an onboarding session in Athens, next month we have a special designers workgroup in-person meet, anbd so on. All this helps us keep in contact with each other, which helps build trust, but also turns out to lift energy levels and boost production. These meetings are fun.

Also at these meetings, we learn from each other. One of the big problems in this sector, and one of the reasons people ask ‘why are publishing platforms so hard to build?‘ (after a number of high profile failures), is that there has not been a focused effort to share experiences on how to build publishing platforms. So, that is what we are doing – at each meeting we talk about what we have learned, how we are thinking about things, and show each other what we have done. The last meeting, for example, each xPub platform gave a deep dive to everyone in the group in a process known as speed geeking (it wasn’t so speedy as each table had 25-30 mins to go through their platform).

So, xPub isn’t a single platform, it’s more the community that is building journal platforms on top of PubSweet and sharing learnings and components. It is a very cool thing.

As a community, we also produced a book entitled ‘PubSweet – how to build a publishing platform’. You can get this for free here – https://coko.foundation/books/

I can also send you a print copy (they look great!) if you send me a postal address.

The book covers many things – a whole lot of technical documentation for how to build and share components etc, as well as some information about to think about workflow and how to map this into a PubSweet system. Personally, I don’t think the technology is very hard when it comes to building platforms – we knew what we wanted from the beginning with PubSweet and went about and built it (not to downplay the extraordinary job Jure Triglav has done in leading this effort). But the real hard stuff is actually thinking about workflow – not many publishing orgs have had the opportunity to think about designing their workflow to meet exactly what they want (rather than shoe-horning it into an existing system), and so we have had to beat this track for other to follow. It has been quite a journey but the book pretty effectively outlines how to think about workflow (which of course is a process that can be accelerated using Workflow Sprints which is a process I designed to facilitate a publisher to design their own workflow and PubSweet platform in one day).

0e7a0345

In that book you can see some high level ‘architectures’ of each of the xPub platforms such as the following (xpub-collabora):

02-adam-workflow-v3

Or this (xpub-epmc):

ebi

So, you might be asking…. at what stage of development are each of these platforms? … I’ll leave it to each of the teams to say exactly, but it has been shocking to see how fast things have come along. I mean, the xPub community only really got together for the first time mid-last year, and building started for most late last year and early this year. It looks like we will have a lot of platforms landing by the end of this year. In this sector that is lightning fast. EBI are particularly impressive – they started two months ago and are almost ready to go – if it weren’t for the fact we are all replacing the under-the-hood data model we designed together at the last PubSweet meet, they would be good to go already. They can achieve such speed because they are reusing a lot of the components that the other teams built before them (and because EBI are just very good 🙂 ).

I can speak a little more about xpub-collabra since that is the platform Coko is building for and with the Collabra Psychology Journal. It’s looking pretty nice. We have some work tidying up the UI, replacing the data model and a few other things, but it’s looking rather good. We are also putting some time into making it a generic platform since the Collabra workflow follows a fairly ‘plain vanilla’ model. So we are building in some management interfaces and various bits and pieces to make it more widely useful – for example, Giannis just built in a Submission Info builder – enabling a Journal admin to build their own submission forms. It requires some hand-holding to use right now, but we’ll shape it to be very usable by your general journal adminy-type. We also have to integrate ORCID and DOIs, extend the range of submission file types etc… but it’s pretty close.

Below is a video showing xpub-collabra in action. It is a a version from some months ago, but you can see the workflow pretty well in this demo.

I think most of the xpub community is going to offer their new platforms to the market in various ways. This will be interesting as there are very different approaches at play. Hindawi, for example, is looking to make their platform a multi-tenant platform, eLife will put JATS at the centre of the workflow etc… So look for more news on that also. For our part, Coko will offer xPub through a partnership with a hosting provider – probably with the same organisations we will work with for Editoria hosting services. Since everything we do is open source, we will also be supplying all the Docker, Helm and Kubernetes scripts so that you can set up your own commercial hosting service if that is your cup of tea (or you can extend your offering should you already be a hosting provider). Coko is pretty close to getting our first hosting partnership set up, so look for news of that soon!

One last thing – because of the modular nature of any platform built on top of PubSweet, it is possible to take any of the xPub platforms and customise it to meet your needs. No need to start building from zero. Additionally, the modularity means you can extend the systems with your own interesting new innovation – finally a place for innovation to call home in the publishing platform world….

So… there is a lot going on in the xPub world….we look quite different to the rest of the market because we are not building one platform – we have instead focused on building a community to support the development of multiple platform solutions for journal workflows. You can pick and choose which one you want, or build something else, reusing as much of the other systems as you can to reduce your development costs (we also spend a lot of time onboarding new folks and supporting them as much as we can).

But it’s not just about improving the game today – supporting the optimisation of workflows is one part of what we are trying to do, the other is to support future innovations.

If you want to know more, feel free to jump into the Coko community channel and chat – https://mattermost.coko.foundation

Come and join the party. We are happy to support you and happy to learn from you…. not-for-profit or commercial we don’t care, build a better journal platform on PubSweet than the rest of us and we’d be happy! We are in it for the mission – come to talk to us! no preciousness here 🙂

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…

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.

Some years ago I came up with a methodology called Book Sprints. It is a facilitated process that takes a group of people to collaborate on producing a book in 5 days. Zero to book in 5 days as we say.

There has much I have learned from this methodology which can be re-purposed. After 10 years working with Book Sprints (10th anniversary this year!) I now know a lot more about why it works and what kind of situations would fit this kind of process. For example, facilitated methods like this don’t work when there is just one person that has the knowledge that is needed in a book. For help with this one author approach, you need either a coach or a ghostwriter. Ironically, when I started Book Sprints I was in exactly this situation…I couldn’t Book Sprint about Book Sprints because I was the only one doing them.

But when you get two or more people …it starts to get interesting…. this is because Book Sprints are very good at developing a shared mental model of the problem very fast. The more minds with the right domain knowledge that come at this together, the better the result… with a few caveats… For example, it seems a natural limit for the number of minds to share the process is about 15 max. That’s because too many minds go too far too fast and you might end up with quite a lot of fragmentation. However, if you have the right people, the right methodology, and (most importantly) an experienced facilitator that knows how to wield the methodology – then magic can happen.

Anyway… I am now applying myself to taking these lessons and developing a new methodology, working title ‘Workflow Sprints’….what is it? Well… I have seen similar problems with the speed of production for books in the software world… The problem is – how do you redesign a (much) better workflow, and then design a platform to meet those needs quickly? What I see happening is that organisations will employ someone external, or re-deploy internal staff, to do a workflow audit, interviewing all parties, create a report with flow diagrams, and then use this as a basis for the developers to imagine a better way of doing things. It is a very linear and disconnected process, and it takes a very long time.

I believe that I can facilitate a group to do this in 2 days. In fact, I’ve already done it. Recently I went to EBI (Europe PMC folks) to do a workshop on their workflow. In a day we had redesigned it and had mocks ready to go. I was curious to see how much this remained true over time, and it appears that they are sticking to this design. They will fill it out, to be sure, but they had the starting point in a day.

It’s not the first time I’ve facilitated workflow development in a couple of days; there have been a lot of workshops I facilitated with various publishing entities on the way, but this was the first time I felt confident enough to go in boots and all. Now that I see how the process can work ,I’m going to try and make this a thing. I have thought about the workflow I want in order for this to happen, and I’ll be trying it as a full-blown method and workflow in the next few months with an org or two. The aim is to produce a summary of the current workflow (this takes a long time if using a legacy ‘interview’ process and much nuance is missed and I’m confident we can get a better result), a summary of the optimised / improved workflow, and wireframes of the new platform. All in 2 days. Which also means I can make this very cost-effective, a whole lot faster than legacy processes, with better results and internal buy-in since it’s the internal staff that design the new workflow and platform for themselves.

It is quite an efficiency. I’m hoping it will be something publishers can consider doing in the early phase of deciding whether they want to migrate to better workflows.

Quite possibly, you think this is a big call. But I’ve done this before. When I started Book Sprints I didn’t come across anyone that thought it was possible… this feels very similar.

I think it is going to work very well. There will always be challenges as you can’t anticipate how all the variables at play will come together on the day. But I have been there before with Book Sprints, and I’m pretty confident in my facilitation skills… So here goes….

Once I’ve proven this out with a few orgs I think this could prove to be extremely beneficial to any publishing org that is pondering how they can improve their workflow – with or without new technology. It could be useful for any org, for that matter. Interesting days.

Some photos below of some of the orgs I worked with to help define this process…