Tomás to make master a protected branch on GitHub and require the Buildkite check to pass before merging it.
Nick document reviewing previous retrospective and include link in survey answers
Nick to change retro question to be a single question
Chris asks: What did we decide regarding manual testing, and how will we communicate that? Can be a Slack message
1 (Stephen+1) Stephen: Start More of us should start dedicating time to running through test plans. Only 3 team members did so early on, and the rest of us (including me, Stephen) did not until very late OR did not do so at all. This is bad because it delays gathering crucial feedback on things which delays releases such as 3.0.1
1 (Felix+1) Francis: Start Testing early. We have the same generic test plan for every release, this should be scheduled monthly and done automatically. We should also place a stronger emphasis on locking the code x hours before release. If it’s not done it doesn’t ship. We should encourage the mentality that not shipping something is sometimes a good thing - Sourcegraph catching bugs itself is way better than users catching them.
8 (Felix+2, Nick+2, Chris+2, Tomás+1, Stephen+1) Tomás: STOP So much manual testing: It slows us down.
1 (Tomás +1) Tomás: START Experimenting, validating, planning and estimating before scheduling and committing. Agreeing to do a certain piece of work in a fixed time window without understanding what it involves only leads to mayhem.
Chris: Keep smoothing out the onboarding experience because customers respond well to it (e.g. zero-config code intel)
Keegan: Stop Packing a lot of large changes into one release
Keegan: Continue Focusing on our q1 goal.
Francis: Continue We do a good job trying to pack our updates to the gills with features, fixes, and improvements. We should encourage this while doing so safely.
Francis: STOP We should stop encouraging changes at the 11th hour. If it’s not done, then make a place for moving it to the next release and help test features that are shipping.
Tomás: CONTINUE Shift the mentality of the team to time based releases.
4 (Chris +1, Tomás+1, Nick +2) Keegan: Start Ensure master is always releasable / easy to revert changes to unblock release.
3 (Chris+2, Tomás+1) Dan: Start Thinking about customer and end user impacts of features released. Ensure docs and the blog post cover migration paths from all major customer versions as part of the criteria for a feature being included in a release. Ensure this is well-communicated across the team, especially in public channels like #dev-announce and #go-to-market, so people on the GTM team and TAMs are all speaking the exact same language to customers.
2 (Tomás +1, Stephen+1) Tomás: STOP So much unstructured Slack communication: It’s hard to find the signal in the noise and leads to a tendency of being always on.
Dev process (5)
2 Stephen (Nick +1, Stephen+1): Continue focusing on real customer problems, because there is always a risk we will be side-tracked by less important work that feels important in a narrow view.
Chris: Improve our dev setup because my feedback cycle when working on the symbols service is longer than it could be, and all of these bash scripts are hard to follow. I’m willing to work on this a bit in the near future. Some ideas:
Rewrite the scripts in TypeScript, and run them with ts-node
Don’t restart all processes in the Procfile when one is rebuilt
Reduce the log spam
3 (Felix+2, Stephen+1) Stephen: I am unsure that having a retrospective for every version we ship (which appears to be the new standard) will be a valuable use of time. It seems like only yesterday that we did the 3.0-beta retrospective, and almost all of the same themes apply to 3.0. I would suggest a retrospective every 2nd version instead.
Chris: Can’t think of anything
Dan: Continue Being so helpful to one another and such a great team. :)