Magazine startup concepts

gistfile1.txt

Infrastructure/application:
* We are using WordPress along with a selection of plugins (including Varnish cache)
* Different user levels -- administrator (all access including updates), editors (access to all content but not application stuff), authors (expanded access to owned content only), and contributors (limited access to create content)
* Login through Fedora OpenID Connect provider, to avoid spam/miscreants -- open access is definitely an extreme risk with WP!
Identify the audience fully
* We target users, and we specifically do not assume they are, or want to be, contributors
* Users are not just desktop; also sysadmins and developers who can use tools in Fedora
Magazine is the voice of the project
* Using it for the canonical source of community project announcements
* Determine "must nots"
   * For Fedora, this comes down to simple matters of contributory infringement
   * We made a specific determination to allow licit, nonfree software as long as the focus was on Fedora use (example: "Watch Netflix on Chrome on Fedora")
   * Avoid technically suspect advice; also, if we point to other articles like clickbait, make sure we are comfortable with the process they lay out
* Transition plan for making Magazine authoritative
   * Drive traffic through big announcements such as major release
   * Fedora carries Magazine feed in our Firefox start page -- could Ansible similarly use a channel or page users often see?
Seed the first months with content up front while gathering authors
* Biggest issue has been scaling the author pool
* It will limit growth if you don’t have a major part of someone's job to curate that pool, grow contribution, etc.
* This can be split between several people but someone has to be accountable for metrics
Set expectations for authors
* Define the content you want -- use web search intelligence to find out what the users want
* "Starter pitches" are a pool of content to be written; any entry should be writable by a new contributor
* Ask authors to OK their ideas with the editors before they start -- avoid unpublishable content, or content that ties up editors too much
* https://fedoramagazine.org/writing-an-article-for-the-fedora-magazine/
* Extra:
   * https://fedoramagazine.org/tips-for-articles/
   * https://fedoramagazine.org/writing-a-new-pitch/
   * https://fedoramagazine.org/how-to-structure-your-article/
Use built-in SEO tools -- Yoast SEO
Translation?
* Fedora Magazine is specifically not translated. Tools for this in Wordpress are fragile and don't connect well to FOSS tooling
* We treat the Magazine like other online news sites, not as a Fedora documentation center
Define the line between official documentation and Magazine content
* Not taking the place of encompassing guides or tutorials
* Highly focused use cases
* This starts to resemble some documentation models, so drawing that line is likely project-specific
Decoration
* Featured images are part of our custom theme
* Catches eye for CTA; also another route for contribution -- establish theme rules (size, limited # of fonts, template some backgrounds, etc.)
* Series will use identical or similar images for identification
   * https://fedoramagazine.org/series/systemd-series/
   * https://fedoramagazine.org/series/making-backups-on-fedora/
   * https://fedoramagazine.org/series/using-gnupg/ 
Publishing
* We use 0800 UTC as a baseline, hits every populated TZ during the daytime -- but not mandatory, can push any time
* Use either people or a plugin like Jetpack Publicize to connect social networks with a CTA post (note limited message space, ~100 characters)
* We publicize on Facebook, Twitter, Google+, sometimes Reddit, occasionally Instagram -- after Google search, biggest set of hits comes from Facebook