forked from MIT-Emerging-Talent/ET6-practice-code-review
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added first part of the retrospective.
- Loading branch information
Showing
1 changed file
with
25 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,23 +1,37 @@ | ||
<!-- this template is for inspiration, feel free to change it however you like! --> | ||
|
||
# Retrospective | ||
# Retrospective :rewind: | ||
|
||
## Stop Doing | ||
“_Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand._” __NORM KERTH.__ | ||
|
||
## Continue Doing | ||
__*Over the past weeks, our group embarked on the journey of learning and practicing effective code reviews. This retrospective aims to reflect on our experiences, evaluate what went well, identify areas for improvement, and outline actionable steps to enhance our skills further. By reviewing our process and establishing the best practices for future code reviews, we hope to foster a collaborative environment.*__ | ||
|
||
## Start Doing | ||
## Stop doing :no_good: | ||
|
||
## Lessons Learned | ||
1. Stop merging changes without proper reviews. | ||
|
||
______________________________________________________________________ | ||
## Continue doing :thumbsup: | ||
|
||
## Strategy vs. Board | ||
1. Regular code reviews. | ||
2. Helping each other out to ensure no one is left behind. | ||
3. Carrying out regular video calls | ||
4. Being active in the group | ||
5. Automated testing for critical features | ||
6. Setting clear deadlines for deliverables | ||
7. Sharing resources and insights to improve team knowledge and skills collectively. | ||
|
||
### What parts of your plan went as expected? | ||
## Start doing :rocket: | ||
|
||
### What parts of your plan did not work out? | ||
1. __Conducting regular check-ins to align on progress and adjust priorities as needed.__ | ||
2. __Tracking and addressing recurring issues__; _We noticed that some issues, like not using descriptive enough names for variables (e.g., naming a variable s instead of binary_str), kept coming up during our reviews. To avoid making the same mistakes as a group and having to point them out individually each time, we plan to keep a shared list of these common issues. This way, everyone can see and remember them, helping us improve and use better practices in future projects._ | ||
|
||
### Did you need to add things that weren't in your strategy? | ||
## Lessons Learned :mortar_board: | ||
|
||
### Or remove extra steps? | ||
1. __Importance of clear communication and task assignment__ | ||
2. __Benefits of automated testing and continuous integration__ | ||
3. __Value of regular team feedback and retrospectives__ | ||
4. __The importance of role clarity__: _Assigning clear roles in each review cycle (e.g., reviewer, author, maintainer) ensures accountability and smoothens the workflow_. | ||
5. __The value of iterative learning__: _Every mistake or challenge faced during this process offered an opportunity to grow and refine our practices._ | ||
6. __Effective prioritization leads to efficiency__: _Focus on the most impactful changes during reviews to optimize time and effort._ | ||
|
||
--- |