Road Map for AiiDA

# Road Map for AiiDA ###### tags: `roadmap` ## The purpose of the roadmap The AiiDA roadmap should serve two purposes: 1. It communicates our goals and priorities to users and stakeholders. 2. It underpins building a clear and agreed plan for work on AiiDA within the team. The roadmap is effectively an exercise in prioritization. Roadmap reviews should be performed periodically (at least once per month), to ensure the roadmap reflects the current state of the AiiDA ecosystem, and its core goals. A critical balance in the roadmap, will be balancing the number of items versus capturing everything that we wish to achieve. The number of items should not be overwhelming, such that developers/users no longer maintain or interact with the roadmap. We should strive to understand, for example, when an issue should live only on a certain repository (such as `aiida-core`), when it should be "raised up" to a roadmap item, and perhaps when it should be "demoted back" to a repository only issue. TODO what is the relationship with AEPs and isssues ... ## Roadmap item specification The roadmap is comprised of items. A user roadmap item MUST describe an aspect of the AiiDA ecosystem that we wish to improve, in a manner that can be understood by non-technical users. The item SHOULD NOT include a concrete solution. A roadmap item "is the why not the how", it will link to one or more issues, AEPs and pull-requests, that will provide full or partial solutions to the item. The roadmap item will be closed, during roadmap reviews, when it is deemed fully resolved. Each item SHOULD be rankable, relative to other items. All items will be placed in a list of importance, which may be altered during roadmap reviews. Each item SHOULD be categorised as one of the following: - `defect`: Address an issue that is already causing failures within the AiiDA ecosystem. - `usability`: An improvement to the AiiDA ecosystem, that addresses either improving a current feature, or adding a new feature. - `future`: Addresses a change required to keep the AiiDA ecosystem future proof. For example, upgrading to a new version of a dependency. - `dev`: A change to the AiiDA ecosystem, that will aide development. For exampe, changes to deployment or testing infrastructures. Each item MUST be in one of the following states: - `proposed`: The item has been proposed but not yet processed - `rejected`: The item was rejected by the team - `active`: The item is active in the roadmap - `resolved`: The item was successfully resolved - `postponed`: The item was not rejected but is not currently part of the active items There MUST NOT be more that 20 `active` roadmap items at any time. ## Roadmap item structure Each item SHOULD have the following structure denoted below. The goal is for the writing process to have minimal overhead, and that the item is understandable as early as possible. ### Heading The top-level heading should be no longer than 50 characters, and provide a concise description of the item. It should be prepended with the item category, in the form: - `Defect: ` - `Usability: ` - `Future: ` - `Dev: ` From the title should be clear for users/stakeholders what the item addresses. ### Motivation Provide a brief description of what the current problem is and/or how it would improve the AiiDA ecosystem for users. The motivation may contain one or more use cases. ### Desired Outcome Provide a description that can be used to decide if the roadmap item has been resolved. ### Impact This section should comment on the impact of resolving the item. For example, how many users will it affect. ### Complexity This section should comment on the complexity of resolving the item, and make a rough estimate as to the amount of work/time it would take to reach the desired outcome. ### Background This section is optional. The section should describe details of previous thought and work done around solving the issue. For example, it could outline current workarounds to the problem, and why they are not ideal, and/or what solutions have been proposed previously (and why they were rejected). ### Progress This section should be continually updated, with links to ongoing work around the item. For example, open/closed issues, PRs and AEPs. It should provide information to help understand if the item is progressing and/or what is blocking its resolution. ## Resolution When an item is move to the `resolved` state, this section should be added, to explain how it was resolved and/or why it is considered resolved. ## Coding day tasks Each team member should take on at least one item from <https://github.com/orgs/aiidateam/projects/3> - Chris: - General overview of AiiDA capabilities on the docs - Refactoring out rabbitmq - Maximum recursion - Jusong: - Registry for computer/code configs - docker stack for AiiDA only image. - Giovanni: - Push/Pull mechanism - Francisco: - Improve profile backups - Marnik: - Task Farming (`aiida-hyperqueue`) - Controlling calcjob/workflow submission (`aiida-submission-controller`) - General improvements to usability (try to see if it can be deconstructed into one or more items) - Kristjan: - Something to do with the REST API? - Xing: - REST-API workflow management Any one else, add you name and pick an item! ## Feedback from team members - [CJS] Please put any feedback you have here, appended with your initials - [JS] Using fix format for the `impact` (Or `motivation`/`use case` section) section, such as "As a user, I need...", "As a developer, I want to have...".