2018

So… it’s been a bit of a year. I was pretty busy looking back. I think I spent about 9 months on the road. I did some surfing. Bought a fridge. Plus some other stuff… so…. looking back….

The year started with a yet-to-be formed PubSweet community. PubSweet is the underlying ‘open infrastructure’ piece of the puzzle that enables folks to build any kind of publishing workflow on top of it. It is used for books, micropubs, content aggregation, journals… a lot. But at the beginning of this year there was one org building on top of it – Coko. Now, we have 9 publishing organisations building on it and 13 or so platforms in play. All that in one year… can you imagine. It is phenomenal growth. The best thing is the feeling in the community is awesome. As Geoff Builder recently said at a Coko meet “I can’t say enough how amazing it is that you aren’t killing each other”… very true.

This kind of growth and goodwill didn’t happen over night. I’ve been involved in many open source projects where there is no noticeable growth at all over many years. In fact, it was by watching these projects and trying and failing myself a number of times that I learned how to make this work. I had a plan from the start and strategised this growth. There are a few key parts…  First… the proposition is transparent. It’s a no bullshit kinda thing. You can’t buy your way in, you can only be part of this community if you play nice. You must be upfront and work in good faith. If not, then we don’t want you. So it’s transparent, we require transparency, but it is required. If you aren’t transparent then see you later.

Another critical piece was to develop processes for consensus. We have a number of workgroups that have helped with this. We also have an RFC process and 3 meetings in person a year where more difficult stuff can be meted out. It works very well. It is all also, by design. You must intentionally design such stuff and I spent a lot of time working through these scenarios in my own head. It takes time because each community has its own character. You want to make sure you have the right resonance with your strategies and sometimes I need to ponder this stuff a lot, let it sit and then bring it about. Also necessary is to have leadership. I provide a lot of that but I also strategised very explicitly for Jure to be the central pin for the PubSweet community. He is an awesome leader of the PubSweet clan but also it must be noted that this doesn’t ‘just happen’. Jure and I spent a lot of time talking through these things, working out what sort of tone we needed, how to best enable people to feel they could be part of this while curating it so it’s not a free for all. Jure has really risen to the challenge and IMHO stands as a case study of good community leadership.

Andrew Smeall from Hindawi and Paul Shannon from eLife have been early leaders in this community. To have such goodwill and leadership from folks like Andrew and Paul is really amazing. They have been in boots ‘n all from the beginning and never blinked. They are heart n soul and mainstay keepers of the PubSweet community ‘way’. I feel very privileged to work with them.

Also at the beginning of the year, Editoria was alive but no books were being put through. We have since changed that with at least three scholarly publishers using it in production as well as Book Sprints using it (recently used in a World Wild Life Fund Book Sprint). We got there also by careful strategy. Alison McGonagle-O’Connell has been out there presenting, demo-ing, and explaining Editoria to all comers. Alison is a joy to work with and I admire her can-do immensely. She’s a tough cookie and now the wizard of Editoria. Alison has brought people closer to Editoria which peaked this year with a Editoria community event. We got about 35 people there and I facilitated the process (after designing the event loosely based on the PubSweet events). Critical was a newly designed Feature Proposal process. I had to design it so that publishers with no in house dev resources could ‘take ownership’ of the product and also so that publishers, rather than technicians, could write the proposals. We received 36 proposals in 2 weeks from 6 publishing orgs. Amazing. There is now a 3-month roadmap in play because of this.

xpub-collabra and perhaps micropubs will go through similar process transitions next year.

paged.js is also flourishing. I started the project with Shuttleworth funding in Feb and now it is integrated into Editoria and it has already been used for several books. It is also growing quite quickly as a community, some of this is ‘auto growth’ – growth that just occurs with no assist – and some of it is from the efforts of the paged.js crew – Fred Chasen, Julie Blanc and Julien Taquet. Julien in particular is proving to be a very good community leader in this area. They are an amazing crew doing amazing work. I don’t suffer from FOMO (fear of missing out) but I really regretted not being able to go to the paged.js workshops in Paris and Brussels in November. They looked amazing.

Then there is Wax…. the editor is growing fast. We had to rebuild it because the libs we were using were not supported and slow growing. But Christos knuckled down and got it done.. amazing. It is currently a one person endeavor but watch this space as I have plans for community growth around it next year.

XSweet, the XSLT docx-to-HTML converter is also going great guns. V2.0 with math support out in the next weeks. This more or less completes all the things we need form it and the lib will flick into a maintenance mode.

