RFC-011: news announcements #29
Conversation
ryanmacklin
requested review from
flicstar,
bwklein,
carriecrowe1138 and
barbaricyawps
|
In general, this seems like a good idea and I'm tentatively in favor of it. I have a couple of questions and comments: Question 1: User stories
Am I right that Casey (or something similar) is the kind of persona you'd be targeting here and the use case is that someone who just wants to keep tabs on the project because they might be an interested user of the project's output down the road? Are there any other additional use cases? What are the larger benefits and impacts to the project and to our community? Question 2: Technical feature requirements Question 3: Press page This page is not terribly well-maintained and I'm slightly unclear what purpose that press page serves. Would your news page replace this content? Supplement this content? Concern 1: Team/project bandwidth My concern is around the project bandwidth for the News Team. You mentioned that this will be a separate team from the Blog team and from the Content Strategy team. I'm concerned about spinning up another workgroup/meeting cadence, especially when a lot of the people who would likely make up the News Team would overlap with the Blog WG and the Content Strategy WG. Can you estimate what the level of effort will be required for this project and its relationship to those other working groups? Would it maybe be instead possible to fold this work into the Content Strategy group? If so, would that team feel confident they could take this initiative on? Concern 2: Conflicting dependencies on future Content Strategy decisions Praise |
That's the most significant persona to target, one that I feel will have spikes at WTD (and eventually other) conferences, as their interest in the project in general could draw them to a news post either from looking over the site, or from looking our Twitter etc. So I'd say we have the variant of Casey we're addressing: "Just-Found-Out-About-the-Project Justine."
That seems like a disorganized list of links where people have talked about the project elsewhere—more like a CV than something useful. I recommend scrapping that. We can repurpose individual elements as needed, but it doesn't seem to really give Casual Casey any genuine direction.
Overall: This could live within the blog team & social media team (which already has overlap), especially if the archtecture was similar enough. It's my understandig that the content strategy team would end up dissolving effectively once the strategy is figured out and implemented. Re meetings: News would be done as-needed, rather than the blog's goal of periodic content (albeit now less frequent than the prior ambition). If someone needs something posted, like we're having an upcoming release or want to announce a talk by a community member, that spins up an ask. No need for a separate proactive, always-on group. The effort level after site instantiation would be small, a few posts a year. We don't want to overwhelm people with "not really news," and want to make it easy for people to find prior-but-still-relevant news posts.
Whatever work is being done regarding Hugo shifts and implementations should definitely block this work. If this idea overall has merit enough to pass, but needs other strategy/tech decisions and implementations to happen, then we hold off on implementing this until then. (And allow this to factor into such architectural planning.) |
|
Thanks for writing this up @ryanmacklin. I'm all in on this 💯 I don't want to over-engineer it. Do we really need RSS? Do we need newsletter subscription? I don't think so. Maybe Q4 next year when we're really releasing stuff folk might actually want to be informed (via push) about what we're doing. Of course, let's make wise decisions now to be future-proof, but I wouldn't want to slow implementation of this because we're faffing with fancy stuff we don't need. We're not so heavy on news yet that we need to adjust our currently manual tweeting. I see writing news as very similar to blog posts, so in terms of effort, no big deal. Since we're slowing the blog at the moment, and focussing on project news, it makes total sense to write some news for a while. I am also personally keen to do advocacy for the project (talk about it publicly), and having news to point to works in really well for that. |
|
|
||
| The sidebar would have the most recent 5 or so posts, with a "see all" that would just show a list with short versions, akin to what is seen in the [Write the Docs newsletter archive page](https://www.writethedocs.org/blog/archive/tag/newsletter/). | ||
|
|
||
| The posts should be short: 500 words or so. Something that would take on average less than 5 minutes to read. We may deviate from this as needed, but the core concept is that our newsletters shouldn't take significant resources to craft and review, and we shouldn't demand significant time expenses from our audience in this manner. |
There was a problem hiding this comment.
I'm starting to think of a micro-blogging format, or something with a significantly reduced character count. Like the newest Tweet length (280 chars) on Twitter. Enough to give a quick update about something and then link to more information, etc. One advantage of using a shorter char count would be the ability to take the syndication feed from these posts and automatically send them out to channels on Twitter, Facebook, etc., without rewriting them to fit.
There was a problem hiding this comment.
I'd like it to not be that stringent. If the news has needs beyond micro-blogging, like (and hopefully this never happens) a public apology for a key member's conduct, we should make sure we can support that.
There was a problem hiding this comment.
I don't think it need some kind of hard coded limit, but I would think that the use of this 'news' stream is for small, quick 'pings' of information from the team to remind people we are doing things and bring them up to speed. If we go over 280 chars, the content cannot be 'retweeted' so to speak without a bit of manual rewrite or truncation.
|
|
||
| Unlike how we handle the blog, authors wouldn't link to "about the author" pages as we do in the blog—and in fact we may decide there are no listed individual authors, to keep the news to appear to always be from the community. | ||
|
|
||
| Unlike how we handle the blog, there wouldn't be any commenting feature. |
There was a problem hiding this comment.
But we can add some buttons to make it easy for people to share the posts on their own social media channels as needed.
|
|
||
| Unlike how we handle the blog, there wouldn't be any commenting feature. | ||
|
|
||
| Unlike how we handle the blog, there wouldn't be any banner or hero images. |
There was a problem hiding this comment.
I'm thinking of something small like twitter cards for the layout.
There was a problem hiding this comment.
One thing to consider: we could have a V1 and V2 plan, with the V2 being "fancier" as we end up feeling out this in practice, and V1 being what the CS team feel comfortable with when the new site is launched
There was a problem hiding this comment.
One of the drafts I've seen from CS (seen today) has Twitter on the sidebar, so we might not want to use the same layout for two different elements. Though there are plenty of ways to implement "Twitter-like" that looks significantly different.
There was a problem hiding this comment.
Yeah, the styles can be different, while conceptually the same. Small bits of information to inform viewers of project activities. With some clear visual separation from one to another.
|
|
||
| Unlike how we handle the blog, there wouldn't be any banner or hero images. | ||
|
|
||
| Because news is timely, the individual post URLs would use the date rather than a title. |
There was a problem hiding this comment.
This would not allow more than 1 post a day, unless we also add the time to the url. We could just generate an ISO datetime string for the slug. ISO datetime would probably be easiest and would provide some information in the string that would mean something about when the post was created.
There was a problem hiding this comment.
That's a good point!
Ideally we don't want more than one news post a day, but to my earlier point about the potential need for a public apology (or something like an emergency rollback or whatever, should we for some reason need that—like if we get into doc tooling), we should make sure we can support multiple posts per day.
Better to support and never need than kick ourselves for not having it, right? As long as it doesn't turn into overengineering. (I'm okay to engineer for contingencies we need to support as the org grows, as long as they're reasonable to consider, and it's less costly to implement them now than later.)
There was a problem hiding this comment.
We have to name the files something, might as well be a date/time code if we aren't using text slugs.
There was a problem hiding this comment.
There's probably other valid reasons for multiple posts per day, e.g. what we're doing/have done during WTD conferences. I'd argue that just appending a "-2" or similar would be sufficient, but using a timestamp works too.
|
|
||
| Two reasons: First, it would split the purpose and publishing resources of the blog. The blog's purpose is supporting docs advocacy and education. | ||
|
|
||
| Second, while the framework might be similar, it isn't exactly the same. So we can reuse a lot of the work on the blog, but it has different content needs. |
There was a problem hiding this comment.
I see a different 'content type' for the markdown files, and new layouts for this section of the site. Something like a 'twitter feed' with a card for each one.
There was a problem hiding this comment.
Totally. I'll leave the markdown implementation as a post-RFC phase, since I'm sure like with the blog, we'll discover nuances as we build it out. But I'm def picking up what you're putting down.
|
|
||
| ### Forward facing: emailing newsletters | ||
|
|
||
| If we want to get to a point of having a mailing list to keep our users informed, this is the content we'd use. And by having two categories, people could opt into different types of content. However, that isn't a requirement to execute on this idea. |
There was a problem hiding this comment.
We could also and probably should syndicate this to an RSS/Atom feed.
There was a problem hiding this comment.
What's the time cost of that? And does the time cost change if we decide that's a "1.1" version of news?
There was a problem hiding this comment.
It isn't much more time or effort, much easier than setting up a new content section and layouts for the website.
|
|
||
| This allows us a space to write about upcoming changes for users to experiment with (such as if we start playing in the space of having "dev branches"), announcements for recruiting, celebrating our contributors' efforts elsewhere (like announcing them being Write the Docs speakers), and upcoming meetups (like holding writing days at Write the Docs). | ||
|
|
||
| This would be an additional effort set for the Tech Team, to take the blog and tweak it for another subfolder. That might involve refactoring material to be shared, or not—details on the code execution part of this effort is beyond the scope of the RFC, barring noting any concerns, issues, or plans that the Tech Team might share upon reviewing this. |
There was a problem hiding this comment.
Adding a new content type section or data file would be fairly simple, and making new layouts for the pages and content is fairly straightforward.
There was a problem hiding this comment.
Yay! I figured that was the case, since my initial experience with Hugo working on the blog with you. I'm very thankful you commented to confirm that! :D
| ## Open questions | ||
|
|
||
| {This section is optional and is where you can list questions that won't be resolved by this RFC, including those raised in comments from community members.} | ||
|
|
There was a problem hiding this comment.
Would this be text/links only, or allow for media assets like images, videos, embeds, etc.?
There was a problem hiding this comment.
Let's assume embeds, and have some guidelines for what those embeds should look like/size of them/etc.
But turning that around: what logistics do we need to consider on the tech side for that? (I believe I know, but I'd rather get specifics from you than silently assume)
There was a problem hiding this comment.
There are some built in Hugo shortcodes that could come in handy here. https://gohugo.io/content-management/shortcodes/#use-hugos-built-in-shortcodes
| - [ ] Set up the site folder | ||
| - [ ] Document process for posting | ||
| - [ ] Document the subsite's purpose and content guidelines | ||
|
|
There was a problem hiding this comment.
Define a new 'content type' that would have the necessary data structure for this kind of information object.
There was a problem hiding this comment.
I'll make a task category of "technical implementations" and add this (and move "set up folder" etc.) in that. And make "Create process" as a task category.
| - Aaron Peters: | ||
| - Alyssa Rock: | ||
| - Ankita Tripathi: | ||
| - Bryan Klein: |
|
This is excellent and seems like we are on the same track. Happy to provide more details soon. |
|
I'll make a note splitting "content" and "presentation." I'll detail a bit more about the intended content/make sure it's easy to parse, and flag "presentation" as a Content Strategy decision to defer, since it sounds like we could use flexibility in their presentation models. |
|
Per conversations in today's CS meeting: it sounds like the CS team will handle news & social media for the time being, |
|
|
||
| ### Types of content | ||
|
|
||
| The news site would handle two types of content: announcements and heartbeats. |
There was a problem hiding this comment.
I agree with these types of content.
|
|
||
| Heartbeats could also possibly showcase an individual contributor, like a "meet the team" sort of vibe. This has been declined as a blog post topic, as that doesn't fit the purpose of the blog, but it could fit here at the tail end of heartbeat posts. | ||
|
|
||
| (That also gives those individual contributors featured a different sort of call to action on publicizing their related post, as friends/colleagues of that contributor may be interest in the post for relationship reasons, then find the other content or project in general interesting enough to follow on its own.) |
There was a problem hiding this comment.
I love the social engineering aspect hehe.
|
|
||
| ### Why not use the blog? | ||
|
|
||
| The blog is about "docs advocacy & education," so if peopple subscribe to the blog/look out for new posts, they should expect material that's education, not that's purely about our group marketing. |
There was a problem hiding this comment.
| The blog is about "docs advocacy & education," so if peopple subscribe to the blog/look out for new posts, they should expect material that's education, not that's purely about our group marketing. | |
| The blog is about "docs advocacy & education," so if people subscribe to the blog/look out for new posts, they should expect material that's education, not that's purely about our group marketing. |
|
|
||
| ### Specifics | ||
|
|
||
| The main page should show the most recent post, so when one clicks on "News" in the header, they don't have to click on a second link to see what's the most recent. |
There was a problem hiding this comment.
I agree with this sort of implementation.
For reference, this is how our implementation could look like:
You can check it out at Netdata Documentation
|
|
||
| ### "Creating" the News Team | ||
|
|
||
| The team that would handle this would be the "News team," and essentially be our PR team. But functionally, that doesn't end up being a new team, as we already have a de facto PR team between those who run our social media (namely Felicity and Carrie), people planning Content Strategy, and the co-chairs. |
There was a problem hiding this comment.
+1 on Alyssa's comments here.
| - Morgan Craft: | ||
| - Nelson Guya: | ||
| - Ryan Macklin: | ||
| - Tina Lüdtke: |
|
|
||
| ### Why not use the blog? | ||
|
|
||
| The blog is about "docs advocacy & education," so if peopple subscribe to the blog/look out for new posts, they should expect material that's education, not that's purely about our group marketing. |
|
|
||
| The posts should be short: 500 words or so. Something that would take on average less than 5 minutes to read. We may deviate from this as needed, but the core concept is that our newsletters shouldn't take significant resources to craft and review, and we shouldn't demand significant time expenses from our audience in this manner. | ||
|
|
||
| Unlike how we handle the blog, authors wouldn't link to "about the author" pages as we do in the blog—and in fact we may decide there are no listed individual authors, to keep the news to appear to always be from the community. |
There was a problem hiding this comment.
This follows, I don't think there's a compelling reason to attach authors to these items, and them coming from the "community at large" has some benefits.
| {This section is optional and is where you can list questions that won't be resolved by this RFC, including those raised in comments from community members.} | ||
|
|
||
|
|
||
| ## Decisions deferred |
There was a problem hiding this comment.
I feel like the first three bullet points below are in fact the "next steps" rather than "deferred decisions." It's an arbitrary distinction, but these are things that need to be addressed in order to take the implementation described in an approved RFC into production.
|
Praise: I don't feel strongly about this, but am tentatively supportive if we have volunteers wanting to drive this. Suggest call out a couple of extra risks:
Praise: I like the micro-content suggestion. |
|
Just adding my +1 on this. |
Note to RFC reviewers
This pull request description is not the actual RFC. To view the actual RFC, click Files changed in the top menu for this pull request.
NOTE: We recommend reading the files in their rendered format rather than their raw format.
Current RFC status