What went well?
ADRs for shared clarity
Regular syncs to review UX
Producing ADRs and PRs in draft form for early, fast feedback
ADRs help us reach agreement on complex topics that are difficult to talk about in a meeting and keep in your head
More granular tasks are very helpful; both for visibility and sanity
We now have much clearer scope for upcoming milestones.
Everyone seems to be on the same page regarding project handoff
Handoff meetings went well
What could be improved?
Communication got better, but still could focus more on doing daily async standups
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 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/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 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
What did we achieve? (for sharing, demos, or simple visibility)
Working LTI integrations on the sandbox instance.
Piazza, YellowDig and potentially other LTI tools will now work. Discourse can work with some caveats
Infrastructure is there to support other kinds of LTI tools in course tabs as well.
All major structural work in frontend-app-course-authoring is done or nearing completion… we should just be left with smaller things and polish.
What went well?
Everyone was really nice and didn’t want to take this first bullet - so I did!
Sandbox / Stage visibility of various project areas is helpful (for now and future work review)
Great to have as a foundation
More detail to specific v1 / v1.1 milestones
Earlier discovery and detail for v1.1+ milestones
(not done, but more planning than we have had in the past for this project)
also helps with UX sequencing / discovery work for post v1.1
the original discovery was another way of arranging milestones, new milestones had shifted starting point
^ this note might relate to the “Reducing churn / rework” item in “what could be improved” below.
Intra team collaboration! Daily status in Slack, more productive checkin meetings discussing architecture etc
meetings with agendas is a win!
more specific technical conversations also in meetings (with documentation / notes!)
this has also helped with accountability (along with ADRs, etc)
more collaborative + collective team feel now compared to before.
helpful daily updates + status + 1
Beginning to collaborate with UX
David Joy (Deactivated) try to work closely with Ange & Jon to keep collaboration tight
What could be improved?
Continuing to improve clarity on who’s doing what, i.e., individual tasks, parts of the project, edX vs. OC, etc. Nothing specific here, but just something that feels like it could keep getting better.
Consensus (on edX side particularly) of build our own vs discourse
nb. task on board to do discovery/spike and decide once & for all
…
Reducing churn / rework on tasks for future milestones
(v1 / v1.1 had a fair amount of reworked PRs / ADRs etc that spanned several weeks/months)
Improved clarity on what’s in each milestone will help here
Kshitij: since I’ve done discovery on different parts of the platform, assumed that was the starting point - this caused issues b/c think people weren’t familiar with that approach
edX time constraints in Q1 should be lessened going into Q3
Process wise: concerning whether or not our general approach is correct this late into the project (build vs discourse)
A focus on delivering value to learners / educators by certain ~rough dates now that we have the infrastructure for various discussions platform areas in place
This wasn’t as possible / clear in the past but hopefully can be soon!
Agree - it still feels difficult to provide estimates/dates, even for the early milestones. Not 100% sure why.
How to get clarity - point estimates - otherwise feels difficult to provide any sort of ballpark dates (need to understand the commitment of your team)
don’t have a baseline
do we have the appetite to do this?
When we get to a milestone, write a doc about all our assumptions and estimate the # of hours or even tshirt sizes would help us
Write down in epic in Jira
Have VERY precise AC on tickets to help estimate
What did we achieve? (for sharing, demos, or simple visibility)
ADR completed
Base configuration model(s) merged.
List of milestones & tasks laid out in Jira
Agreement and clarity on many technical details and on early milestone technical scope
Decisions
Action Items
Anything else you want to talk about? (parking lot)
What went well?
Scoping milestone 1 down into something we all understood
Worked well when we correlated our milestones w/ what PRs needed to be merged
More cohesive discovery/milestones was useful
Collaboration with Discussions + LTI project to land course tab LTI work early on
Great ADRs - they really helped me understand what was going on quickly.
MFE build / view of course authoring + discussion apps exist and are helping clean up platform boundaries along the way
Increasing the frequency of the meetings allowed for closer loops and quicker+better feedback +1
Deep dive technical meetings was really helpful; Kshitij Sobti was really good at leading discussions. This synchronous conversations were good. Unclear where this type of conversation should go outside of this meeting
Shift away from relying on initial discovery documents is helping to focus on milestones
Pattern: Be flexible as we dive into the project
Antipattern: edX should help review technical discovery documents up front
What could be improved?
Earlier ADRs
Clear definition of “blended”/roles: is edx just here to review/sign-off, or should we be allocate development capacity too?
Sarina: answer: edX allocates dev capacity to be more involved in the process
Clear milestones/delivery plan from the outset (product + eng)
More technical engagement up front
Templates/collateral could be improved upon. Format matters, could help a lot
Original document hasn’t changed since it was written; should we have revisited this document to answer questions/make it a living doc?
What does “ready for kickoff” means? Needs definition.
Don’t think we were at this point when we started
Kickoffs should assign discovery ownership, go through unanswered questions, figure out lines of communication, figure out jumping-off points
Milestone kickoffs (mentioned down-ballot)
Outset: no discussions MFE; now, 1/3 of the project.
Smaller scope at beginning and not exploding scope is important
Antipattern: “It’d be cool if…” “If we have time…”: needs more elaboration on if these are actual scope changes or just things we want
Detailed technical discovery happened in a sorta ad hoc way, from my perspective; felt like we had a lot of unanswered questions fairly late in the game
Better thought partnership from edX from project kickoff - we came up to speed kinda late
For every milestone (and definitely at the start of the project), have a meeting focused on going over the discovery, and brainstorming any issues.
Role clarity on blended expectations for edx technical leads + opencraft leads on project tracking / sequencing
Who should step up? edX giving some priorities is helpful; OC focused on getting a lot done simultaneously, which has lead to some far-off PRs being opened
The initial discoveries, should have been more thorough (on OpenCraft’s side)
edX review speed / timeliness on discovery documentation + plans for future work
Review speed has meant stacks of PRs building upon one another in backlog
Major rebases needed when base PRs needed changes
Makes things difficult to review when multiple reviews in flight
Idea: more granular PRs? to review serially to get things in
Idea: initially create the dependent PR be based against the "parent" PR, and then, if needed, you can re-point the PR against master/main
Can’t do on edx-platform b/c OC on fork
Could we do reviews in OC repo? Don’t see why not
edX struggled with prioritization of reviews vs many other in-flight projects (mostly internal)
always a re-ramp-up to get back into the project
edX engagement in first few months was lacking. Make sure we’re involved more thoroughly in every step
Originally had thought the 1000' view would be enough, but we’ve seen it not work well
Need to be involved in the code to a degree that we can be confident in releasing it to edx.org
Difficult to review - haven’t been able to get ahead of this
OC: not sure where to go next
ADRs have been helpful in development - forces a more clear definition. Helpful mental exercise
edX issue: multiple Jira tickets limits visibility of what’s actually going on (OSPR, BLENDED, TNL)
Need one canonical ticket - Kshitij recommends the TNL ticket; BLENDED just manages the ticket itself
limiting threads + active project scope to limit WIP and rewrites (related to clear milestones perhaps)
Fragmented/tons of documentation (particularly, in edX wiki) makes it hard to get up to speed
Better understanding of cross-project dependencies.
What did we achieve? (for sharing, demos, or simple visibility)
the initial working prototype for the new discussions app I’ve seen looks great
there is a demo (based on older code) of Piazza embedded in the course discussion tab
Decisions
Action Items
What’s next? (Nov/Dec goals)
Anything else you want to talk about? (parking lot)
Does current communication work for the team (#forums in Open edX slack, PR/BLENDED/TNL ticket comments, weekly checkins)?
Synchronous working well
Async not so much
Idea: have most comms on TNL tickets, and review on PRs themselves
Not use BLENDED tickets for communication
For decisions/posterity, record project decisions & important for posterity stuff in project pages in Confluence
How should edX surface TNL tickets assigned to OC so we don’t lose them?