As a community-led organization, we welcome feedback 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 feedback 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.
We incorporate suggestions and plan our development cycles using the following process:
- Plan and prioritize. User suggestions are added to ORCID’s public User Feedback Trello Board and member and integrators suggestions are added to the Member and Integrators Feedback Trello Board. There we review the suggestions alongside our existing workload and prioritized them. We consider the feedback 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?
If we receive a suggestion that we know we won’t have the resources to work on within the next six to nine months, it is added to our list of ideas for longer-term consideration and are addressed as time permits or if additional request for the feature come in.
- 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 feedback Trello boards 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 welcome suggestions on how to improve the ORCID registry. Here’s how you can share your suggestions for ORCID enhancements and new features:
- You can tweet us, using the hashtag #ORCIDfeedback,
- Share your ideas in meetings,
- Participate in Working Groups, or
- Tell us in person at events!
In addition, ORCID is an open-source project and we welcome contributions to our source code as well as all our repositories.