Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as too broad by gnat, GlenH7, MichaelT, Bart van Ingen Schenau, Dan Pichelman Aug 13 '14 at 0:32

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 10 down vote accepted

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.

share|improve this answer

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 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.

share|improve this answer

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.

share|improve this answer

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........

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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