We've probably all been in the situation where you'd like to alert your team members to some change ("I changed X, so now it's running every hour instead of every day"). But the change is non-urgent, and email can be disruptive - or get tuned out.

Anyone have any techniques where the team can have a running log of changes that everyone should be aware of, that they can peruse at their leisure - or at least, when they suspect something is up?

7 Answers 7


If your team find email disruptive or tune it out, something is wrong (they've set their notifications to be too in-your-face, or they're getting too many private emails, or they haven't set up filters/triggers properly). Email is, in my opinion, the perfect tool for this. Set it up right and it will serve its purpose.

You could do something silly and complicated, like use a wiki page, set up an RSS feed specifically for this, or give the team a freakin' twitter account, but when you stop and think about it, email can already do what you want.


I think a very good practice is to setup a post commit hook to email the diff of changes. Set a fixed subject prefix and [email protected] sender address to make them easy to filter out, so it's non-intrusive.

We've been doing this at all my past workplaces, and it's always popular. Many developers read the diffs regularly and recommend improvements to each other. It's a good way to keep everybody involved well-informed about the changes happening in the project. Some developers might not be too happy at first, I've heard complaints of "some strange spam", referring to the diff emails, but even the skeptics tend to warm to the idea after a while. I strongly recommend it.


what about adding a textfile "compatibility_issues.txt" where configuration or code behaviour changes are added together with version/datetime info and add this file to the sourcecode-repository. This way the issues don-t get lost and you can find out the source-code fragments that are related to the changes through sourcecode-repository history.

however i would also keep emailing these issues.

Do you have a naming convention for these emails. If i as a developper am not intrerested in this "compatibility-change-spam" i can setup an email-filter for this.


I assume you have changed something because you had a defect to correct or a feature implemented. Therefoer the correct way for people to know about these changes is your change tracking system.

If email is your change tracking system and people are not reading emails, it will make little difference if you send one or don't........


Enforce (ideally automatically) the creation of checkin comments in your source control system. That way people can easily see a summary of the changes that have been made recently.


We do this 2 ways. First, for most apps, configuration files are versioned using SVN. So you can always go svn log and perhaps get some context. Second, we use an issue tracker as the official record of requests and changes. People can manage their settings themselves in that system to manage their own spam. Either way you are covered -- you've got local technical info and perhaps context in the issue tracker and nothing is in your face unless you want it that way.


In our team we do code reviews with Gerrit now, and since we started it became easier to keep everyone in the loop about code changes. The team is relatively small, and everyone reviews everyone others changes, so the awareness of them is quite high. We've agreed to start a day with code reviews, and code doesn't go to master branch before being reviewed, so usually there's a push from the code's author to get his change merged, and the review process doesn't stuck. I guess, introducing a code review might be a too big change in your development process to take this as an answer, but this definitely helps.

Not the answer you're looking for? Browse other questions tagged or ask your own question.