The support.orcid.org website is on a UserVoice platform that has a different privacy policy from our other sites. You may view the details at http://support.orcid.org/tos
X

How are new features decided?

The ORCID Registry from its start has been imagined, defined, and developed by members of the research community. It is with this basic tenet that we have developed our ORCID iDeas Forum for you to provide feedback, new feature ideas, and improvement suggestions for consideration.

Since our launch, we're received hundreds of ideas, annotated with comments and votes, through the Forum. We are excited and energized by the enthusiasm of the community. Now, the challenge is to review and prioritize your ideas. We would like to share our process with you and invite you to participate!

IN THIS ARTICLE...

The process - from idea to feature

Who is involved?

Many of the enhancements on the ORCID development roadmap are from community suggestions received through the ORCID iDeas Forum. We work with the community through the ORCID Technical Steering Group to review your suggestions. Occasionally, a topic will be big enough that we will engage a Technical Working Group to help understand the area and to solicit broader input from the ORCID Technical Community.

Learn how you can get involved.

The process: bug or enhancement?

The first thing we check if it is something that isn't working as specified (a bug), or new functionality or difference in the behavior of existing functionality (an enhancement). Bugs and enhancements take slightly different journeys through our process so we'll describe them separately.

From reported bug to fixed functionality

While we spend a lot of time testing features to be released on the Registry, from time to time ORCID Registry and API users find things that we didn't. Once a bug has come to our attention, the following process is used:

  1. Get Info: We gather as much information as possible to understand when the problem happens. Sometimes this means that we do additional testing, and sometimes we will ask for more information from the person who reported the problem.

  2. Prioritize: Once we understand the problem and when it is likely to happen, we prioritize it. Once prioritized, it is added to our Bugs Trello Board for tracking. The considerations that we use for prioritizing a bug include:
    1. Does the problem represent a security concern for the Registry?
    2. Does the problem prevent someone from registering for an ORCID iD? (our top priority)
    3. How many people are affected by the bug? (the more people, the higher the priority)
    4. Does the problem affect the Registry or API performance or quality? (the more so, the higher the priority)
    5. Does the problem make the Registry confusing or difficult to use?
    6. Does the problem make the Registry less attractive?

  3. Schedule: We allow some time with each release to address bugs. The number of bugs addressed with each release depends on how much time it takes us to diagnose and fix the problems, compared to the amount of time that we have in each development cycle to work on bugs. The higher-priority bugs get addressed first; sometimes lower priority bugs will need to wait for several release cycles. If there are many very high priority bugs, we will sometimes delay new functionality to address these issues first. Bugs that have been scheduled are moved to our Current Development Trello Board for tracking. Critical bugs will be patched as soon as they are fixed, outside of the typical release cycle.

  4. Communicate: Once we have scheduled something to be fixed, we update those who let us know about the problem. If the original communication came to us in the form of a support request, we respond directly to this request via email. Alternatively, if we learn about the problem via the ORCID iDeas Forum, we update the status and include comments directly to the idea page. Anyone who has voted for the idea or left a comment (and has included their email) will receive an update via email. We also send an update when the fix is available for your use.

From idea to new feature

For launch, we focused on providing basic registration functionality and integration with Launch Partner processes. We have a list of ideas for enhancements to the Registry. And, we have received many great ideas from the user community. We plan monthly development cycles with the Technical Steering Group and Working Groups using the following process:

  1. Prioritize: Each month we review the new features that we planned for the month along with any newly suggested ideas. We consider the ideas and features to incorporate and prioritize them for inclusion in future releases. Occasionally we will receive a suggestion that we feel is a low enough priority compared to others that we have a very low level of confidence that we will have the resources to include it within the next 6-9 months. In these situations we will postpone the idea for now and put it on our list of ideas for longer-term consideration. Ideas and features are prioritized based on the following factors:
    1. How closely does the feature fit ORCID's vision and mission?
    2. How closely does the feature fit ORCID's principles?
    3. How important is the feature to enabling other connections, integrations, and collaborations?
    4. How important is the feature to the user community?
    5. 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?
    6. How many people will be affected by the feature?

  2. Specify: Once a feature is selected for inclusion and prioritized, it is added to our Development Planning Trello Board for tracking, and a specification is written for it by the ORCID technical team with input from the steering and working groups and the initiators of the idea. The length of time spent on a specification can vary depending on the idea. In some cases we look for a lot of community involvement in creating a specification, though sometimes we specify a feature quickly so that we can get feedback and input once others have a chance to try it out.

  3. Estimate: Once a specification has been written, it is provided to the ORCID development team to estimate how long it will take to build. The estimation process is done at a high level, and is sometimes an iterative one. If it appears that it will take a long time to build something, we will break up the feature into parts and work on a piece at a time.

  4. Schedule: Given the likely time it will take to build a feature, the number of items that may need to be fixed or have already been scheduled, and input from the community and steering and working groups, the ORCID Technical Director will move items to the "Next Up" list of the Current Development Trello Board for tracking. The development team selects items for development from the Next Up list as current items are completed.

  5. Build & Test: During the development cycle features are built, bugs are fixed, and everything is tested. 

  6. ReleaseWe periodically will release fixes and new features that have been completed to production. The timing of these releases are dependent on what has been completed. If it is important to release quickly, we will. If there isn't anything pressing, we may wait a couple of days to provide you with more new features at once. We do not use scheduled release dates, though our process enables us to make mini-releases several times per month. 

  7. Communicate: We will be keeping the iDeas forum up-to-date with progress on the timing and release of new features. Development progress also can be followed by watching the Current Development Trello Board.

iDea status - finding out what is coming

There are two ways to stay informed about what we are developing: the Current Development Trello Board, and the ORCID iDeas Forum.

Once we have prioritized something that was suggested in the iDeas Forum, we will update its status:

  • COMPLETED - The features that we already have added to the Registry or APIs

  • STARTED -  Items that are actively in development. These items usually can also be found on the Current Development Trello Board.

  • PLANNED - Items that have been scheduled, but are not yet in active development. Often these items require specification, or are waiting for an opening in the development workflow. These items usually can be found on the Development Planning Trello Board.

  • UNDER REVIEW - These items have been considered, though have not yet been scheduled. Often these items can be seen on the site or APIs within the next 9 months.

  • PARTNERSHIP - These items are usually things that we can not implement without first establishing a partnership with another organization. We use the information in these ideas to inform the partnerships we pursue.

  • HACKATHON - We feel that the items in this category are great candidates for community coding challenges during one of our upcoming hackathons.

  • POSTPONED - These items may or may not be a part of the Registry some day, though not likely in the next 6-9 months. They are reviewed periodically to see if their status should change.

  • DECLINED - There are some great ideas that just don't fit our mission, or are infeasible for us to tackle. These items will be assigned a status of Declined.

Feedback and Knowledge Base