Then there is Workflow Sprints. The process I designed for helping publishers work though their workflow woes. It takes 1 day per org/workflow and has proven to be extremely effective. I’m now training facilitators to do this as it is proving popular and I can’t do them all next year if it comes down to that. Coko is also able to generate revenue from it which is cool.

Then there are design sessions which I still facilitate for various products including Editoria, xpub-collabra, and micropubs. All interesting projects and the design sessions are fun and sooooo effective. Who said publishers couldn’t design their own solutions? Not me…

Also this year I have been peripheral to the Book Sprints team. I gave up direct involvement when I got my Shuttleworth Fellowship. Thankfully Barbara was there to take the helm and has done an amazing job. We have had a couple of meetings this year and it has been awesome. We broke 1m NZ this year for the first time…amazing. Many people still don’t think it’s a real thing 😉

Also from Book Sprints we get many requests from people who love what we do but want ‘not a Book Sprint’…ie they have some other format/media/context etc they want to think about. So this year I have also founded SprintLabs to act as a bucket to put these experiments in… more on this in the new year.

Also this year I finished my Shuttleworth Fellowship having reached the 3 year maximum and became an alum. That was quite a moment. Strange thing is, I feel more a Shuttleworth Fellow now than I ever have 🙂

Needless to say my journey is unconventional. All this stuff is stuff people told me wasn’t possible. All of it. Book in 5 days, impossible! You can’t use browsers to typeset books! Headless modular publishing CMS – impossible! Publishing platforms are an intractable problem! You guys will never be able to build community, it just won’t work!

Yeah yeah. Fuckem.

And there was a lot of other stuff this year too. But honestly, where do I get the time? Where do I get the time to surf? I have no idea. One of the tricks though that I have learned is to trust the people you delegate stuff to. Create an environment for them to succeed and let them go. For the most part I just need to talk things through with them and help keep them and everything on course. They also have to go with my rather counter-intuitive, emergent, way of problem solving and doing things. If they can’t then it doesn’t work out, if they can then we do great things. Which means, of course, lots of travel is needed and talking to people. I am a great believer in remote teams but I am not a believer in remote-ness. If that makes sense. You gotta be close to people so they can trust you and you trust them when you aren’t there. Its for this reason some of our meetings happen on beaches 🙂

It is what it is. It’s been a huge year.

Still, got to make a surfboard this week and 2 Workflow Sprints to go (in the US)… no matter, I’ll be here in no time…

Feet up mate, Koutu
Feet up mate, Koutu

Workspaces

Recently at the PubSweet Book Sprint we put together a chapter on understanding PubSweet Workspaces. Workspaces are reusable components that you can use to assemble a publishing platform. Henrik developed some icons during the sprint to represent this idea and you can see the depiction of the xpub-Collabra platform described in this visual language below:

02-adam-workflow-v3

PDF chapter below.
workspaces

OHBM Announcement

Last week I worked with the cool people at the Organisation for Human Brain Mapping (OHBM) and today they have a new announcement.

We are now working closely with the Collaborative Knowledge Foundation (Coko) to put together a publishing workflow, and we are grateful to the Canadian Open Neuroscience Platform (CONP) for providing generous support for the development of Aperture.

Coko has extensive experience developing open source publishing components, some of which are used by Elife and other open-access publishers. Their framework could give the Open Science SIG and the broader OHBM community the opportunity to participate in the construction of Aperture. We look forward to establishing even more collaborations with like-minded partners.

https://www.ohbmbrainmappingblog.com/blog/announcing-aperture-the-ohbm-publishing-platform

 

Workflow Sprints

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…

Wormbase

dsc04365
dsc04338
dsc03635_792x528
dsc03404_792x528

ArXiv

20170929_114707-s
20170929_110158_1008x756
20170929_103400-s

Collabra

l1030128

Erudit

img_9414 b8e8b1c7df4a5fb2a6c58ac05b294280 0d97bd808c1dcb881f974082ebc7882f

UCP

Kate and Cindy (UCP production staff) designing their system (Editoria)
9dff4e076e72846d42c1047f22f4883b

EBI /EPMC

team
y

AUT

6df1a81c23ef48c246296b158a2efb64-1024x576

Workflow Tweaking at Coko

Yannis and the Athens crew have been tweaking our workflow for the products built on top of PubSweet. This includes (at present) Editoria (book production system) and xpub-collabra (Journal system).

