At Coko we’re a small but very productive team. On the technical side, there are a lot of decisions to make that can affect everyone. These range from the small, such as what styles to apply to a radio button, to the large, more along the lines of “which software do we use to manage components?”
As much as possible, we aim to keep these discussions informal and pragmatic. This lessens the overhead on the team (no lengthy meetings!) and also makes the process a whole lot more flexible and enjoyable. We don’t make long proposals often and we keep the decision process discussion based. As Charlie Ablett (the lead developer for INK) has said, “software is a conversation.” That’s very true.
For example, we recently made the decision to start breaking pubsweet-components (e.g. a Journal Dashboard) down into smaller components. Alf Eaton brought up the issue of how to manage these smaller components so we could view them as a library in a kind of ‘live style guide.’ It was a good, and timely, question. He had already tried out a few options, namely Storybook and Styleguidist, and so we put this up for general discussion. It was important to do so since we want to establish conventions, a common approach, for developing all parts of our code and so the question needed to be floated to the team. Two days later we met for a quick 25-minute meeting, in which we covered four questions (three ear marked for later) and made a decision on the style guide. Short and sweet. In part, that was because Alf had already tried out the main contenders and had clear arguments as to why Styleguidist would work well. We all gave the thumbs up and the decision was made.
We also try out things occasionally and are not afraid of ‘spikes’ (a fixed time period experiment/trial of approaches). When we went down the path of working out user interfaces for track changes in Editoria, Christos Kokosias volunteered to prototype several approaches. We then blogged about this for input and demonstrated working code for three different approaches to folks at the University of California Press. Feedback came in and we had a clear winner. We’ve also tried spikes on other items, for example, we tried some prototype interfaces for xpub using material-ui. It was an interesting experiment but ultimately the team found material-ui to be too constraining, we prefer to have maximum control over how our user interfaces look and work. So while it was interesting, in the end it validated the approach we’ve already taken.
As you can see, these processes help us establish conventions for how we work and by keeping the decision making process lightweight and discussion-based we can quickly work out if the current ways still make sense or if we want to go in a different direction without getting lost in endless process.
Some decisions, however, warrant a little more consideration. This is especially true now that we are starting to work with a variety of publishers that are building on top of PubSweet, Editoria, xpub, etc. It’s been interesting since it represents a slight bend in the road for us. Until recently, we’ve been a small team with informal but tight communication. However, Coko is now quickly turning into a community and our decisions affect more people and consequently more people need to be involved in those decisions. Community, after all, is not a one-way street “from us to you” but a living, functioning organism. We’re all in it together.
To respect that growth, we’re developing processes that work for a larger group. Our first concerted attempt was the PubSweet 2.0 meeting in San Francisco a few weeks ago. We invited community members to be part of the process to decide what made it into the 2.0 release. To get there, Jure Triglav, PubSweet’s lead developer, wrote an overview document of PubSweet 1.0 that was made open for discussion to anyone interested in what might go into PubSweet 2.0. Being the closest person to the core code, he had some ideas of what this might look like and added these to the document, which was distributed to community partners 10 days before the event and published to the PubSweet repo for anyone to read and comment on. The document and resulting comments became the focus of the two-day meeting. After much discussion, we came out with unanimous community agreement not only about what should go into PubSweet 2.0, but what changes needed to be made to the road map to make it happen. While it sounds almost too kumbayah to be true, the result was multiple publishers working together and agreeing on a common technology that they will build together!
This initial community decision making meeting worked extremely well. Of course, we’ll need to develop other processes as we go along and we’ll have to try not to get too far ahead of ourselves. Ideally, we’ll develop new ways of managing these kinds of decisions from the ground up — even the process of making processes should be lightweight 🙂