Show and Tell for Wax from Coko people Jure and Yannis. Using Jitsi open source video for the demo. Will be re-encoded to ogg vorbis video and posted to the Coko blog shortly. We used Youtube (boooo!) to archive this time around since we couldn’t quite get the jitsicon recording working… will get it right for next time.
I’m taking a holiday in Hawaii to surf and do nadda for a week. I hired a 9ft Walden Magic from Mikes Maui Beach House. Nice folks. Wind is up but I had a good day yesterday on some small waves.
In essence, eLife is building on top of PubSweet to build their new manuscript submission system. They will possibly re-use parts of the PubSweet components built for Collabra. That’s the beauty of the PubSweet ecosystem – you can reuse what you want, and build only the new stuff (significantly reducing the burden).
We are already collaborating with eLife and have been for some 4 weeks to refactor parts of PubSweet according to some excellent recommendations made by eLife and their dev partners YLD. They are all great people to work with.
Stay tuned, more interesting news to come!
At Coko we are currently pulling the Wax Editor apart to componentise it. This will make extending and customising it a whole lot easier. To follow the project see the repository here : https://gitlab.coko.foundation/editoria/wax-pubsweet
Recently, I have been involved in some discussions around what tools to choose for open communities. This came up with regard to the Open Source Alliance for Open Scholarship (links to the new website coming soon!).
One argument that always comes up with these kinds of discussions, and I have been involved in many, is that we should use platform X because ‘thats where the people are’. Because open source has lost in the platform game (but its not too late) this argument almost always points to a closed source platform eg. github, twitter, slack etc
‘Going where the people are’ feels intuitively like a good idea. You want your project to succeed, go where the people are. Hard to argue against that. But argue against that we must, and I’ve started to think a little about how to counter this position better because sometimes, when people get stuck on this argument, there is no budging them.
One thing I have experienced recently that has fed a counter argument is the growing community around Coko. We use Mattermost and Gitlab as our primary web spaces for community and collaboration. What I notice with our gitlab, for example, is that when you open it up in the browser it looks like Coko. It looks like a home for a variety of connected and interesting projects that all revolve around Coko’s mission to reshape publishing. It is my hope that this will grow to be even more true over time. If that proves to be the case, then this gitlab instance will be a home (possibly one of many) for a certain approach and certain kind of thinking about how to change publishing. And that there is incredibly valuable because it speaks to the need for your community tools to surface and reflect your communities activities and values.
That’s not so easy to do in github. Go to a github org space and it looks like every other github org space. It looks dull. It reflects the identity of github and not of your community. This doesn’t just come down to theming, but it comes down to more subtle nuances such as with gitlab (or similar open source solution), the space is committed only to the things your community is doing. Things that are not connected are not a click away. From a community members point of view its a space dedicated to them. In this day I believe this is increasingly more unusual, important, and appreciated.
Consequently, I use the argument that developing community identity is more important than ‘going where the people are’. Don’t create a space ‘where the people are’, create a space where your people can go.
Much is going on in the Coko world at the moment and a lot of news coming out soon about various collaborations. Much of the attention has been around xpub, the journal system we have been working on built on top of PubSweet.
PubSweet is, of course, a component based system so you can ‘roll your own’ journal or book platform from existing components. We are making a lot of components for both Editoria and xpub and publishing them for reuse with an open source (MIT) license.
Some of the components we are generating for xpub are coming out of the work we are doing with Collabra, the UCP Psychology Journal. Today the Managing Editor, Dan Morgan, and I met for another session working out the logic of the components and how they fit together.
We started by working through the flow from the perspectives of each of the major stakeholders – Managing Editor, Senior Editor, Handling Editor, Author, Reviewer. We worked out what they each needed to see on the dashboard and then went through their workflow and what they needed from each component.
We then took each of these small mappings and transferred them to larger pieces of paper. Drawing the interfaces in basic form.
Each of the diagrams are detailed below.
We had already worked out this structure. Today was about running through the logic from each actor’s point of view. Good news is, the logic held up and validated the architecture. Good news! So, what you see in these pics is more or less what we will build. It is a thin horizontal slice that covers the complete lifecycle of a manuscript going through the Collabra process. We’ll build it and test it, and then layer on additional functionality.
Next I’ll recreate these in digital graphics and add a page of bullet points for explanation. We will then meet with the Coko team and talk it through and start building! It’s a good way to design systems, way better than endless months gathering pages and pages of product requirements. It’s a lightweight and fun process. Software is a conversation after all!