Sprint 1 Reflections

Vicky:
For Sprint 1, most of us faced a lot of technical difficulties trying to both understand all the existing codebase and what we need to implement. We originally divided up the team to handling 2 different user stories/features. Originally I was assigned for the UI part of the endorsement feature where only professors/TAs should be able to endorse a post but then the team realized there was more technical difficulties going on in figuring out the backend of the code and how to establish new fields/relationships for this feature and so I joined in. I tried to understand what my partner Evelynn has already built in terms of the backend endorsement feature of the code and made a separate branch to experiment with it but struggled understanding lots of the implementation and what wasn't passing in the test case. I then tried to create a new branch of my own for the backend code and attempted to also build the endorsement feature from scratch by mimicking the layout of the upvote feature (due to its similarity with endorsement) that's already there but wasn't able to get through all of it due to how time consuming understanding the codebase was. I tried to build off what Evelynn did and add routing/api related code to the src/api/post.js file for the sake of tying the front end to the back end and also tried making some operational related code in the src/posts/data.js file.

Evelynn:
For Sprint 1 I mainly focused on implementing the backend for allowing an instructor/TA to endorse a post. I designed how the endorsement status would be stored (would be an int field for the ID of the user who endorsed, null if no endorsement) and made changes to the Post's schema, socket.io, API, write controller, and a couple others. I also wrote
test cases for the endorsement function in test/posts.js. During development I realized that this issue was larger than expected, with multiple dependencies throughout the codebase. I was able to successfully endorse a post, but failed the test case to unendorse due to faulty logic. The delays in the backend implementation also delayed implementation of the frontend and integration. For the next sprint, I will better evaluate the technical demands of an issue and better collaborate with my team members so we can develop in parallel and be more efficient.

Cass:
For Sprint 1 I focused on helping with both BE and FE implement with the endorsement feature. I added the localization string for the error messages, helped with finding/understanding the structure for UI features. We realized the labor division was not as effective and there are a lot of dependencies between the files. We hope to work more closely in the future sprints and moves some goals from sprint 1 to sprint 2.

Alice:
For Sprint 1, I tried implementing the Backend for marking if the post is answered by the Staff or not. I also helped Anna out with the draft wireframe for the UI. However, things didn't go as planned because I was unfamiliar with working with Redis. Hence, it took me a while to learn adding a new field into YAML files. I also adhered to the unanswered.js file because my feature and that has similar structure. However, I haven't figured out how these components will interact with each other yet. So test cases aren't written.

Anna:
For Sprint 1 my goal was to plan out the UI for the change, coordinate with Alice on her progress, and implement the front end based on her progress. While I did wireframe and plan out the change for button, I did not reach the rest of the goals. As with the rest of the team, I significantly underestimated just how difficult it would be to fully understand the codebase. After reading a couple files, I thought I understood more than I did and would move on, then I would find myself returning to the same files over and over again. It was also difficult because since the change was to be made on a main page, the UI trigger was really just to open a page and didn't help very much with narrowing down specific aspects to change. I also think Alice and I could have improved our communication. For example, we could have a spent more time going through the code and discussing what we learned together to be more productive rather than doing it on our own and getting our own individual perspective of how to go about implementing this one feature.