I lost my patience for politeness somewhere around the third or fourth time this happened with the same kind of excuses.
RE: your status, we both know that while it is your job to foster goodfeels in the community, there is also a line in the sand and there are things you cannot be honest about. Some of those obligations are “general professionalism” and others are just dictated by your corporate culture. You are a company rep, you have to tow their line, but that status can be abused.
Since you guys are looking for a process, I’mma help you out.
First, I assume you have an issue tracker like Jira. It might not specifically be Jira, but you can probably customize it. You should have one that allows this. “A whiteboard with post-its” is OK.
Next, you add a “release notes” field to every. Single. Issue. It doesn’t have to be big.
Next, you probably have a series of statuses like “Open”, “In Progress”, “Ready for Test”, and “Done”, with rules in place about when and how issues move between states. Put “Documentation” between “Ready for Test” and “Done”. The rules:
- After an issue is tested, it moves to “Documentation”.
- Now it is “who does the release notes?” person’s responsibility to check Known Issues, Help, and the Release Notes to make sure they reflect this issue’s completion.
- When that person is satisfied it moves to “Done”.
- Code CANNOT BE SUBMITTED OR RELEASED unless it is “Done”.
- The person responsible for this state is reviewed on how well they maintain it. The person responsible for the release notes should know any promotions or bonuses they expect are conditional and tied to their ability to maintain the process.
- If a person different than that one moves it beyond the state to Done, that person has to discuss it in their review meeting re: their expected promotions and bonuses, particularly if it had a large negative impact on player sentiment. This is akin to intentionally releasing bugs and an offense that can lead to discipline.
I’ve never worked anywhere that didn’t use this process, and I’ve also never worked anywhere that forgot to put things in the release notes. Sometimes we had conscious discussions about if something qualified for the release notes, but isn’t that the aim? “If something isn’t in the release notes it’s because so and so agreed it wasn’t relevant, signed and dated in our issue tracking system next to the documentation of the fix.”
If you do not have or want to adopt processes like that, it is not mean-spirited for me to note your team is not behaving professionally. Part of being professional is having processes that make you accountable. This isn’t secret sauce in the industry, it was laid out in a Project Management 101 class I was forced to take in college.