|HQ: University of Victoria, Canada
Founded: 10 years ago
Products: JIRA and Confluence
Murray Leslie of NEPTUNE Canada
ROPOS – deep ocean science ROV
It never ceases to surprise Atlassian what our customers use our bug tracker and collaboration software to help them do. The use of both JIRA and Confluence by the ocean science project, NEPTUNE Canada, is no exception.
Based off Vancouver Island, NEPTUNE is the first regional-scale underwater ocean observatory that plugs directly into the internet, alleviating the need to rely on unpredictable ship cruises or satellite data. In essence, this gives people the opportunity to remotely surf the seafloor and for scientists from universities around the world to run deep-water experiments. The underwater network gathers live data from an expansive loop of many high-tech instruments which transmits data via high-speed fiber optic cables. The data is sent to and archived in an innovative system at the project’s headquarters. NEPTUNE Canada has been built to provide continuous observations of the Northeastern Pacific seafloor for 25 years.
I had the pleasure of speaking with Murray Leslie, Software Quality Control, of NEPTUNE to learn how they have used our software development tools to help them achieve and maintain their goals. Having never heard of such an exciting project, Atlassian was pleased to find out that in 2008, the NEPTUNE project was selected as one of the five most significant science projects of the year from The Economist. Both JIRA and Confluence have aided NEPTUNE’s efforts to achieve this awesome accolade.
Tell me a little about your work and company.
NEPTUNE Canada is based out of the University of Victoria. We are a regional cable observatory off the west coast of Vancouver Island. We are the largest observatory of this kind in the world, and are funded from Oceans Network Canada. The Ocean Observatories Initiative (OOI), based in Washington, DC, has recently been funded and they are looking to build out their network in the next 4 or 5 years. We hope to be interoperable with the OOI in the future. The OOI’s wiki is very open and I realized they were also using JIRA and Confluence like us.
The OOI has several projects globally to install and maintain ocean observation systems in the Southern and Western Atlantic and the Northeastern Pacific. NEPTUNE Canada is on the west coast of Vancouver Island and will interoperate with another OOI project which will extend from Washington state down through Oregon. So eventually, we will potentially be able to monitor the migration of whales all the way from California to Alaska.
I’ve been here 4 years and am one of three people on the software and quality engineering team.
How is JIRA used at NEPTUNE?
We moved from Bugzilla to JIRA about 3 years ago. We wanted something that would scale and handle different workflows so that we could deal with non-software related issue tracking as well as simple bug tracking. That was one of the big selling features for JIRA. We didn’t evaluate any other products; one of our lead developers here was at another company that was using JIRA, and he basically sold us on it.
JIRA has multiple roles, it’s primary purpose is for doing bug tracking, feature requests, requirements management and issue tracking. We also have different projects for instrumentation, and for scientists who want to visualize their data or change the settings on an instrument. The Directors of Science of Engineering use it in a totally different way; they use it essentially to track action items from meetings and follow up items. It’s important for them to maintain transparency and actionable items.
We have 13 projects and 103 users. There are 30 employees, but a large community of scientists and researchers use it. We want to integrate JIRA and Confluence with our in-house, Java-based, web application: Database Management and Archiving System (DMAS). That will allow people to do social networking activities without us having to reinvent the wheel. For example, a scientist will have a workspace that has JIRA tickets relating to his project or instruments, and with a single click (with single sign-on), gain access of DMAS to access live data. So, when it is all put together, it should be a seamless experience, not just day-to-day observations of their instruments, but eventually collaborative workshops or collaboratively publishing scientific papers.
Do you follow an agile development process?
We are using more of an agile development process so that we are developing user stories in our wiki software and then trying to break those down into individual tickets so that we can do rapid iteration. We try to do 2 releases a month. We do not currently use GreenHopper. We try to deliver high value functionality early on. That’s where JIRA and Confluence have been very helpful for us – to document the requirements in the wiki, break it down into a JIRA workflow, create individual tickets, and assign those tickets to programmers. From the instrumentation/science end, that has also been a very good way for us to maintain transparent communication with the outside users and not get lost in email hell. ‘You didn’t get that email’ or ‘who has the most current version of that paper?’ We are trying to get away from that by pointing people to a repository on either Confluence or DMAS.
Are you using any plugins or other integrations with JIRA?
Right now we have an LDAP directory connected with single sign-on to Confluence and DMAS. We use Jasig CAS, a Java-based single sign-on tool that works well with Confluence. Integration with JIRA has some legacy issues with LDAP, but we want to have JIRA users also have access to any of those applications or others that we bring on.
What advice would you give another scientific entity thinking of using JIRA?
I’d tell them to consider single sign-on early on. There has been a lot of planning to get ours up and running. Also, JIRA and Confluence are a natural pair; they work really well together.
The idea of workflows with JIRA is something that really differentiates it from other defect tracking systems. That’s the big deal. The ease of use; most people only need about a 10min tutorial to get up and running on it. From an admin perspective, I find it really easy to change permissions, or create new groups, new projects and components. To me, the mark of success for software is you don’t have to read the manual, and you guys have done a great job with JIRA.
How and why did you start to use Confluence?
For an internal wiki, we are still using MediaWiki. However, people outside our domain could not access it without a separate VPN. When we started to expand and produce our website, we initially went with a content management system called dotCMS. It supposedly had collaboration tools including a wiki, but it was inadequate – as a polite way to say it. We started shopping around looking for something else that would allow user-generated content to be created easily. We settled on Confluence for our public knowledge management tool because of our experience with JIRA.
What is the main use of Confluence?
It’s our primary means of user-contributed content. We have project spaces for individual researchers – we call it Ocean’s 2.0 which is social networking for ocean science. It’s the idea of moving away from just presenting content and allowing collaboration. People can collaborate on projects privately without others knowing, but we are encouraging projects to be open, possibly an outreach of some kind – maybe just like a Facebook wall. We want research to be made public as soon as possible. Some content is generated by our web person, and then other content by the researches in the field. We are hoping to attract contributions of other user groups like teachers, political researchers, and people who are interested in policy or decisions based on climate change and ocean geography. In the meantime, current researchers can get as detailed as they want and keep their permissions as they wish or open it for others to collaborate.
The use case that I give people that they seem to get is ‘have you ever been on an email thread that goes on and on and on and people send versions of documents back and forth, and after about the 7th iteration, nobody knows who has done what to the document?’ That’s the use case that everybody gets, so if we just roll ‘wiki-style’ and push our documents up to the data service, then all of the versioning can be looked after for you.
There are several hundred users in Confluence. There are about 6K users on the DMAS site, but only a few hundred of those have a Confluence account. We are trying to limit access to grad students, interested parties and primary researchers.
The collaboration tools in our old dotCMS tool just weren’t up to what we were expecting. So, the move to Confluence was not adding any new functionality, but the ability to easily create new pages, to easily create new content, to have version control on documents and to link back to JIRA & DMAS projects has been in the works for over a year now.
What advice would you give another research institute considering Confluence?
Confluence can be skinned any way you like. You can skin it so you don’t even know you are on a wiki. My advice is to have a developer who knows style sheets really well.
I think most people are aware of the value of web 2.0 technology for socially interactive content, and we are just trying to bring that to a science-oriented website. People want simple tools to look at their data, interact with other researchers and collaborate in an intuitive, natural way. Document management, shared workspaces, and use of third-party tools such as Confluence, JIRA, and Skype have assisted our growth into the social web. This is the right way to go and I’m hoping it pays off in the near future.