I can certainly understand the frustration of developers, staff and volunteer, in trying to find a good way to communicate with the very diverse communities about changes. The number of volunteer testers is small (and often tending toward the technically highly literate), the potential number of venues is very large and multi-lingual, and it is often difficult to sort out "dinosaur" responses to change from those that are valid concerns.
I don't have any perfect answers here, but whatever decision is made, I'd urge that the following be considered when communicating about changes, particularly anything that is noticeable to an editor without any technical knowledge:
- "Communication" implies that there is an opportunity for the recipient to respond, whether with questions, suggestions, or concerns. Whatever process is selected should accommodate that. - Any notifications about change, particularly to the UI or to content handling, should clearly explain what is new, what will be removed, why the decision was made to make the change, how the change will affect accessibility (e.g., screen readers) and usability, and who to contact with questions/suggestions/concerns. Any opt-out processes should also be clearly indicated. - When making changes and communicating about them, always be clear who the customer is, and remember to keep focus on that. The "customer" may be readers, unregistered users, registered users, a key organizational process (e.g., accessibility, security), a project, or some other entity. Where possible, involve the customer in the public discussion about the change. - Remember that the majority of "visible" changes will affect people (readers and users) who have very limited technical knowledge; write in plain language without jargon. Get someone with limited techie vocabulary and understanding to copy edit your communication.
These are useful, and fairly standard, communication processes. Here's hoping that a good solution can be found, for everyone's sake.
Risker/Anne