...
Communication got better, but still could focus more on doing daily async standups
🌟🌟It’s 🌟🌟 It’s not always possible to know in advance if an ADR will be needed for a task, and injected ADRs get harder to review.
architectural decision vs “how this task will be done” is a distinction that we may want to make here.
For this project (distributed, blended), may want to make assumption that ADR is a good idea, or ask project team for feedback when ticket is started if ADR is warranted
Want to reduce code churn / throwing away code / changing midflight
Awais Jibran (Deactivated) Make a list of all the ADRs on this project because they’re spread across multiple repos
Note: we have an ADR bot - can search for BD-03 wherever this bot posts (should catch most, but possibly not all, ADRs)
It posts on Slack #adr-notifications
Repos: fe-app-discussions, fe-app-course-authoring, edx-platform, xblock-lti-consumer
🌟🌟🌟 Need to agree on a level of detail in UX tickets that everyone’s comfortable with; David may have had enough context to make-do with less detail, but I think we’re learning that more might be helpful for folks onboarding into the project. Not really a ‘problem’, but something I think we’ll learn/work through together.
Mainly worth a call-out here; an adjustment to process
Current Miro board has a lot going on, maybe this could be broken up a little more for clarity
Jon F volunteering to make a separate Miro board - deliverables only (finalized designs)
🌟🌟 🌟Hard 🌟🌟🌟 Hard to get code reviewed sometimes, which is problematic if you’re working on a series of PRs that sorta depend on each other.
seems difficult in general at times having differing time allotment/committment commitment between teams (eg, one of TNL on call in a given week, conflicting OC sprints, etc.)
Coordinate scheduling better - communicate on-call, interrupts, vacations, as in advance as you can
OC works they have stuff for review on second Wednesday of sprint; keep in sync with edX team to make sure everyone knows that’s coming
Try to prioritise prioritize reviews when you can
Can be hard with timezones on a lot of things
Timing may be easier with Awais & team coming on the project
🌟 Frontend test coverage is lagging
Reviewing milestones frequently to make sure we’re on track
🌟 🌟🌟🌟🌟 Code refactors can be hard to rebase around so should probably be done in smaller steps.
Hard with stacked pull requests on top of some refactors
Smaller changes make it easier to do the rebase
Focus on incremental, user-facing delivery
🌟Churn around who is going to implement Paragon components
need to involve Product, Eng Mgrs in discussions
Meeting host needs to admit people from waiting room;
somehow even though I’m the meeting host so did I? Or did someone take over host somehow?
it thinks Steven is host/admin 🤷♂️
...