Blog
Wax Show ‘n’ Tell
Hindawi Limited & Coko Announce Partnership
Coko & eLife partner on first PubSweet fueled journals submission & peer-review platform
Seeding a New Ecosystem: open infrastructure
Take Editoria for a spin
Making decisions in a small team and keeping it fun
A look at the future of journals with xpub
Editoria 1.1: Meet the Automagic Book Builder
A sneak peak at what’s next for PubSweet
Travel the long and winding road to PubSweet
Ink 1.0 is here!
Baby steps to user-centric open source development
Why we’re all in open source now
Getting Started with Coko
Editoria 1.0 preview
Preprints won’t just publish themselves: Why we need centralized services for preprints
INK – the file conversion engine
How we’re building the ‘mountain chalet’ of complex conversions
Sowing the seeds for change in scholarly publishing
Open Source Alliance for Open Science
Editoria Newsletter Out Now!
INK client upgrade
All About INK (explained with cake)
Track Changes (Request for Comments)
Book on Open Source Product Development Method Released!
Italics, Buenos Aires and Coko?
Editoria Update
Where we are with File Conversion
A Typescript for the Web
Coko Celebrates Year One
Editoria – Scholarly Monograph Platform
Adam Hyde’s Blog
Introducing Christos
Introducing Yannis
New PubSweet release
Attribution in Open Source Projects
Open Source for Open Access
Reimagining Preprints: a new generation of early sharing
Introducing Stencila and Nokome Bentley
Reimagining Publishing
Introducing Charlie
PubSweet 1.0 “Science Blogger” alpha 2
PubSweet 1.0 “Science Blogger” alpha, INK 1.0 alpha RELEASES!!!
Collaborative Product Development
Publishing for reproducibility: collaborative input and networked output
Substance Consortium
UCP & CDL Announcement
Release 0.2.0 is here!
CKF receives funding from the Gordon and Betty Moore Foundation to transform research communication
Technology Slows Down Science
[tech post] CSS and Drop Caps
Vote for the pubsweet logo!
Introducing Substance
Digging Collaboration and Cooperation: Code for a New Era
Coko 2015
PubSweet 0.1 Release
Coko Resources
Making science writing smarter
What I Have Learned About Building Community
Introducing the Tech Team
Knowledge and Communication
PKP and CKF Strategic Alliance
CKF Launches
September 11, 2017

Making decisions in a small team and keeping it fun

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 🙂