GitLab

Synopsis: When a new security release goes out, one may wish to notify as many users as possible. This requires communications across several different media. The aim of this issue is to define a smoother workflow for improved consistency.

Target Media:

The communications about a recent release may hit the following media:

• chat.civicrm.org (public groups) - "Town square", "dev", "product-maintenance"
• chat.civicrm.org (private groups) - "security", "ESR", "mergers"
• latest.civicrm.org - Versions listing (which feeds civicrm.org/download and in-app notices)
• sourceforge.net - Default download
• civicrm.org - Security advisories
• civicrm.org - Blog
• civicrm.org - "Security Notifications" mailing list
• twitter.com - @civicrm account
• facebook.com - CiviCRM group

Considerations:

• The broad communications for monthly-releases and security-releases are similar, but security-releases have the higher bar because they are more urgent, leading to more time-sensitivity and a longer list of media. Consequently, if we solve security-releases, then our monthly-releases can follow a simpler subset of the workflow.
• The list of media has tended to grow over time.
• The people who post to each medium has varied overtime.
• The knowledge/access of posting in different media are spread among different people.
• The best documents to refer people to are generally (a) the blog article and/or (b) the release-notes.
• The document any-announce.md proscribes some particular steps. It is slightly out-of-date, and includes a range of tasks which have (for at least... 5 years?) been split among different people.
• Today, the emotional experience of getting announcements is a bit like this: You sign up for 3 channels, and then you don't see a notice on whichever one is your favorite, and someone tells you that you need to signup for more.
• Today, the emotional experience of sending announcements is a bit like this: You post a message to 5 channels, and then someone says that you didn't post to a 6th channel that you don't personally use.
• It is conceivable to use a smaller list of feeds (like latest.civicrm.org and release-notes) to populate more channels automatically. This would require case-by-case technical implementation. Alternatively, for media where automation has poor cost/benefit, we can have a person responsible for each medium. This would likely create some lag (b/c it's hard to precisely coordinate timing across multiple continents). Any style of contribution (automating a medium or standing sentry for a medium) is useful.

Proposal 1️⃣:

1. Team organization

   1. There is a private MM group for people involved with release communications.
   2. Rename the current mergers group to releasers or release-team or somesuch -- since this is a more accurate reflection of how the group works.
   3. In the the GL project dev/release, add a wiki page with a list of media and the party responsible for each medium. Anyone added to this list must also be added to MM.
   4. The MM channel has sticky link at the top to the wiki page.

2. For post-release communications, the workflow goes as follows:

   1. Tarball and tag information goes up to download.civicrm.org, sf.net, latest.civicrm.org. The release is live.
   2. The person who uploads then sends a notification to all releasers that the release is live.
   3. Each person who signed up for release-comm's gets the ping and does thing their thing.

Meta

• If additional proposals are made, please give them an identifying code; and, if possible, include a summary in the description of this issue.
• Related: Security Releases - Update pre-release communications workflow