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