Birgit Pauli-Haack 6:37 pm on September 19, 2022
Tags:   

Developer Blog Editorial Group – Meeting Notes September 1, 2022

Attendees: @marybaum, @daisyo, @milana_cap, @psykro, @webcommsat, @mburridge, @bcworkz, and @bph

Agenda

  • Introductions
  • Editorial Guidelines (from this proposal)
  • Infrastructure of the Developer Blogblog (versus network, site) 
  • Project / Issues tracking
  • Review process
  • Tasks & Posts left to go live

Editorial Guidelines for Writers and Reviewers

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 UIUI User interface 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, excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. handling, subheaders, featured images, TL;DRs etc. 

As the group builds the GoLive edition, it will have to handle these things for the first time; later iterations can influence long-term policy.

Authorship 

The proposal said: “Posts should be published by users of WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, with the author link going to the WP Profile page. Authors should also credit reviewers, editors, and other contributors.” 

Participants agreed to clarify that the author link should go to a contributor’s personal WP.org profile and not a company’s profile. That follows how the training team handles authorship. 

Original content and republishing  

Participants discussed concerns of plagiarism and how to detect it. It was suggested during a still to be finalized submission process, the author will give assurance that its original content. Another suggestion is to include this topic in a future reviewer’s checklist, but to avoid it becoming a difficult task with the onus being on checking the author had self-verified it as original content. In the longer-term future, blockchain technology may be able to assist. 

Infrastructure for the Developer Blog

  • The Developer Blog site is on the way to have final design and information architecture for GoLive. It is only accessible to the contributors working on it. 
  • Asynchronous discussions and announcements take place in the new WP SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel #core-dev-blog
  • The public GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ space Developer Blog Content tracks content tasks, which already has an initial set of labels and stages. That set is bound to grow as the team adds content categories and issue types. A separate Discussion space can host ideas for blog posts, relevant conversations and even final outlines before a given idea becomes an actual task on the issue list. 
  • This project board will show content as it progresses from concept to published posts
  • The Theme’s code also lives on GitHub. The MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. Team owns it, just as it does the rest of WP.org. 

Birgit will add editorial group members to the site and GitHub spaces in the following weeks and message them on WP Slack. 

The Review process is roughly as outlined in the proposal.  With the GitHub tools it can come to life. 

Once the first set of posts go through the process, the editorial group will likely have tweaks to make to the formal guidelines. 

Task list to Go live 

  • A great set of first posts. 
    • Three ideas
      • Business case for create-blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. script adoption
      • Perspective Change between classic themes + Block Themes
      • Journey of a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher developer to GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ adoption, enhancing Core blocks and building custom blocks.
    • Meeting leaders asked participants to think about additional ideas, and also mention it to other contributors and members of the community, on what is particularly missing.  
  • Review collected posts by the editorial group
  • Draft more content areas for the following blog pages, and share with the group to help start building:
    • About page
    • How to get involved
    • Editorial Guidelines
  • Finish setting up the website 

Tasks will go on the issues list for collaboration and version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories.. 

Future meetings

The next meeting will be October 6, 2022, at 13:00 UTC / 9 am EDT 

Initially, meetings will be once a month on the 1st Thursday of the month. 

  • November 3rd at 13:00 UTC / 9 am EDT
  • December 1st at 13:00 UTC / 9 am EDT

Props for review: @webcommsat @mburridge @jeffpaul 

#core-dev-blog