marlitas
commented
1 year ago Here are the meeting minutes:
What was the timeline and who worked on this this sim when?
AP and LV from the beginning.
CK and LV: Original development of the decay screen. Published as a prototype. MS and CK and LV: worked on refactoring code for a second screen. 10/22 MS and LV: Picked things back up to add the chart intro screen. MK and LV: MK helping bring to the finish line around 7/23.
Successes:
**AP: LV’s goals of “full stack” involvement. Design, pedagogy, look and feel, development, phet processes. It was all her! AP: The sim is really excellent. I am proud of the final product. It is PhET-Like. AP: Though the sim took a long time to publish, the timeline met expectation. MS: LV got to work with 3 devs, which is a lot and that is good. MS: I appreciated all the outside dev support MS and LV got along the way. CK: LV full dev experience. Lots of good learning from things like factoring out code for a new screen. *CK: It is an amazing, award winning sim! MK: LV was really able to provide the stability through the whole process. *MK: QA was quick and easy. KP: Such a success story about an outside collaboration. KP: LV’s experience gain and general growth. LV: Growth and independence gained. **LV: Really happy with the sim, proud of it, able to present at conferences for it. LV: Design process: using Jason from the beginning. Iterative design/dev process.
Improvements:
AP: The sim took a long long time to publish. LV was pretty part time, MS CK and MK all had to trade the sim off and ramp up. *AP: It would have been nice if we knew from the beginning that LV could have been supported through all of it. It is hard to do this because of budgeting etc. MS: Hard to keep track of what we were working on, because of such a limited amount of weekly time spent on it. **MS: Hard to work on 2 very different sims at the same time (BAN and Center and Variability). *CK: Hard to work in such a split-time manner. Pairing started at just a few hours, but a larger chunk would have been more efficient and faster LV growth too. MK: I wish there were more resources (outside of direct pairing time) to support outside collaborators. *MK: Prototypes make sims hard to maintain, and it was much harder to publish because of it. KP: This was an unfunded simulation. That was a challenge. ***KP: We need to rethink the PhET model of having an intern. Supporting devs experience a really long tail on the sim. We need to brainstorm how to support interns/outside collaborators in our new iteration model. 2 years is pretty common for a sim publication when an intern is the lead. LV: Challenge to add the second screen well after the first screen. **LV: It was a challenge to switch the developer I was working with.
Discussion:
MS: Hard to work on 2 very different sims at the same time (BAN and Center and Variability) MK: I believe much of this has been solved with strong will and the iteration planning process (or so I hope).
KP: We need to rethink the PhET model of having an intern. Supporting devs experience a really long tail on the sim. We need to brainstorm how to support interns/outside collaborators in our new iteration model. 2 years is pretty common for a sim publication when an intern is the lead. AP: Let’s definitely brainstorm this. How can we support this? KP: Right now we just aren’t. AP: Even if not currently feasible, we should keep this in mind as an important mission-driven piece of PhET. MS: How does this relate to POSE? KP: We will need to solve this in relation to POSE (if we get that grant) MS: It is best if an intern can be in the sim from the start. MK: We may also want to raise the bar on what an intern can offer (more dev experience or ability to give that much more time) to help onboarding and to integrate into interaction-team-style phet development. AP: This is not an intern-onboarding problem. This is a general dev onboarding problem. If we added more supporting resources for onboarding devs in general, this would help interns. KP: This is part of the POSE grant work we are hoping to be able to do. NEXT STEP: another brainstorming conversation so that the answer isn’t what it currently is (we don’t take on interns).
LV: It was a challenge to switch the developer I was working with. KP: LV, even though it was hard to switch devs, did you feel it was valuable to see multiple dev styles? LV: I did like seeing the way different people worked, the main issue was in how the transitions between each dev occurred AP: Did the CK/MS overlap help? LV: Yes I think that helped, and then afterwards we would reach out to CK when we needed help. LV: It was more of a challenge because we switched to a different style. With CK I wasn’t leading as much, with MS I was now leading more and so that felt like a bigger jump. There was less reference to pull from on the second screen. MS: That may have been miscommunication on my part. I did not fully understand the learning relationship there. LV: Having MK observe MS/LV pairing was really helpful in that transition. AP: A process would be really helpful here. MS: There was a pairing session where we used the IntelliJ remote working tool (I could place my cursor and type on her screen). LV: I think that could have been helpful in that leadership transition.
NEXT STEP: Creating a process for switching devs, or just staying away from it. We need to reinvent the intern model. This is part of the above “Next Step”
Stats: BaN is on track for 500 thousands runs a year.
- Modifications to look and feel?
- Nope
- Something to point out is the double button that combined the behavior of two other buttons. Worked well for this sim. Is unique. Doesn’t need to be formally noted. Comes with costs but here it outweighed those costs.
- Modifications to sim design process?
- Nope
- Process was iterative. Didn’t feel destructive.
- Design changes didn’t cause us to have to backtrack. Felt smooth overall.
- Modifications to project process?
- Lots of modifications happened throughout the lifetime of this project.
- Nothing else is coming up, besides the above mentioned Intern process that needs to be developed.
- Messages to share at status?
- We should share the usage in the month of October!
https://github.com/phetsims/phet-info/blob/f9fcab965f857627b7a2da4d0bb90f95ea9edc1e/checklists/postmortem-process.md
[x] 1. Schedule the meeting
Require the entire sim team to participate, and optionally anyone else who had a significant involvement. Have the meeting as soon as possible after the sim is released, so that experiences are still fresh in everyone's mind. Allow sufficient time for the meeting, 1.5-2 hours.
[ ] 2. Enlist a meeting moderator
The moderator's job is to make sure the meeting runs efficiently, stays on point, and focuses on constructive (but not overly negative) criticism. The moderator can be someone not on the sim team, or in many cases the Development Coordinator. The moderator also documents the important points of the meeting.
[x] 3. Create github postmortem issue and postmortem google doc
Create a github issue in the repository of the sim for which the postmortem is occurring. This checklist will should be copied into the issue.
Create a postmortem google doc for the sim and set phethelp as the owner. This google doc should live within the appropriate sim folder on google drive.
[x] 4. Two successes and two improvements
Require participants to bring a list of no more than 2 items that were done well during the project and no more than 2 items that could be improved upon. Limiting to 2 requires people to think critically about their experience.
[x] 5. Identifying the top five
At the meeting, start by having each person present their items (successes, then improvements). Make a list of these items, and note duplicates. Based on popularity, identify the top 5 success items and the top 5 items that need improvement.
Discuss the 5 success items first. Identify specific things that can be applied to future sims. Celebrate, pat each other on the back. Then move on to the harder part.
Discuss the 5 improvement items. Try to avoid getting personal. Discuss what was learned, and identify specific things that can be done to prevent these problems in the future. If anything needs more investigation, assign to specific individuals.
[x] 6. Modifications to Look & Feel
Identify modifications to the PhET Look-&-Feel Guidelines. If applicable, based on what we learned during development of this sim, suggest revisions to the guidelines.
HTML5 Look and Feel
HTML5 Visual Sim Design Elements
[ ] 7. Sim checklist
Review the Sim Checklist
[x] 8. Action items
Note important items in the postmortem github issue, and create issues for any tasks the require action (such as updating documents, leftover "todo's", etc.
Action Item Questions:
[ ] 9. Take home messages
From the top 5 successes/improvements, decide what are the "take home messages" that would be useful to note in the future, and add these to the HTML5 Postmortem Take Home Messages google doc
Report out at status meeting