This article has been originally published on MELLODDY blog. Want to know more about MELLODDY? Visit www.melloddy.eu

The MELLODDY consortium brings together 17 partner organizations of different types, working towards a common goal, in multiple countries with different cultures. The project is fully remote, with various businesses and technicals skills brought in by the partners. How does one develop transversality to a project in this context? How to create a common way of working in such an innovative and new collaboration endeavor? That is what Substra Foundation is trying to contribute to...

Bringing in the tools

The first step was to agree on and to set up collaborative tools, understood and shared by all. 

It looks fairly simple, yet across 17 partners with different work habits, security constraints, fields of expertise, we were pretty happy to quickly settle on the following:

• Box: for shared and secure storage of documents, already in use during the elaboration of the project proposal, so that one was easy

• Monday.com: for collaborative task management

• GitLab: for code repositories

• Slack: for channel-based discussions

This set of tools enabled participants to start collaborating as soon as the project officially started.

Speaking with a common voice

Communication of the project’s scientific results and strategic impact is intrinsically linked to the overall objectives of the MELLODDY consortium.

With 17 partners of different cultures and sizes and such front-running project, communication can quickly become a mess if everyone communicates on their own and what they want. 

Therefore, the first step was to define a common strategy: what is the objective of the communication stream for MELLODDY? Which axes of communication do we find important? Helped by various partner communication representatives, validation processes were defined. They are robust enough to ensure that each partner can express themselves using agreed pre-approved material while also allowing new content to be developed when needed. Our strategic communication plan was finalized around the following main axes:

• To raise awareness of MELLOODY’s mission;

• To promote the benefits of collaboration;

• To amplify scientific dissemination and results.

As already hinted at, part of the communication plan also addressed the question of making content available to the different partners. They can use them to present the project at conferences and events for example. Other communication channels include the MELLODDY website, kept live throughout the project; our twitter and LinkedIn accounts, where topic-related news and events are shared; as well as our blog hosted on the website, where each partner can share its contribution and thoughts on the project. Likewise, our communication plan also considers the anticipated dissemination of MELLODDY results and scientific publications that support the work already being done.  

In brief, only 1 year into the project, the communication strategy continues to be deployed and improved. 

Assembling knowledge 

To support the technical platform and the project participants, it is necessary to provide comprehensive documentation. The documentation gathers and maintains an up-to-date description of the technical approach and the software stack of the project (key mechanisms, choices made, etc.); in a sense, the knowledge acquired during the project.

Elaborating such documentation can sometimes require efforts that seem secondary to the main objective of contributing to the creation of the solution. That is why it seemed natural to try to add as little work as possible by capitalizing on what already existed and would be produced whatsoever. 

As such, the technical documentation relies where possible on deliverables and documents created during the project by the different partners in our goal to reach MELLODDY's objectives. Duplicating content is to be avoided, following the Single Source of Truth principle. Original content is elaborated only to provide a more transversal overview of the project, the glue that relates existing content pieces together, and broader perspectives. In summary, MELLODDY's technical documentation is composed of:

• Core content pieces: the documents elaborated under the umbrella of the different work packages, whether official deliverables or specific reports and notes. They are stored securely on Box and referenced within;

• Transversal perspectives: articles providing a high-level, transversal overview of the different components of MELLODDY technical approaches and software stack;

• Processes and operations: articles providing descriptions of operations, monitoring and incident management processes for the operational phases (yearly execution runs but also the earlier test phase).

The “tool” or format that we would eventually use for this documentation had to consider that it would document not only software but also operational processes, machine learning choices, etc.? The objective of this documentation was to be useful to project participants, not to be archived somewhere as a proof of serious work. The familiarity and accessibility of a website, with an advanced navigation menu, search capabilities, and cross-referencing, sounded much better than any format of a standalone document.

We settled for the following:

• a version-controlled collection of .md files for our documentation articles (referencing the core content pieces mentioned above as files stored securely on Box);

• building it into a website with MkDocs, a reference static website generator particularly adapted to software documentation;

• serving the website with the GitLab Pages module of the project’s private GitLab instance.

Making it happen

A significant challenge is the definition of the operational processes for the yearly run, the period during which machine learning models will be trained and tested on all the private datasets of the partners.

Here again, on such a complex multi-party project the difficulty is finding the balance in favor of providing sufficient clarity rather than having intricate processes that would bring complexity and require too much effort for the different partners. 

To minimize manual operations, a first guiding principle was defined by the project's technical teams: everything-as-code. It implies that everything that can be, is scripted and version-controlled. Of course, as far as principles go, we endeavor to follow them through yet accept that some things need to be managed manually. These are, that what cannot be automated (in a distributed, privacy-preserving approach, each partner must privately manage its IT environment and initiate operations), interruptions and incidents, and monitoring during the operational phases.

To help orchestrate the manual interventions, several things are being set up and experimented with during the pre-yearly run test phase:

• for each key technical operation to be performed by the partners, technical cookbooks are being elaborated. These cookbooks are user guides that are as precise and as didactic as possible. As such, each partner participating in the run can strictly and uniformly apply what is indicated. This can go as far as the line of code to be typed in a given situation. 

• and, by defining major principles and macro-processes, we can leave more room for agility where it is useful and necessary. 

There are likely to be some oversights and questions that will arise during the run, which is inherent to any research project of this magnitude. But our goal is to provide a framework as complete as possible to limit bad surprises when everybody will be in it. 

Preparing the future

MELLODDY is an enthralling project, and it is just getting started. Soon we hope to start a new chapter answering the following questions: What is next? What are we doing in terms of sustainability for the platform? What happens after the project ends? These are exciting questions for a new and innovative way of collaborating in a “privacy-preserving” way between direct industrial competitors. Beyond R&D, could “coopetition” become a new standard?