Here is a very good article on communication from software projects, why it is important, and how to do it well:
Different projects within the KDE and Qt worlds and their leadership have different viewpoints on how external communication could or should work. By and large, we do pretty well in our extended community in this regard. However, there has been an increasing number of lost opportunities as well as unfortunate incidents related to the way communication is being handled by some projects in our community. I certainly do not have all the answers and there is no "One True Approach", but in general I am a believer in continuous communication beyond one's borders.
I'll try and describe in this blog entry what "continuous communication" means, its benefits and its challenges from my point of view. I'll try and be thorough, so if some of the time spent in definition is a bit tedious, I apologize in advance. I hope you find something of use for your own projects and that you can also add to the following ideas so that everyone, including myself, can benefit from new ideas and personal growth.
It is written somewhat from the perspective of FOSS software development, but it applies more generally and I think it can give some insight into what people expect. As I have said before, I think the big failing of the Nvidia Linux developers is not so much that they are doing a bad job with the drivers, it is that they are doing a bad job (or, rather, no job at all) at communicating with users. Nobody has any clue what is being done, when it will be done, or even if it will be done.