The ORCID Registry from its start has been imagined, defined, and developed by members of our community. That is why we developed the ORCID iDeas Forum for you to provide feedback, new feature ideas, bug reports, and improvement suggestions for consideration. We are also committed to an open development process where you can keep track of what we are working on; learn how new features are decided. We strongly encourage anyone who’s interested in using or contributing to the Registry to join the ORCID API Users Group.
-
Check our Trello boards to see what we’re working on
We track and share our development plans using Trello. Follow what we’re working on (Current Development), what bugs have been reported (Bugs), and our roadmap for the year (annual roadmaps).
-
Feature requests should be made in the iDeas Forum
Search the iDeas Forum to see if your idea has already been suggested. If it has, you can vote and comment to show your support. If not, you can add a new idea.
-
Bug reports should be made in the iDeas Forum or directly to the ORCID team
Report the bug to our support team for investigation; once confirmed, we add it to the Bugs board to be addressed. You can report the bug by posting in the iDeas Forum or by submitting a ticket via our webform.
-
Registry translations should be made in Transifex
We use Transifex to manage the translation and review of ORCID localizations. Join the Translation Team to contribute. See Getting Started as a Translator to get started on Transifex.
The ORCID Team is always excited to get contributions to improve the Registry by enhancing features or fixing a bug. Check out our pointers on contributing to the ORCID Github below:
-
Understand the basics
Not sure what a pull request is, or how to submit one? Take a look at GitHub's excellent Collaborating Documentation first.
-
Discuss non-trivial contribution ideas with committers
If you're considering anything more than correcting a typo or fixing a minor bug, please discuss it on the ORCID API Users Group before submitting a pull request.
-
Submit JUnit test cases for all behavior changes
Search the codebase to find related unit tests and add additional @Test methods within.
-
Run all tests prior to submission
Make sure that all tests pass prior to submitting your pull request. See the DEVSETUP.md Testing
-
Squash commits
Use
git rebase --interactive
,git add --patch
and other tools to "squash" multiple commits into atomic changes. -
Also Make it fun :-)