As a community-led organization, we welcome ideas from our members and users about new features and functionality for the ORCID Registry, APIs, and websites. This article explains what a feature is, the process we follow for evaluating and adding them, and how you can share your own ideas for new features.
IN THIS ARTICLE...
A bug report is a request to fix a problem with existing functionality, while a feature request relates to new functionality. Some reports are very clearly for bugs, for example, when a users is unable to log in to the Registry, or the API is unresponsive. Other reports are very clearly features, such as a request to add a new section to the record.
However, some requests fall in between these two categories, for example, wanting to change the way something works. This could be considered a bug if the current functionality is causing problems for users, or it could be considered a feature request if it is defining an improved way of working. In these cases we have to make a judgement call.
For more information about bugs, see: How are bugs fixed?
From idea to new feature
The ORCID Registry has, from its start, been imagined, defined, and developed by members of the research community. It has grown into a mature, stable, and well-used cornerstone of research infrastructure, and researchers and organizations alike depend on this stability. Our rolling program of improvements, originating from many sources is fueled by our community’s requirements.
Researchers, research organizations, infrastructure partners, publishers, repositories, funders, and ORCID staff all generate requests, which have to be managed collectively. We have limited resources and cannot implement everything, and nor should we. All requests are, therefore, considered in the context of our capacity to meet both them and the needs of our community as a whole.
ORCID’s public Product Roadmap Trello Board contains all the requirements we have committed to implementing at some point. We clearly define who the requirement is for, what it will do, the benefits it will provide, the cross-organization impact, and the effort required before committing to working on something - and we do it in a way that makes sense to everyone involved, including the initial requestor. Viewed together this information enables us to better prioritize our development efforts, report on our progress, announce new features, and ensure we continue to provide a useful and relevant service.
We plan our development cycles using the following process:
- Plan and prioritize. Each week we review the features we are currently planning alongside our existing workload and any newly suggested ideas, and prioritized them. We consider the ideas and features to incorporate and prioritize them for inclusion in based on the following factors:
- How closely does the feature fit ORCID's vision and mission?
- How well does it align with ORCID's principles?
- How important is the feature to enabling other connections, integrations, and collaborations?
- How important is the feature to the user community?
- Is this a feature that ORCID should build, or would it be more effective, efficient or better enabled if we encourage someone else to develop the feature?
- How many people will benefit from the feature?
Occasionally we receive a low-priority suggestion that we know we won’t have the resources to work on within the next six to nine months. These are added to our list of ideas for longer-term consideration.
- Specify. Once a feature is selected for inclusion and prioritized, we create a more detailed specification, incorporating feedback from the original requestor, relevant working groups, and the Technical team -- as well as our Strategy and Engagement teams -- to ensure we are understand and can meet the requirements. This may be a longer or shorter process, depending on the feature being requested. In some cases we ask for, while at other times t we specify a feature quickly ourselves, so that we can get feedback and input once others have a chance to try it out.
- Estimate. Once a specification has been approved, the ORCID Technical team estimates how long it will take to build. The estimation process is done at a high level, and can be iterative. If it is likely to take a long time to build the feature, we may break it up into smaller parts that we can work on one at a time.
- Schedule. Taking into account the time it may take to build a feature, the number of other features and bug fixes expected, and input from the community (including working groups, where applicable), the ORCID Product Director moves items to the Product Roadmap Trello Board for tracking. The Product and Technical teams together select items for development and these are then moved to the current development board.
- Build and Test. During the development cycle for each release, features are built, bugs are fixed, and everything is tested.
- Release. We periodically release fixes and new features that have been completed to production. If it is important to release quickly, we will do so but, if there isn't anything pressing, we may wait and release more new features at once. We do not use scheduled release dates, but our process means that we typically make mini-releases several times per month.
- Communicate. We update the iDeas forum with progress on the timing and release of new features. Development progress also can be followed by watching the Product Roadmap and Current Development Trello Board. Any significant new features are also announced on the ORCID blog and promoted on social media (Twitter and LinkedIn), as well as in our monthly member newsletter and the ORCID API User Group.
How can I get involved?
We have developed our ORCID iDeas Forum for you to provide feedback, new feature ideas, and improvement suggestions for consideration.
There’s also a handy iDeas archive, which includes all existing iDeas sorted by date, so you can see if someone has already suggested an idea and, if so, check its status.
Once we have prioritized a suggestion made in the iDeas Forum, we update its status as follows:
- COMPLETED: A feature that has already been added to the Registry or APIs
- PLANNED: A features that has been prioritized, specified, and estimated - you can follow its progress on our product roadmap, as outlined above
- NOT PLANNED: A proposed feature that doesn’t fit our mission, or isn’t feasible for us to develop
- THANKS FOR YOUR SUGGESTION: Helpful feedback and suggestions that are not associated with an iDea