Security Releases - Update post-release communications workflow
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 feedscivicrm.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
andrelease-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
-
Team organization
- There is a private MM group for people involved with release communications.
- Rename the current
mergers
group toreleasers
orrelease-team
or somesuch -- since this is a more accurate reflection of how the group works. - 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. - The MM channel has sticky link at the top to the wiki page.
-
For post-release communications, the workflow goes as follows:
- Tarball and tag information goes up to
download.civicrm.org
,sf.net
,latest.civicrm.org
. The release is live. - The person who uploads then sends a notification to all
releasers
that the release is live. - Each person who signed up for release-comm's gets the ping and does thing their thing.
- Tarball and tag information goes up to
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