Team communication

For anyone completely new to the project, it is most important to know how to get plugged in. There is a fairly extensive amount of communication flying around related to the project, and being able to find and track it may take some time.

Instant messaging and video conferencing

On a day-to-day level, the team meets in a Slack chatroom. Slack can be used in your internet browser or via an app; you will be invited to join the team by an admin.

The daily stand-up meeting is managed via the ‘#general’ channel, with notes in google docs that are edited throughout the day as people complete the tasks assigned to them.

Slightly less frequently, members of the team meet on Zoom for voice discussions. These meetings are organized as needed, but should provide feedback where appropriate (tickets, notes, etc).

Other IM tools

Slack is the only IM tool used by the entire OME team. Some team members do also use IRC (#ome on and may provide support via that channel but in general, all external requests for help are best submitted and dealt with via the forums so they are available for the whole community. In particular, the various Gitter channels associated with OME projects on GitHub are not routinely monitored and responded to.



The team is increasingly moving away from Trac and towards using Trello, especially for managing ‘story’-level items, documentation and testing.

The Trac server is available under and uses your LDAP account for authentication. Trac was used to record all tickets, but today is no longer actively used for new tasks and is mainly a record of older tasks.


Trello is an online organizational tool used to manage “cards” arranged in “lists” on various subject-themed “boards”. This is currently the team’s main internal planning tool for higher level development goals and for managing documentation, testing, and the maintenance of our continuous integration tools.


You can request access to the openmicroscopy boards as an external collaborator. Sign up for a free account and then get in touch with us to be added. We have now added a public OME organization to allow anyone to follow our development progress (see Public-facing workflow for more information).

Developer documentation

The developer documentation is maintained under version control, generated using Sphinx and hosted on the OME website.

Each section of the code base (OMERO, Bio-Formats) has a landing page that will direct you to all the developer documentation that you might need. For example, the Developer page for OMERO is here.

Jenkins: Continuous integration

Our Jenkins server is available here and also uses LDAP authentication. Jenkins provides a mechanism to run arbitrary tasks (“jobs”) on one or more platforms after particular events (time of day, git push, etc.) These jobs build all of the binaries released by the team, and also run automated testing.


Git and GitHub: Source code

Commits take place primarily on GitHub currently. To be aware of what is really going on, your best option is to become familiar with Git, GitHub, and the repositories of all the team members. Information on doing that is available in the Checking out the source code and Using Git.


Forums and mailing list

Feedback from the OME community happens primarily on the forum as well as GitHub.

You should be aware of and scan all threads on a fairly regular basis. The general rule is that requests from the community will be responded to by the next working day, where to the best of our ability, we keep the ‘working days’ and time zones of the community in mind.

Where possible, the task of monitoring feedback is spread across the team. Forum questions are listed at the morning stand-up meeting and can be checked off in the accompanying notes when dealt with to ensure nothing is ignored or forgotten.

Anyone on the team should feel free to speak up to answer questions, but do try to verify the correctness of answers, code samples, etc. before posting.

As much information about our activities and decision processes should be made public as possible. For many items, there is no reason to hide our process, but we do not go out of our way to make them public. For example, internally the team often uses OmniGraffle documents to illustrate concepts, but these are kept privately to prevent any confusion.

Internal servers

There are a number of servers and services inside of the University of Dundee system that are used by the entire team. You may not need access to all of them immediately, but it is good to know what is available in case you do.

  • (LDAP-based) is necessary for securely accessing some of the following resources (e.g. squig, jenkins)

  • is the shared, team-wide repository for data which can be mounted if you are on VPN or within the UoD system. It contains test data for various file formats.

  • The OME QA system is an in-house system for collecting feedback from users, including failing files, stack traces, etc. Like our community feedback, QA feedback should be turned into a ticket in a timely manner.

  • Home directory / data repository on necromancer (SSH-based)


For anyone who has been hired to work at the University of Dundee, you will be provided with a new start tasklist which itemizes all the things that need to be done to get you set up in RL (building access, a chair, etc.).

Google Docs

In addition to the services hosted in Dundee, the team also makes use of several Google resources due to the improved real-time collaboration that they provide. A single Google collection “OME Docs” is made available to all team members. Anything placed in the collection is automatically editable by everyone.

For example, the primary contact information for all team members is available in the DevContactList spreadsheet.

You can enable notifications on the spreadsheet so that you receive an email if any changes are made.


Weekly meetings are held online with all members of the team. Notes are taken collaboratively in a public Google doc in the “OME Docs > Notes > Tuesday meetings” collection. Anyone who missed the meeting is expected to review the notes and raise any issues during the next meeting.

Periodically, a technical presentation is held during the weekly meeting. This can be used to either introduce an external tool for suggested use by the team or as a peer review of in-progress work.

Mini group meetings can either be regularly scheduled (e.g. weekly) or on an as-needed basis. Notes from such meetings should be recorded in gdocs or on Trello as appropriate and if necessary matters arising should be covered in the weekly meeting for the rest of the team.