Essentially, after the initial design and build process we slip into faster iterations where I step out of the way and the ‘client’ and developers work in very fast iterations to tweak features and fix bugs. We loop in Julien for UX as necessary. Then we move into a stabilization phase for landing the product.

Right now both Editoria and xpub-collabra are in the tweaks and bugs phase, and we have started adding a ‘roadmap’ to each of the READMEs to list what we are working on now. See:

https://gitlab.coko.foundation/xpub/xpub#roadmap

https://gitlab.coko.foundation/editoria/editoria#roadmap

We’ll be adding a similar table to XSweet and other products. It is a simple, readable, format.

Aperta Halted

A part of my personal history is a platform called Aperta which was previously called Tahi. It was a PLoS project and I was hired to design and build it. I quit when the PLoS Board decided to close the repositories, effectively making it a closed project. The repos remained closed, and as far as I know, are still closed today. Ironically after I left, they renamed the project ‘Aperta’ – Italian for ‘open’. A really silly marketing move to reassure everyone that despite what they may have heard, the project was still open…that was perhaps true, albeit (ironically and literally) in name only.

Now, it seems, the platform dev has been halted. Feels good to me. From what I heard (and I didn’t hear much), PLoS didn’t take the project in a good technical direction and generated a significant amount of bad faith and market confusion while trying to develop it behind closed doors.

To quote the new CEO Allison Mudditt (who I respect very much, Coko worked with Alison when she was at UCP):

Part of this initiative will involve changes around the workflow system – Aperta™ – we set out to develop several years ago with the goal to streamline manuscript submission and handling. At the time we began, there was very little available that would create the end-to-end workflow we envisioned as the key to opening research on multiple fronts. But the development process has proved more challenging than expected and as a result, we’ve made the difficult decision to halt development of Aperta. This will enable us to more sharply focus on internal processes that can have more immediate benefit for the communities we serve and the authors who choose to publish with us. The progress made with Aperta will not be wasted effort: we are currently exploring how to best leverage its unique strengths and capabilities to support core PLOS priorities like preprints and innovation in peer review. This will be part of our planning for 2018.

http://blogs.plos.org/plos/2017/12/ceo-letter-to-the-community-mudditt/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+plos%2FBlog+%28Blogs+-+PLOS%29

I hope that PLoS releases the technologies that have been developed for Aperta (there was a lot more than just the submission system) into the open… with both open repositories and open licenses AND, more importantly, an open heart. Collaboration and openness is more to do with how people are than what open license they choose and several of the practices, including asking potential collaborators to sign Non-Disclosure Agreements (NDAs) before getting a demo of the system, were ridiculous and ungenerous.

Having said that, it would be awesome to see all that work released into the open, in open repos with open licenses, and no more blurring of the word ‘open’. Afterall the systems developed that included Tahi were all paid for by researchers. The PLoS Article Processing Charges fuels PLoS and they committed some of this revenue to the development of Tahi. When I was there, no external funding was secured for developing the system. Pedro Mendes made a good point in response to the announcement:

ha

There is some merit to this, but I do applaud PLoS for being adventurous, and if it had worked then the result would have been APCs could be lowered, not just for PLoS, but for any Journal out there reliant on expensive and dysfunctional Manuscript Submission Systems. Allison also notes this in a discussion below the post mentioned above:

…the original idea was that Aperta would allow us to eliminate or speed up the slowest steps between a finished work and its publication in order to reduce the cost of our publishing services

That is true, and it was an admirable goal. However, whatever the journey was between then and now, the project should have always have been out in the open as a public asset. Open for science, open for access, open for source, open for all – and the fact researchers paid for it but it was turned into closed project mid-flight is reprehensible and in the end it worked against PLoS, in particular, it severely weakened PLoS claims to supporting all things open. What a mess.

But, it can’t be ignored that Tahi is about 5 years old now, which is old in software years. A entire generation of technologies that are better suited to solving these problems has arisen in that time. The system is now not much more than a still (just) relevant but outdated approach. That is the risk you take when you develop things behind closed doors. By the time you release it (or don’t in this case), it is out of date. That said, it would still be good to release it, but there are better technologies and approaches out there now.

So I look on with interest to see what will happen next.  I sincerely hope PLoS can return to cutting a path through publishing and exploring and enabling a viable Open Access model that others can follow. With Allison at the helm I am betting things are going to take a much needed turn for the better, not just with this project, but on all counts.

