Closed bph closed 1 year ago
Mary Baum volunteered
@marybaum and @abhansnuk to collaborate on this async and on Thursday September 29, 2022 at 18:00 UTC. Google doc.
Our first step will be to identify sections for the information which will also help async collaboration. We will look for inspiration from other technical writing tips, and by incorporating learning from these, it will also help encourage a wider contribution of submissions.
The following approaches identified by @marybaum and @abhansnuk have been checked as correct for the dev blog with @bph. These will be incorporated into the page content. 1) Audience: Theme and plugin developers, web agencies, individual developers, developers advancing their web knowledge the blog will be a mixture of news, features / tutorials-type [not Learn WP level]. case studies, real world examples that bring more than one features together in a use case or tutorial. This is in line with the discussion on the name of the blog. - CONFIRMED. Action: Further work to confirm tutorials-type for Dev blog versus Learn WP materials, and where there can be overlap/ joint usage to avoid duplication of effort and maximize usage. @abhansnuk to discuss with training
2) Type of content (Incorporating above for ease and to expand as content ideas come in)
3) Authors' personalities/ opinion
Published: Tips and guidelines for writers Huge Thank you to Mary and Abha putting it together.
From the meeting notes:
From the proposal:
From the discussion, the consensus emerged that this new Developer blog is not just ‘more documentation’. Rather, it’s a place to talk to developers as people, first, and then as members of a community.
To that end, the group agreed that one of the first pages on the blog should be about writing for the blog—both in tone, from the above style guides, and with tips and tricks on how to write, so people will keep reading.
These examples might go on such a page (and drive its tone):
In an open-source environment, there is no imperial we’re making the decisions and doing the things. Specific people, or groups of people, might do things, and the code does things. Spell out who is driving the action.
Use active verbs; the way to get around using we is not to say a thing was done (by magic?), but to say that a person, group, function, or other piece of code does a thing. In a pinch, say a thing happened or got done; at least getting done is a little more active than being done.
Make the reader the star of the show. Walk in their shoes, and lead the way forward, to show what they’ll get from reading the next sentence, and the next, until they see the tangible benefits that come when they do what you recommend.
Look to the Documentation Style Guide for official terminology re: code examples, references to UI elements and technical instructions, so they stay consistent across the teams.
The training and marketing teams have published guidelines that can be screened to ensure consistency across the project.
For using screenshots within a post, this Best Practices for Capturing Screenshots will be a useful guide. Other assets like video, animated GIFs or presentation would need to covered as well.
The blog will also need a set of publishing standards to guide decisions on SEO, excerpt handling, subheaders, featured images, TL;DRs etc.