# 2023-04-14 Meeting minutes
###### tags: `Meeting`
**13:00 | Zoom**

Present: Martin, Mathias, Jacob, Christoffer, Linn, Edvin

## Before the meeting
* Everyone should have read through the entire thesis at least once, and created issues and left comments about what to improve.

## Agenda
* Around the table
* Current purpose:
* The purpose of this project is to develop a framework for developers to create well-performing simulations or games, while limiting the need to manually handle issues like cache management and concurrency. The primary concerns are to ensure speed and scalability of the framework. Code quality and readability should also be taken into consideration in order to improve the ease of expansion and the use as a tool for product development.
* New suggested purposes:
* "The purpose of the thesis is to explore, test and benchmark different implementation approaches to the 'parts' that make up an 'Entity Component System'-Framework and how these impact performance differently."
* The purpose should be about documenting and researching what goes into making a performant ECS engine. (This way we're not trying to contribute something revolutionary, but instead performing research about what the state-of-the-art is and how we can go about implementing it ourselves.)
* The purpose of the thesis is to investigate how a general purpose ECS framework, with features for cache efficiency and concurrency can be implemented in Rust, based on current research and open-source ECS project.
* Discussion points
* Interesting to discuss why the prestanda differs between our engine and others
* Different things we have tried to implement already that we can compare between?
* staged and unstaged in scheduling
* Archetypes or Sparse Sets
* Changing the purpose at this point is hard, many things would have been made different if we had another purpose
* The suggested purpose change would perhaps have made us go down another more modular route with the engine
* How do we want to do reviews of "Thesis issues"?
* Write in Slack whenever a section is ready for review? And do similar reactions as we do with PRs?
* Or some other way?
* When does a thesis issue go from `In review` to `Done`?
* what will the benchmark results be used for?
- To compare our engines implementation against others?
- We can have a part in the discussion that analyzes and reasons about why the difference in performance exists, and suggest improvements.
* Clean up `In review`
* Go through issues in backlog and reprioritize
* Go through normal issues in `New` and modify/prioritize/discard/place in backlog
* Go through thesis-issues in `New` and modify/prioritize/discard/place in backlog
* Issue for running problem as well
* Go through (double-check) this week's feedback from Yehia and last week's feedback
* Current project status
* What important issues are left?
* Is everything going according to plan?
* Is anything blocking us from doing something?
* Come up with timeline for upcoming weeks
* When is the next important deadline?
* When is the project over?
* When should the thesis be done?
* Send the thesis to Yehia
* Send the thesis to fackspråk
* Need to come up with questions
* Possible question: how to handle prototypes better in method?
* are we using the method section correctly?
* Possible question: how to structure related works, chronologically?
* are we using the related works section correctly?
* Possible question: how to structure results?
* we have thought about dividing it into three parts: first part describes the engine implementation and how to use it, the second part presents and describes our benchmarking results, the third part describes our process of figuring out what implementation to use for the engine
* Possible question: what is the exact distinction between results and discussion? Is it okay to motivate decisions in results, or is that considered discussion?

## Decisions
* Related Works could be a section separate from History of ECS
* In Related Works, we can state that it's not a very research-heavy field, it's much more industry-based (i.e. GitHub-projects)
* Questions to Yehia
* We feel like our purpose at this moment doesn't really work, because we feel like it is already reached by others. Therefore we were wondering if we can modify it a little bit, or if that is a bad idea. Our purpose right now is this: "The purpose of this project is to develop a framework for developers to create well-performing simulations or games, while limiting the need to manually handle issues like cache management and concurrency. The primary concerns are to ensure speed and scalability of the framework. Code quality and readability should also be taken into consideration in order to improve the ease of expansion and the use as a tool for product development." There are already engines out there that does this. So we were thinking of changing it to something we can easier reach, which is research and document about how to develop an ECS engine. What do you think about modifying our purpose to this? And if this is okay, how would this change how we write the result?
* Could you take a look at the section "The Entity Component System Architecture" in introduction? It is a kind-of high-level overview like you asked for in the beginning of background. Is it enough or do you think we should add a more detailed overview in background as well?
* How we handle thesis issues:
* Once you're done with a thesis issue,
1. move it to `In review`
2. send a message in `review-me-pls` stating exactly what parts of the text you've changed. If you've got anything specific you'd like feedback on, then mention that in the message.
3. everyone else in the group will leave :eyes: when they begin reviewing
4. during a review, leave comments inside the thesis
5. after a review is done, send a message in the thread from `review-me-pls` indicating you're done and whether you want changes to be made before this issue is considered complete (just like PRs)
6. once at least two others have reviewed and approved it, it is moved from `In review` to `Done` by the author

## Next meeting

**2023-04-18 | 09:00 | EG-3507**

*