Originally discussed in 2016-10-11 meeting.
On the Marketing wiki, the Release activities is barren and can be expanded to be more comprehensive of activities the Marketing team performs each release.
I missed the original discussion about this between @bprofitt and @mailga, but it seems like the idea was that some of the links were broken in this part of the wiki (since fixed) and that the processes explaining what it is we do every release could be expanded to be more comprehensive. I think it would also be helpful for people interested in participating to see the steps broken down a bit further so they have an idea about where they could help and contribute.
As far as I can tell, this ticket is mostly wiki gardening.
@bproffit @linuxmodder @mailga I think the best next step for this ticket will be identify key tasks and responsibilities associated with the Marketing team, and then updating the wiki page with more descript versions of those tasks.
To help get some brainstorming going…
Perhaps we could use this as an opportunity to flesh out some of our other tasks, like the press kit, feature profiles, and other things (perhaps related to #232?).
Adding some links from the IRC meeting.
Ubuntu Marketing Resources: Community - http://spreadubuntu.neomenlo.org/ (resources created by the community) - https://wiki.ubuntu.com/LoCoTeamHowto (guide on how to run a local team) - https://wiki.ubuntu.com/BuildingCommunity/RunningReleasePary (running a release party) - https://wiki.ubuntu.com/LoCoComputerFairHowto (how to run a computer fair)
Canonical - CD/DVDs provided to approved local teams - https://wiki.ubuntu.com/LoCoGettingCds - Conference packs for community members representing Ubuntu at an event - https://wiki.ubuntu.com/UbuntuAtConferences - Ubuntu Funding Reports - https://community.ubuntu.com/help-information/funding/reports/
Discussed in 2017-02-07 meeting.
The current idea behind this ticket is to reevaluate what the Marketing team does or should be doing during a release, and then more clearly communicating that in a public place, like our main wiki page. The issue we have is that we haven't discussed or brainstormed this much yet.
@amsharma and @dhanesh95 were going to collaborate on researching the Mozilla marketing team / efforts to see what kind of work and activities they do for their release cycles, and then leaving a comment here to share what they find. @bproffit may also have some insight to share in some of his other roles in other FOSS projects, but I'm not sure. Thanks @cprofitt for adding in links to some of the Ubuntu side of things. I'll try to take a closer look this weekend.
I have started working on http://piratepad.be/p/rHoXbTwt17 . @jflory7 @dhanesh95 It will be great, if you can help me putting in more/better questions in the pad.
Also, @dhanesh95 if you know more people from mozilla marketing team, it will be great if you can share this pad link with them.
I don't know why but that pad is refusing to load on any of my browsers. Create a new pad maybe?
I don't know any more people but I'll try to make some friends. :grin:
I have started working on http://piratepad.be/p/rHoXbTwt17 . @jflory7 @dhanesh95 It will be great, if you can help me putting in more/better questions in the pad. I don't know why but that pad is refusing to load on any of my browsers. Create a new pad maybe? https://etherpad.net/p/EUYbfXuRGG - here you go :) Also, @dhanesh95 if you know more people from mozilla marketing team, it will be great if you can share this pad link with them. I don't know any more people but I'll try to make some friends. 😁 great idea :)
I don't know why but that pad is refusing to load on any of my browsers. Create a new pad maybe? https://etherpad.net/p/EUYbfXuRGG - here you go :)
I don't know any more people but I'll try to make some friends. 😁 great idea :)
This is something OSAS put together a couple years ago. It was meant to be used as a template for any software project.
One of the major functions of any open source project is releasing software, with the goal of reaching as many users as possible. To help our projects succeed, we need to ensure that we get the message out in a timely fashion, to the widest relevant audience, and with the right information.
With that in mind, we've crafted a set of guidelines for coordinating release announcements to ensure that your excellent work doesn't get lost in the shuffle. Remember that these are only guides; you own community practices can be different.
No less than three weeks from release date: * Create a collaborative document (Etherpad, Google Doc) to include highlighted features for the release announcement, press release, and blog.
Two weeks from release date: Generate a changelog that includes notable changes to the release that will need to be documented and included within the main changelog file. Merge any relevant content from the updated changelog into the release announcement, press release, and blog. * Create press release and send to PR for vesting
One week from release date: * Have social media content in place for scheduled/live distribution before, during, and after release date.
Three days from release date: Release manager, engineering lead sign off on release announcement and blog PR signs off on press release
Two days from release date: All final QA/smoke tests should be completed. Build should be placed on appropriate servers.
One day before release date: * Relevant media outlets should be sent copy of press release.
Day of release: Code should be made visible to outside world. Release announcement, social media, and blog should be published as scheduled. * Press release should be posted on newswires via PR.
No less than 2 weeks from release date: * Create a collaborative document (Etherpad, Google Doc) to include highlighted features for the release announcement and blog.
One week from release date: Have social media content in place for scheduled/live distribution before, during, and after release date. Generate a changelog that includes notable changes to the release that will need to be documented and included within the main changelog file. * Merge any relevant content from the updated changelog into the release announcement and blog.
Two days from release date: Release manager, engineering lead sign off on release announcement and blog. All final QA/smoke tests should be completed. * Build should be placed on appropriate servers.
Day of release: Code should be made visible to outside world. Release announcement, social media, and blog should be published. * Relevant media outlets should be sent copy of release announcement.
No less than one week from release date: Have social media content in place for scheduled/live distribution before, during, and after release date. Generate a changelog that includes notable changes to the release that will need to be documented and included within the main changelog file. * Merge any relevant content from the updated changelog into a release announcement.
Two days from release date: Release manager, engineering lead sign off on release announcement. All final QA/smoke tests should be completed. * Build should be placed on appropriate servers.
Day of release: Release artifacts should be made visible to outside world, if they are not already. (It's okay if a release is synced to mirrors ahead of the actual release announcement.) Release announcement and social media should be published.
Pushing out a release announcement would seem to be relatively straightforward, but in order to get the most impact from your announcement, it should be written in a way that's going to be most likely to be picked up by the media.
Here, then, is a template for a release announcement, with some guidelines. Please note, this is a guide only, and boilerplating exactly what we have here may not be effective for your project.
Be matter-of-factual about information shared in public statements. Avoid hyperbole ("the bestest project ever made!!!" and speculation ("the only project that can do this"). As tempting as it is, release announcements should not opportunities to hype your project. You can take the opportunity to thank your hard-working community, however; this not only gives credit where credit is due, but also emphasizes the free and open source nature of the project. Media outlets will rapidly disregard such hyperbole and possible avoid spreading the word about your release altogether.
Be clear, concise, and use facts and supportable information. This will help get your announcement more broadly disseminated.
--
Project X, the [main purpose of project: goals, functions, governance...] project, today announced the general availability of Project X x.y, a community-driven [description of project]. This latest community release includes several new features, including [list of newest features].
Developed by a global community, Project X [a detailed paragraph of what the project is, what it does, and any other pertinent information should be included here.]
Notable enhancements to Project X x.y include: [Detailed paragraph describing a first major feature] [Detailed paragraph describing a second major feature] [Detailed paragraph describing a third major feature]
A complete list of Project X x.y features is available on the Project X community release announcement page [URL]. Project X x.y [detailed description of a two or three additional features].
[If possible, add a quote from a prominent community member or technical lead about the new release here.]
Additional Resources Read more about the Project X x.y release highlights [URL] Get more Project X updates on Twitter [URL] Read more about Project X community events [URL]
About Project X Project X is [a very detailed description of what the project is and what it can do].
@bproffit++ Thanks for this comment!! This is a lot of helpful info to have… we should try to get it into somewhere static. :thumbsup:
I talked with @amsharma before the meeting and got a quick update from here. The current Etherpad can be found here with the raw notes, since the Piratepad appears to have issues.
To summarize…
Press kits usually have the following materials within them. They are typically remixes of existing marketing materials/deliverables.
Press kits were usually delivered in hard copy format. For efficiency and speed, it is suggested that PDF and ISO files be placed in a zip file that can either be emailed to press as needed, or placed on bootable USB sticks to be handed out at events.
Discussed in 2017-02-21 meeting.
Using a public git forge or public platform for the press kit is a good way to promote our content and encourage community contributions, while also making sure our work and content is easily findable and revisable.
One general part of our discussion was about using a public git forge for our marketing activities to hold our content. The benefit of this is that:
More verbose discussion in the meeting minutes, but here's a bulletpoint list of what we did discuss.
Discussed in 2017-02-28 meeting.
To break up what this press kit looks like, we tasked a few people to write a simple description or idea of what these things look like into this ticket. Then, we can port this over to a wiki page later and also try working on the first version to include in our press kit for this release. @ankursinha and @bproffit were going to discuss one-page release announcement, and @ankursinha was going to leave a comment answering questions about:
My action was for background modules and past press coverage, which I have below. Note that these are suggestions that we will discuss and vote on at our next meeting.
I see this information being most helpful for outward sources reporting on the Fedora Project. This would consist of news sites, media outlets, other Linux newsy sites, etc. Ideally, this information would be compiled once, and then along with each annual update, the numbers would be adjusted and updated as needed. This would likely be around Flock, when the FPL gives the State of Fedora talk.
Therefore, I see this best being a Markdown file in the press kit that we could convert to a PDF for delivery or sharing with media sites. We could communicate this somewhere between Beta and GA.
To me, it's unclear whether this is best used internally or externally. Clarifying this would be helpful to understand what we want to do for generating this document and how we deliver it. However, since we're already doing this roughly every meeting with the "In the news" announcements, it would be easy enough to sort this data from the meeting logs into a Markdown file inside of the press kit repository. We could do whatever we want with it after.
I definitely want to understand better why this document is important or what its role in a press kit would be. Is it helpful for other news outlets to see what other sites are writing about Fedora? Could this potentially bias them (positively or negatively)? An experienced marketeer's opinion would be helpful here. :grinning:
Discussed in 2017-03-07 meeting.
Since we have the talking points and Marketing presentation to the Council in two weeks, @x3mboy and I decided to table this ticket until after March 21st until we get these other two, higher priority tasks done.
@ankur1989 / @bproffit, if you can both wrap on your action item, we can pick this up when we revisit this topic! Thanks. :thumbsup:
Metadata Update from @jflory7: - Issue untagged with: meeting - Issue priority set to: 30 (was: 10)
Metadata Update from @jflory7: - Issue assigned to jflory7
As our focus is changing because of Mindshare, I will close this ticket and will use the number as reference for both, Mindshare Committee and Marketing team
Metadata Update from @x3mboy: - Issue set to the milestone: None (was: Fedora 26)
Metadata Update from @x3mboy: - Issue close_status updated to: Moved - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.