Design for Community

Recently we took the Editoria product, which is relatively mature now, to a newly designed community process. It was an interesting exercise. We had previously been developing explicitly for the requirements of one organsation – UCP. The task was to now take the product to a community and transfer the mandate of ‘ownership’ to multiple organisations and individuals (‘the community’).

I’d done it before, but this case was significantly different. Most recently I had designed processes that successfully turned PubSweet, the core ‘headless CMS’ from a product developed in isolation (essentially by Coko for Coko) to a community-owned product. I designed a strategy to transfer that mandate and engage a series of early adopters – namely eLife and Hindawi – through a series of events. These events were carefully crafted to communicate that we wanted to embark on a disarmingly frank journey of trust and good faith – to expose an offering, warts and all, to those organisations attending to take collective and collaborative ownership of the product and the vision.

From the outside it might look like we were offering a product – PubSweet. But that is not what we were offering. We were offering trust and goodwill.

These offerings can only be made if there is genuine good faith and a willingness to offer to build trust amongst all parties. This must be communicated by being vulnerable and humble.  At the same time, the offering is not without vision – there does need to be a core ‘hook’ that people can rally behind.

So, with PubSweet I designed and facilitated a series of events to do this. The first event was to get the main players onboard, and we are very lucky that Hindawi and eLife were all in, which is a reflection on their own ability to work in good faith and trust.

The following events were curated to cement a culture where collaboration by virtue of trust and good faith was shaped. I designed processes for transparent collaboration, and before long, these processes became part of the culture of the PubSweet community. It works now very beautifully. We can always improve things but we have instantiated a very successful and productive collaborative culture and it is a very healthy community. So much so that it is, to some degree, now self-replicating. When EBI joined the community much later, they were inducted into an existing culture and expectations were clearly articulated by the community in how they acted. That is what a healthy community culture is all about, and to be sure, it doesn’t happen accidentally, it is intentionally designed and purposefully facilitated. When it works (to a degree) it maintains itself (after a while).

So, when it came to Editoria, I needed to come up with a similar strategy. Except that in this case, the stakeholders were not builders. None of those interested in Editoria had developer or designer folks in their team that could commit to contributing to the development of the product. This is entirely unlike the PubSweet community which consists entirely of orgs with their own dev teams.

So, the context was quite different. How then do you hand over the ownership of a product to a community that cannot itself change that product? What is there to own? What is there to collaborate on? Where is the shared interest?

For this reason I curated the Editoria meeting to articulate our desire to transfer the mandate to the community. It was also done with a sense of vulnerability and humility. I designed a flow during the meet to lead up to handing over the ownership of the product to the community, the pivotal moment being a Feature Proposal process which I communicated near the end of event. The Feature Proposal process enabled anyone (org or individual) to propose new features and changes to Editoria. These would then be filtered through a transparent selection process and the selected features would be built. In this way now the community can affect the product. They literally effect its development path. They can change it, they have a shared interest in the development of the product and a reason to collaborate.

In the two weeks following, we had 36 Feature Proposals made by 5 different publishing organisations. That is amazing. These were not insignificant proposals and also there was a lot of discussion within the newly formed community about the relative merits of each, what could be improved, who thumbs-upped the ideas etc…

Again, this process didn’t happen accidentally. It was intentionally designed and purposefully facilitated. It is an example of what I mean by intentionally designing communities. Part strategy, part emotional labor. Always risky but extremely satisfying when it works.

It is also work that never ends.

Whose Knowledge

A good buddy – Anasuya – runs an awesome org called Whose Knowledge. A month or so ago they did a Book Sprint with the Book Sprints team and are now publishing the results:

New Resource! Our Stories, Our Knowledges

This collection of resources is written as a guide to support marginalized communities – including women, people of color, LGBTQI communities, indigenous peoples and others from the global South – in sharing their knowledge online. We hope to inspire the next generation of knowledge-makers to join in this work within their own communities. These resources are also intended to encourage allies who wish to help with this work. Whether you’re a member of a marginalized community, or an ally, these resources are here to assist you in centering knowledge from the margins.

Code Editor in Wax 2

Christos has been working on our new web-based word processor -Wax 2. It is based on the best-of-breed ProseMirror open source libs. A week or two ago, Christos integrated a code editor (CodeMirror) with it and sent me the following vid… looks great (see below). We also have a similar feature in Wax 1, but the integration isn’t as nice… check out the last bit of the video where Christos is ‘undoing’ items. It works seamlessly. In Wax 1 the code editor is a separate embedded object to the parent page so the ‘undo’ history does not integrate as nicely as it does here..

Paged.js workshops pretty popular!

Paged.js is the open source pagination engine we are developing to support CSS paged media specifications. The development has progressed pretty fast, since starting in February this year. So far, we know of one commercial product and several really interesting open source projects that have integrated it. Paged.js has also been used to make its first print book (the Editoria manual made in a Book Sprint last month). We don’t consider it near a 1.0 yet, so this is pretty impressive!

We are now moving into planning workshops to train people in how to use paged.js to make books (and other things) in the browser, and to extend paged.js with JavaScript to do new cool things.

We had one workshop in San Francisco last month. It was more of a paged.js core team meet really as it was a day after the Editoria community meeting and we didn’t much advertise it.

At the end of this month, there is a workshop (2 days) in Paris and one in Brussels (1 day). We have 46 people enlisted. It is close to our max. There might be a few seats left (it is a free workshop), so if you want to go, sign up here –

Demand seems pretty high as we have had several people that can’t make either date asking us to keep their names for the next workshop. We also have folks coming from the Netherlands and the US to attend. Pretty cool!

But stay tuned… we will have more workshops including NYC sometime in March and a few surprise other countries on the list… I’ll keep you posted!