---
# System prepended metadata

title: Team responsibilities
tags: [design, roadmap]

---

# Team responsibilities

[TOC]

Check together with [team-compass](https://github.com/aiidateam/team-compass)

 
## Responsibilities
1. Engine: Jason (main), Marnik, Ali, Alexander
2. Storage: Edan (main), Marnik, Julian, Kristjan (maybe)
  2.1 Data types: Miki (main), Julian
  2.2 Provenance Graph: Kristjan (main), Xing
  2.3 Caching: TODO
  2.4 disk-objectstore: TODO
3. verdi CLI: Alexander (main), Marnik, Miki
4. Scheduler&Transport: Ali (main), Alexander
5. REST-API: Alexander (main), Edan, Marnik, Kristjan, Jason
6. DevOps: Jason (main), Alexander, Marnik
7. Plugin System: Julian (main), Marnik, Alexander
8. Discourse & Issues: Marnik (main - rotation), Everyone
9. Dependencies: Alexander (main), Jason, Ali
10. Website: Edan (main), Julian
11. AiiDA-Workgraph: Xing (main), Alexander, Julian
12. DocPages: Alexander (main) 

### Explanation

Maybe the coding week would also be a good time to make an overview of the various components of AiiDA and divide and conquer the problem.

I think you need at least two people that are somewhat proficient with each component + Sebastiaan. A couple of components already:

1. The Engine: Everything relatet do processes, daemon, persistancy. Includes understanding the dependencies RabbitMQ, `circus`, `plumpy`, `kiwipy`. Also includes the work on a replacement of RabbitMQ.
--> Manage issues in aiida-core tagged with `topic/engine` 
2. Storage: Everything related to the database, repository, archive, migrations. There are still some complex issues to solve/improve here e.g. related to the Querybuilder. Expertise on `SQLAlchemy` is a must, but also probably SQL more generally as well as the disk objectstore and maintain commands.
--> Manage issues in aiida-core tagged with `topic/storage` 
2.1. Data types: Easier to get into, since it’s less of a complex and intertwined code base as other parts of AiiDA. Still, it would be good if someone could take the lead on the redesign of these data types as we move them outside of `aiida-core` into `aiida-atomistic`. A _major_ challenge here is still how we want to deal with migrations of plugins outside of AiiDA core.
2.2. Provenance graph: The Nodes and Links and creation of the provenance graph as well as its traversal
--> Manage issues in aiida-core tagged with `topic/provenance` 
2.3. Caching machanism: include how hash is generated for different data types. 
--> Manage issues in aiida-core tagged with `topic/caching`  
2.4. Diskobject-store
3. Verdi CLI: One would think this one is not so challenging, but the Verdi CLI is a complex beast as well. `click` expertise is an obvious must, especially since Sebastiaan really squeezed every last drop of features out of this package.
--> Manage issues in aiida-core tagged with `topic/verdi`
4. Schedulers/transport: Also somewhat intertwined with the engine, someone will have to be an expert on these components as well. Whatever implementation we choose for FireCrest, this person will have to be involved in reviewing/designing it.
--> Manage issues in aiida-core tagged with `topic/transport`, `topic/scheduler` as well as  `aiidateam/aiida-firecrest` repo
5. RestAPI: a bit of a trouble child in relation to dependencies lately, it’s clear that no one is really giving this part of AiiDA much love. I’ve even been wondering if we should move this component to a separate repository, since it’s not strictly necessary for the functioning of AiiDA. Kristjan would be an obvious choice here.
--> Manage issues in aiida-core tagged with `topic/rest-api` and the repo `aiidateam/aiida-restapi`
--> Manage issues in aiida-core tagged with `topic/data-types` 
7. DevOps: CI workflows, dependencies management and Docker images. This includes both pip dependencies management and conda forge packages management. this includes following up on Security alerts from GitHub and automatic PRs
--> Manage issues in aiida-core tagged with `topic/devops` 
8. Plugin System modules and packages related. Those include `aiida-registry`, `aiida-plugin-cutter` and `aiida/plugins` modules.
--> Manage issues in aiida-core tagged with `topic/plugin-system` 
9. Discourse & Issues: Monitor Discourse questions & new issues and make sure someone replies in a reasonable amount of time. Everyone should reply to discourse questions when they have time.
10. Dependencies: 
--> Manage issues in aiida-core tagged with `dependencies` 
13. Website: Polishing and advertising to all users and potential users. 
14. AiiDA-WorkGraph: It as a aiida-core component to create AiiDA workflows.
15. DocPages: The aiida-core readthedocs page and the aiida-core developer documentation on the GitHub wiki and the maintenance of tutorials on the the aiida-tutorials readthedoc page. This excludes code documentation.
--> Manage issues in aiida-core tagged with `topic/documentation` and the `aiidateam/aiida-tutorials` repo 

Updates:
- Plugin was completely forgotten, added it 
- Removed tests responsbility, because every subgroup needs to be responsible for managing their pytest fixtures. Typically the issues that go in this direction are more about DevOps
- Renamed Documentation -> DocPages
- I merged dependencies with DevOps, because CI failure go hand in hand with dependencies.
- I have almost no issues regarding the provenance, not sure how to solve this
- We did not assign caching, merged caching it with engine
- Removed Jason from storage and added him and me to engine. Made me manager 

TODO:
- Assign responsibilities for caching
- Add the final version also to the wiki of the GitHub repo