As for me, I learned a lot from designing Aperta (I prefer to call it Tahi). The design process was an introduction to scientific journal publishing for me. I learned a great deal. Tahi gave me, at the time, an unencumbered dream time to imagine something new. It had a lot of interesting innovative approaches and if I had stayed with the project it would have ended up close to where PubSweet is now as I wanted to completely decouple the ‘spaces’ (a concept important to Tahi). It would not have been as good as PubSweet at doing this as a complete ‘decouple’ really has to be imagined from the start, and isn’t as clean if retrofitted. Still, the system would have been a lot more flexible and reusable.

But that wasn’t to be. Don’t get me wrong – I don’t think Tahi was the perfect platform, but it was a pretty good starting point with some significant innovations. At the time, I was looking forward to shaping Tahi with use and to mature it into an excellent system. The good news is, the next platform you design is always better.  I took a lot of what I learned (I have now been involved in instigating around a dozen publishing systems) to my next development, and worked hard to re-conceptualise a new system that avoided some of the mistakes I made with Tahi, and took some of the good parts a whole lot further. That new project is PubSweet and it is looking awesome, and leverages modern technologies and approaches to the max – mainly thanks to the bunch of amazing folks working on it within the Coko team (particularly Jure Triglav) and also now, increasingly, from the collaborators we work with (at this stage mainly eLife, YLD, Hindawi and ThinSlices). Also a huge thanks to the Shuttleworth for backing me, especially because it was at a time (I had just quit PLoS) when it was very much needed. Their backing meant Coko was possible, and consequently, PubSweet and everything else we have done.

Anyways… it was past time PLoS moved on too from Aperta and congratulations to Allison for making the right call, especially given that it would have been a difficult one given the cultural forces at play inside of PLoS.

1+1 Design Method for Workflow

So, I think I’m formulating something of a design strategy for publishing workflows. I’ll call it, for now, the 1+1 Method. It is not a facilitation methodology like the Cabbage Tree Method, but more of an approach for encapsulating workflows within the simplest and most flexible system possible.

This is very much a work in progress.

The basic idea comes down to this – workflows seem complex when you map them out. There are many forks and eddies and cul de sacs, as well as seemingly ad hoc tasks and unique circumstances. When you map out a workflow like this, you tend to get a complex route with many optional routes determined by a variety of variables and dependencies.

If you build a system that ‘hard codes’ that logic, then you face a number of problems, the most important being:

  1. you tend to create a system that reflects the present with only slight optimisation
  2. the system is prescriptive and inflexible and does not provide a path to future optimisation or, even possibly, radicalisation of workflow

So, how to avoid this? The answer is to design a system that is simple and can be optimised easily. I’m guessing you are thinking this is not really a very helpful answer! True enough… so let me attempt to break this down a little. What we need to do is first understand the organisational workflow, and then design a system that will enable this using the concept of ‘workflow spaces’. We need to create as few of these spaces as possible, and reuse as many of these spaces as possible. Further, we need to move people into these spaces at the moment that something is required of them.

I’ll get better at explaining this over the next months, I’m sure…I’m still working out a language and conceptual framing of this that is easy to communicate and understand….

But let’s look at a simple example… say, a Journal publishing workflow. In this example the workflow looks like this (keeping it relatively simple):

  1. an Author creates a new submission
  2. they fill out the required information and submit
  3. an Editor checks the submission and rejects the submission or assigns a Handler
  4. the Handler checks the submission and invites reviewers
  5. Reviewers accept or reject the invitation
  6. the Handler invites new Reviewers if necessary
  7. Reviewers write reviews and submit
  8. the Handler reviews the reviews and writes a decision to accept (goto (11)), reject (falls out of system), or ask for a revision
  9. the Author reads the decision and changes information if necessary and resubmits
  10. the Handler checks the revision, if all is ok it passes to production, else go to (4).
  11. Production
  12. Publishing

This is relatively a relatively simplified and generic Journal workflow, but you can see some forks in the paths… In my experience, most Journals have the above but with additional organisation-specific forkings and nuances. So the above is very much an ideal simplified state.

So… if you were to develop a system that takes the object, in this case a journal article, through this process, then you have a pretty complex conditional system. For example, there is two-fold circularity at play. First, there may be more than one round of reviews so the system has to be able to cope with this, second more than one round of reviews requires the same amount of decisions. That’s pretty complex already. The mistake most systems make is to try and program this path into the system in a very prescriptive and linear manner – which is difficult to do and, more importantly, hard to change once done.

