Quick roadmap

Ideas that should be made into issues

1. We need to discuss CRUD wiki page (Bonnie made it) and how it interacts with the notes Fang has added under this section "**Documentation** is the "frontend" of PeopleDepot.

2. We need to create a guide for adding new models to the code. Step by step

   • make an example for seeding data into the database. This would go into the guide for adding models
   • documentation and examples

3. We need to plan and track the creation of tables. I propose using meta/master issues

   • Tables to add for VRMS
   • The spreadsheet that has all the tables and their priority for tracking

4. Onboarding documentation

   • recommended tools
   • vscode plugins
     • hadolint
     • pylance
     • visual studio code remote
   • host OS python requirement for pre-commit

5. I would like to use openapi-generator to generate the API client for use by any frontend code. It's essentially a wrapper that hides the actual network requests and deserializing the data into objects. To the client code, it would feel like it's calling a library function and getting back an object read to use. See this for exactly what I want to do. We're already using drf-spectacular to generate our API doc. https://www.saaspegasus.com/guides/modern-javascript-for-django-developers/apis/?utm_campaign=Django%2BNewsletter&utm_medium=email&utm_source=Django_Newsletter_141#api-clients . We can set up a gh action to generate this library on commit to main or a release branch.

   • document how to run manually
   • set up gh actions to auto generate
   • add to "add model" guide with relevant additions needed to the code. e.g. The client library access function names are set in the api doc annotations

6. local development for VRMS. We need to set up a way for VRMS to use PeopleDepot for development locally. This probably requires making a new docker-compose.yml that starts the VRMS container alongside the PeopleDepot ones and connects them.

   • local cognito mock so it doesn't need the internet
     • https://github.com/insomenia/cognito-mock

7. We need to deploy a dev and maybe even staging environment soon for VRMS. They are currently migrating from v3 to v4 which is supposed to use PeopleDepot for the backend, but we're not ready yet. I hope we can get this done in 2 months, say mid-October.

   • We need to split the Dockerfile and requirements into dev and prod. The testing stuff shouldn't go into the production build.
   • Maybe we can delay deployment if VRMS can use PeopleDepot locally. Can run VRMS in a separate container alongside peopledepot

8. We need to set up pre-commit hooks to run the pre-commit script for each commit. It lints, formats, clean builds, and tests the code.

9. I would like for us to use conventional commits in this project. It's industry standard or feels like it's going to be. One advantage is it takes care of incrementing versions for us when used with gh actions. It also helps with release notes.

   • document and create examples

10. Documentation is the "frontend" of PeopleDepot. Assume we're a standalone project trying to attract developers to store their data in our backend.

    • Tutorials for building functional "projects"
    • Guides that outline the steps to do certain things, like the "create new model" guide for our contributing section
    • API doc in OpenAPI using drf-spectacular which is generated from the code
    • Reference doc that describes the components in a logical way. This is analogous to integration testing vs unit testing (API doc)
    • use sphinx which is the most mature system for python, uses rST We've decided to use MkDocs
      • mkdocs is another system, it came later with less complete features but is currently the most popular, uses md
      • Of our 2 biggest dependencies, djangoproject.com uses sphinx while django-restframework.org uses mkdocs
    • use either mermaid or plantUML for diagrams. They're both text markups that work well with git.
      • https://www.planttext.com/
      • plantUML is more mature and mermaid is newer and maybe more popular since it does in-browser js rendering as opposed to plantUML which renders on the backend.

11. Wishlist. This is just a thought and not part of the system. I find myself often asking people (wondering) what their experience/familiarity levels are. It would be great if that's available to look up within a team. Either by the leads or even for the members.

    • I'm looking for tech and experience level, like done it before, some experience, lots of experience, deep knowledge, or read about it, followed a tutorial on it, worked with it, wrote a guide on it, mentored it.