This year, metadata development is one of our key priorities and we’re making a start with the release of version 5.4.0 of our input schema with some long-awaited changes. This is the first in what will be a series of metadata schema updates.
What is in this update?
Publication typing for citations
This is fairly simple; we’ve added a ‘type’ attribute to the citations members supply. This means you can identify a journal article citation as a journal article, but more importantly, you can identify a dataset, software, blog post, or other citation that may not have an identifier assigned to it. This makes it easier for the many thousands of metadata users to connect these citations to identifiers. We know many publishers, particularly journal publishers, do collect this information already and will consider making this change to deposit citation types with their records.
Every year we release metadata for the full corpus of records registered with us, which can be downloaded for free in a single compressed file. This is one way in which we fulfil our mission to make metadata freely and widely available. By including the metadata of over 165 million research outputs from over 20,000 members worldwide and making them available in a standard format, we streamline access to metadata about scholarly objects such as journal articles, books, conference papers, preprints, research grants, standards, datasets, reports, blogs, and more.
Today, we’re delighted to let you know that Crossref members can now use ROR IDs to identify funders in any place where you currently use Funder IDs in your metadata. Funder IDs remain available, but this change allows publishers, service providers, and funders to streamline workflows and introduce efficiencies by using a single open identifier for both researcher affiliations and funding organizations.
As you probably know, the Research Organization Registry (ROR) is a global, community-led, carefully curated registry of open persistent identifiers for research organisations, including funding organisations. It’s a joint initiative led by the California Digital Library, Datacite and Crossref launched in 2019 that fulfills the long-standing need for an open organisation identifier.
We began our Global Equitable Membership (GEM) Program to provide greater membership equitability and accessibility to organizations in the world’s least economically advantaged countries. Eligibility for the program is based on a member’s country; our list of countries is predominantly based on the International Development Association (IDA). Eligible members pay no membership or content registration fees. The list undergoes periodic reviews, as countries may be added or removed over time as economic situations change.
Open company contributes changes back to another open company
Now have a method for getting work done much easier
Hurrah!
I’m Joel, a Senior Site Reliability Engineer here at Crossref. I have a long background in open source, software development, and solving unique problems. One of my earliest computer influences was my father. He wrote software to support scientists in search of things like the top quark, the most massive of all observed elementary particles.
One day my father came home with over 40 floppy disks, excited to have this cool, free operating system called Linux. Together we installed Linux and ended up with a fully functional computer. Learning and using Linux opened up an entirely new world to me of amazing open-source software that I could use freely. As I enjoyed all this new software now available to me, I tried to fix any bugs or problems I’d encounter and report solutions for them to the software developers. It felt great to be able to contribute back so others could benefit.
Software teams tend to manage their workflow by writing issues, reviewing them to make sure they make sense and have an achievable goal, estimate how much time it will take to complete, and finally––the crucial step––putting the issues in the order in which they should be completed. To manage my work, I’ve always used Jira––a product designed to help teams of all types prioritize work––and for the first time in over a decade, I find myself not using it in my work.
Product development tracking with GitLab
The Crossref team took the decision a few years ago to move all our development and product tracking work via GitLab––a commercial open-source product anyone can use to help keep track of software throughout the development life cycle––with an open-by-default policy. Work is tracked using the issues feature of Gitlab. GitLab will host it, so you don’t have worry about maintenance and backups. One major drawback I discovered with GitLab, is a lack of maturity when it comes to doing light project management work.
This is where the trouble begins with GitLab.
In the board view of your issues, you can transition your issues from waiting, to in progress, from in progress to done. The problem with this view is its width-restricted, and things like tags on issues, which are used to help categorize, take up valuable vertical space. With enough tags and a long enough subject line, you can only see five issues at a time on a MacBook Pro monitor, for example.
In the list view of your issues, you get a clean compact view; the perfect view to order issues. However there’s one major flaw, it’s paginated. (You know when you’re shopping and they make you click to see another page of goods? Yes, like that.) The problem with GitLab’s implementation is you can drag and drop issues on a given page, but there is no way to move the issues to another page in the list of results. Additionally, all newly-created issues are added to the end of the list.
The solution
I went about finding a solution by visiting GitLab’s own public issue page and found that requests requiring user interface (UI) changes would languish; in some cases, they would go years without getting approval. Instead of putting in all the work to open an issue with them, only to have it be discarded or ignored, I decided to look for another way.
GitLab has an API, what more could I need? I discovered I could log in and get a list of all the issues, by project, and by group. “This is perfect!”, I thought. I can write my own UI around it. It took three evenings writing a UI that was satisfactory to me. When I started writing javascript to interact with the UI, I learned that the ’re-ordering of issues’ didn’t actually have an API. Further investigation lead me to the issue tracker where I found an issue by a GitLab employee asking for the same functionality––the ability to re-order issues.
While in a chatroom for GitLab development, I was genuinely surprised by my experience. There was quick attentive help on locating the file I would need to implement the change, they set up a development environment, and even helped submit tests for my code while I worked on updating documentation and writing a changelog entry. It felt like GitLab must’ve designated an employee to work with the community on submitting improvements. In no time, the API for re-ordering was implemented. After the scheduled monthly release of GitLab rolled out with my new API, I was able to easily re-order issues.
GitLab’s response when help was needed along the way was impressive. Now there is a much easier method for getting work done that everyone can use. It’s rewarding when you can contribute back to the community for all to benefit.
Is GitLab as polished as Jira? No. Did they embrace me making changes by being open from the start and providing help along the way? Yes. Do I see Jira shifting its culture to match? Unlikely.
By emulating GitLab, an open organization like Crossref has a shot at encouraging community development.
