Provide extension developers with the ability to communicate with their users
There are a number of reasons an extension developer may wish to communicate with her user base:
- To alert users about a security issue
- To make announcements re the project roadmap, etc.
- To ensure sufficient community engagement to sustain development/maintenance
- To offer related paid services (e.g., training on the ins and outs of CiviMobile)
End users benefit from all of the above as well, but participation, naturally, should be opt-in.
Each developer is free to implement her own system for engaging users, but to:
- Prevent duplication of effort
- Provide a consistent user experience across extensions
- Provide legitimacy
... I posit that CiviCRM should provide some of the infrastructure.
A few ideas on potential implementation:
- When a user opts in, an API call is made to CiviCRM.org. This API will create a contact record for the Domain Organization, if one does not already exist on CiviCRM.org. Said contact will be added to a group named for the extension.
- The Domain Organization may not have useful contact info. It may be necessary to specify a technical contact as well. We have also discussed ideas for specifying who from the organization should be opted into the group -- different staffers may have interest in different extensions -- needs fleshing out.
- Provided they are CiviCRM Partners, maintainers of the extension (as specified on the extension node) will be granted access to this group via an ACL. They won't have access to CiviMail or anything of the sort -- CiviCRM, LLC is just providing the list.
- We'll need to write a code of conduct about how the contacts may be used. It should be pretty common-sensical. We should not make CiviCRM, LLC responsible for managing opt-outs -- users opt out from the maintainer's list.
- The new extension manager that Allen has been working on as an extension will house the user interfaces (and the corresponding logic to trigger the API call). At some point we'll need to discuss measuring its robustness and the path to shipping it with core. The default will be that an extension offers the relevant UI -- if a developer wishes to opt-out (e.g., because it's a one-off extension, or because the extension serves a particularly sensitive audience) we'll give them a hook or something.