What a Collaborative Community Looks Like

Adam Hyde Jul 30, 2018

Those organisations building platforms on top of PubSweet gather together every 3-4 months for our PubSweet Community Meeting. It started off as Coko, Hindawi and eLife but now we are also joined by the wonderful folks from the European Bioinformatics Institute.

The events usually go for 2 days and we sometimes have a additional 3rd day for those that have specific items they want to address that could not be covered in the previous 2 days.

Each meeting we get an update from Jure Triglav (lead dev for PubSweet) followed by updates from each project.

We then collaboratively decide what topics we want to cover over the 2 days. This meet was particularly exciting for updates as each organisation had made significant progress on their platforms. Consequently we did a ‘demo-athon’ – breaking out four tables and setting up small groups to rotate around each project every 20-30 minutes. This gave each project the opportunity to explain in depth what they are doing to the entire group as well as enabling anyone to ask questions at any detail to each project without fear they would be side tracking the entire group. It worked extremely well.

Then we got onto the topics of the meeting – the shared data model, and best practices for sharing components.

We largely addressed these issues on day two (there were some smaller topics we dived into on the afternoon of day one). The data model group gathered around a table with Jure facilitating. It was essentially a collaborative data model design session – every project was present and had their ideas and opinions to share. There were some sound high-level principles that were agreed to first (some of the following is slightly technical):

  • These models do not use Collections and Fragments, instead they are standalone models in separate tables.
  • JATS is used as a vocabulary and a source of data types, wherever appropriate.
  • All models have ‘created’ and ‘updated’ dates (with the exception of AuditLog, which does not have an updated date)
  • All models have an ‘id’ UUID
  • Dates are ISO-8601 strings, as PostgreSQL recommends this as date input, JATS allows it, and GraphQL can handle it.

From this position it was a matter of iterating through each major table in the data model and agreeing to the structure of each and (where appropriate) how each item would map to JATS.


The good news is that we worked through the entire model (as much as we presently need) and had consensus on each! You can see the results of this session in the Coko repo for the shared data model here – https://gitlab.coko.foundation/xpub/shared-data-model

It was awesome to see collaboration on this wide issue successfully achieving consensus on an issue that can at times be quite tricky. In just one day!

The other group focused on how to share components across the projects. The outcomes of this group was also documented and can be seen here – https://gitlab.coko.foundation/pubsweet/pubsweet/issues/408

The group documented many of the existing shared components but also worked out some simple protocols for making the available shared components more visible as well as best practices for building shareable components. A working group will now also take this forward and implement an integrated, shared, styleguide and address other issues identified in the document linked above.

We also had t-shirts and books to give away.

It was a great meeting and we are looking forward to the next one towards the end of the year, possible with some exciting new projects joining the community!

Many thanks to the good folks at EBI for hosting this event.


About the Author

Adam Hyde


Adam is the CoFounder of Coko.