Some of you might aware of this, we build our company like we build software. We try to mark the release of Dwarves 2.0 by the end of this year, and this is one of the changes that we’ve adopted recently.
We have an autobot for auto release. But somehow the information flow still got blocked.
Normally, team leads jot down their team output in Project Status Meeting every Friday. But here's the thing, it only contains the outstanding point such as which product has been on air, or some adjustment in the line-up resource.
Progress is shipped out everyday. But the proof for that is located at many corners. So we figure, how does a master changelog sounds like?
Master changelog is used to communicate our work effectively. Internally and externally. We gather the mini achievements from each project into one hub where people can browse, add up their opinion and create their own newsletter for different scenarios.
Master changelog brings a bird view on our internal work. In a broader goal, it speaks up how our work bring impact to the whole project milestone, more than just the daily done list update.
It all started with the first sprint planning, followed by a process of development, features releasing and change log drafting.
In the next post, we’ll dig deeper on how each information source get filtered until it reaches the final audience. There will be 4 main sources
- Tech R&D: Knowledge hub for industry movement catch-up
- Project: Latest changelog on project development & project milestone
- Operations: Update on workflow and internal policies
- Sales: Team’s sync up on deal and partnership status
PR is a building block of our workflow. This builds up all the generated information. Before doing any actual work, the empty-early pull request is created, including the detailed implementation plan/diagram/., etc. The technical design must as well be agreed upon beforehand.
During the PR, the commit must follow these prefix rules:
- feat: indicate it is a new feature
- fix: bug fix
- perf/chore/style: any chore work
It's possible to group the right message to the changelog by using those prefixes. After the implementation, a GIF or screenshot of the PR should be taken and embedded in the PR.
We don't do weekly releases. We aim for the shorter releases on the staging level. By breaking into short ones, in our perspective, releases are more comfortable to identify, test, and resolve. Still, it's short, but that doesn't prevent us from bringing the quality of them to the highest level.
That's why QC's place to view the release list and sign them off in advance is necessary. Automation testing reports, in some cases, can be considered as well.
Once the changes are landed, we wrap it up with a message for every project to walk through which change has been pushed—a public announcement to keep everyone on the same page.
After releases were made, we collect and turn them into changelogs—a summary of what has been checked off. At the end of the week, we collect those separated changelogs from each project and combine them into a master release, or, the team's communication backbone.
We often use HackMD for team composing, or Notion sometimes.
Depends on the audience type, we tailor it for better communication purposes. For internal, it may perform as a weekly digest conducted by Duy. Meanwhile, Khai can add up some product vision and deliver it to Product Owners, or Giang sort out the key points to help engage the credibility between DF and the clients.
Subscribe for “The Next Bytes” where Han & the crew draft up our observation in the industry.