So… how to get around this? Well… the answer is to use this emerging 1+1 Method I’m trying to articulate here. It is a simple way to encapsulate workflow, leaving the door open for further optimisation and innovation. To achieve this, you must walk an article (or whatever object it is) through all the steps of the workflow, but while doing so keep in mind the following:

  1. for each step, you are only allowed a maximum of 2 spaces. A common Dashboard, and one other space.
  2. push all light, single issue, tasks to the common Dashboard (space 1)
  3. if necessary, push the other tasks for that step to another space (space +1)
  4. reuse as many +1 spaces as possible, merge as many +1 spaces as possible
  5. indicate to each player/role they have something to do through Dashboard status/notifications, providing links to +1 spaces only at the appropriate moment (when they have a reason to use that space)

That’s pretty much it. What we are doing is telling a story to each participant (those that have something they need to do at a certain time), that there is something they need to do now and they have to go here (Dashboard or +1 space) to do it. When they have completed that task, the next participant gets their notification that something needs to be done and they are provided with the means to do it (an action provided on the Dashboard, or access to a +1 space).

So the journey of the article is managed through notifications at the appropriate time to the right people. This means that if we need to optimise the workflow, by either collapsing some steps or adding some steps, we don’t need to redevelop the whole prescriptive, linear workflow logic of the system. We simply need to tweak the order of notifications. Additionally, if we decide that some new innovative process should be introduced, we can do so by either tweaking an existing +1 space, or adding a new one (introducing it to the relevant participant at the relevant time through Dashboard notifications).

That keeps the system intact, and allows us to tweak and optimise/radicalise, as we go.

In the case of the Journal workflow above…. a 1+1 solution might look something like this:

  1. an Author creates a new submission  – Dashboard
  2. they fill out the required information and submit – Submission Page
  3. an Editor checks the submission and rejects the submission or assigns a Handler – Dashboard (notification) + Submission Page (to check the Submission) + Dashboard (to accept or reject an assign Handler)
  4. the Handler checks the submission and invites reviewers – Dashboard (notification) + Submission (to check submission) + Reviewer Assignment Page (to manage Reviewer Assignment)
  5. Reviewers accept or reject the invitation – Dashboard
  6. the Handler invites new Reviewers if necessary – Dashboard + Reviewer Assignment Page
  7. Reviewers write reviews and submit – Dashboard + Review Page (includes submission)
  8. the Handler reviews the reviews and writes a decision to accept (goto (11)), reject (falls out of system), or ask for a revision – Dashboard + Decision Page (includes Submission and Reviews)
  9. the Author reads the decision and changes information if necessary and resubmits – Dashboard + Submission Page
  10. the Handler checks the revision, if all is ok it passes to production, else go to (4) – Dashboard + Submission Page
  11. Production
  12. Publishing

Of course, the above could be simplified still, or you could move some elements around. The reviewer assignment could, in some workflows, occur from the Submission Page. Or, perhaps, the reviews could be placed on the Submission Page…. these decisions are dependent on your organisational needs, what information needs to be shown to who etc…

The point is, the entire workflow above, with all its loops and eddies, has been created with just the following spaces:

  1. Dashboard (primary space for everyone)
  2. Submission Page
  3. Reviewer Assignment Page
  4. Review Page
  5. Decision Page

Just 5 spaces.

Now, the above is still in need of a better explanation. If you want to get a feel for how it works, I suggest you think of a workflow that you are involved in. Simplify it a little, since this is just a first exercise, and then write down all the steps in order. Now… work through this 1+1 method. Start with the Dashboard, rely on notifications to keep everyone in the flow (exposing to them to the right Dashboard action or space at the right time), and conservatively add a new space only when you are sure that:

  1. that action couldn’t easily be handled in the Dashboard
  2. there isn’t another space that could ‘house’ this action sensibly

Walk through it once. You could even do it with Post-it notes representing the spaces if you like. Then sit back, look at it and ask yourself could it be simpler?

Then play with it a little. When you have a good system you could even play with some innovative new spaces – put them into the steps and ask yourself what that space would look like and who should it appear to and when…. you’ll see how easy it is to innovate with a system that enables this kind of workflow….

Needless to say…. that is why we created PubSweet… There might be more technologies like it, but if there are I’m not aware of them (let me know if you know of any). Also, if you have any feedback or thoughts on the above, especially on how to improve the explanation, then please let me know!