Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

6 Answers 6

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 noreply@yourcompany.com sender address to make them easy to filter out and non-intrusive.

At one of my past workplaces this method was well embraced. The developers actually read the diffs, recommended improvements for each other, and were in general well aware of all the changes going on in the project. At all other workplaces I ended up being the only one reading these emails, and new developers often complained about "some strange spam", referring to the diff emails.

Reading diffs is not rocket science. It is a good practice which allows your team to spot big problems quickly (more eyes see more), and better code in general.

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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