WordPress Documentation Team to Host Its First Online Contributor Day, October 25, 2022

WordPress’ Documentation Team will be hosting an online Contributor Day on October 25, 2022, ahead of WordPress’ anticipated 6.1 release the following week. Milana Cap, who has been volunteering with the Documentation team for years and is currently sponsored by XWP, announced the event this week.

“The primary goal is to catch up with a lot of tasks in the team’s backlog but also it’s an opportunity for all contributors to meet, collaborate in real time, and help onboard all new contributors who need any kind of help,” Cap said.

The virtual event will be the first of its kind for the Documentation team but follows in the footsteps of other contributors teams, including the Polyglots and Accessibility teams, which have hosted wildly successful global events that include contribution and onboarding. These types of virtual gatherings help contributors get connected and put names to faces

New contributors are encouraged to attend, even if it’s just for a short time to see what documentation contribution is all about. Cap requested everyone who plans to attend to leave their names on the GitHub issue dedicated to the Contributor Day. It outlines the steps to begin contributing and highlights a list of tickets awaiting content review for older documentation as well as more recent block editor and end user documentation tickets. For example, there is a project board specifically for high priority tickets remaining for 6.1.

The Documentation team will be kicking off the event on Tuesday, October 25, 2022 at 06:00 AM EDT and it will run for 10 hours. Attendees can join via Zoom and are not required to stay for any length of time.

Easily Format Markdown Files in VS Code

Every respectable software project needs a README. This file provides crucial information about what the project is, how to work with it, and other relevant information for developers. README files are written in markdown, a special markup syntax. The syntax for markdown is simple enough, but it can be a pain to manually type out, and it’s easy to make simple mistakes and typos.

Wouldn’t you like to just use the Cmd+B keyboard shortcut to bold some text instead of typing ** around your text? Or what about creating a nicely formatted table in your README, especially when editing an existing table? Wouldn’t it be nice if the table formatting and column width adjustments were taken care of for us? Markdown is wonderful, but it’s not exactly as easy as working with a Google doc when applying formatting.

How to Write a Software Requirements Specification (SRS) Document

There are plenty of horror stories about outsourced software developers and clients clashing on project requirements, and one of the most common causes of such quarrels is ambiguous language. Vague terms like "urgent," "pending," "ASAP," and so on might mean something different to the client and to the contractor. Or, perhaps, the involved parties have a different impression of the product's prioritized functionalities. It's neither party's fault, per se — they are just speaking different languages, in a sense. The customer has an idea for the product, its functions, and what the user interface might look like. 

But the developers are thinking about the "behind-the-scenes" of the project, how to write a scalable and readable code, ensure security, make a solution performant, minimize bugs, etc. When there is a disconnect between both viewpoints, it can lead to extra work, wasted money, stress, and even a sub-par final product. But, thankfully, there's a way to avoid such miscommunications from the get-go: Software Requirements Specifications.

The Principle Behind the Practice

There are principles and there are practices. A principle is a universal truth that is applicable everywhere. A practice is a specific implementation of a principle and can vary based on the situation.

Understanding the difference between the two is an important step in becoming wise. When you understand the principle behind the practice, you understand why we do the things we do. You understand the rules and also when to break the rules. Understanding the principle behind the practice helps you to be more flexible and apply good judgment in your day-to-day decisions.

Software Engineering Best Practices That High-Performing Teams Follow

Maybe you're a newbie dev, in a coding academy, or newly graduated. Or perhaps you're old and cynical like me. The reality is, tech moves fast, and it's easy to get distracted by the latest software, tool, or trend.

But while you're floating in YouTube videos, Reddit boards, and StackOverflow, we've got something to keep you anchored: the good coding practices in software engineering. I've deliberately approached this article with broad strokes to move a little beyond the typical laundry list. Let's take a look at the software engineering best practices that high-performing teams follow.

Five Ways Developers Can Help SREs

It is not easy to be a Site Reliability Engineer (SRE). Monitoring system infrastructure and aligning it with the key reliability metrics is quite a daunting task. Whereas, a software engineer's job is to deliver high-quality software.

Relationships between software engineers and site reliability engineers can sometimes be tricky. To begin with, developers are generally assigned to write code that goes into production. Then, there are SREs who are responsible for improving the product's reliability and performance. 

How to Write Self-Documented Code With Low Cognitive Complexity

In this article, I will share practical and straightforward advice on how to stop (holy wars) arguing about code quality and find measurable arguments about the necessity of refactoring, simplification, adding comments or documentation for the code. While I’m going to refer to exact commercial tools in the second half of the article, I should say that I’m not affiliated anyhow with the tool's authors. The tools are available via free community licenses as well as commercial licenses.

The goal of this article is not the tool itself but to tell you about useful metrics that will allow your team to write self-documented code, produce better software and improve the programmer's life.

How to Use GitBook for Technical Documentation

For the past three months, I have had the distinct pleasure of working as an intern for an open-source project called Intermine, where I was tasked with creating new user training documentation. For this project, I entirely rewrote the Intermine user documentation — which included images, code snippets, tables, mathematical formulas, and more — using GitBook. This guide will share my experience creating technical documentation using GitBook and act as a de-facto quick-start guide to GitBook.

What is GitBook?

GitBook is a collaborative documentation tool that allows anyone to document anything—such as products and APIs—and share knowledge through a user-friendly online platform. According to GitBook, “GitBook is a flexible platform for all kinds of content and collaboration.” It provides a single unified workspace for different users to create, manage and share content without using multiple tools. For example:

The Engineer’s Complete Guide to Code Quality

You might not realize it, but you probably know when you see bad quality code. It might be written in a way that doesn't make sense, be full of errors, excessively verbose, or highly inconsistent in its use of terminology and naming conventions. Fortunately, there are lots of ways you can improve your code quality, make it easier to review and test and reduce the pain later of having to fix all of the errors. Let's take a look.

The Basics of Code Quality

Code quality refers to the attributes and characteristics of your code. These may differ according to your organization's specific business focus and the particular needs of your team. While there's no definitive checklist, there are broadly several things that separate good quality code from poor quality.

Open Source: What, Why, How?

What comes to your mind when you hear the words open source?

I read about it and tried to understand the subject more closely. My research on the topic led me to many articles that described open source as source code that is made available to the public to view, use, modify, and distribute under a license. 'License' here is the key word; insight on how licenses work will follow soon.

Open Web Docs

Robert Nyman:

Open Web Docs was created to ensure the long-term health of web platform documentation on de facto standard resources like MDN Web Docs, independently of any single vendor or organization. Through full-time staff, community management, and our network of partner organizations, we enable these resources to better maintain and sustain documentation of core web platform technologies. Rather than create new documentation sites, Open Web Docs is committed to improving existing platforms through our contributions. 

Well that’s… awesome. I know a lot of people were worried about the long-term health of MDN after the Mozilla layoffs, even though they have made some strong moves.

But wait, hasn’t this been tried before with Web Platform Docs? There is a big difference:

Q: Is this the same as Web Platform Docs was?

A: No, Web Platform Docs was a new documentation platform, whereas this is aimed at contributing to existing platforms.

Working through my mental checklist of things I would think this needs to succeed… does it have leadership? Does it have a plan? ✅

Florian Scholz joined the project in November 2020 as our Content Lead, working with stakeholders to define initial workstreams. Our 2021 priorities include working with Mozilla’s MDN writers and engineers to support the recent infrastructure transition and to prioritize and move forward with key documentation work, developing a community of contributors around core web technology documentation, browser compatibility data, and improving JavaScript documentation.

Does it have a team? ✅ Looks like 11 already and new hiring is happening.

Does it have money? ✅

That’s a good chunk of change, and covers that whole first year’s budget (Nov-Nov). Here’s hoping the big contributors keep that contribution up annually. But even if they don’t, I imagine a ton of good will come from just one year of this much focus and investment.

Direct Link to ArticlePermalink


The post Open Web Docs appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

How to Be a Terrible Project Maintainer

Hey, you! Yeah, you. Are you a software engineer? Do you have ownership over a particular repository at your company? Do you want to ensure that working with your repo is a constant source of frustration for your fellow developers? Great! Then read on for these tips on how to be a terrible project maintainer.

Don't Write Good Documentation

Especially on how to do local development or how to contribute to the repo. You want to keep people guessing. Running your project locally should be a puzzle that only the greatest minds can solve. If you want to be even more cryptic, consider including outdated or incorrect instructions that reference non-existent scripts meant to run the app.

WordPress Documentation Team Discusses Modifying External Linking Policy Following Opposition to the Ban on Commercial Links

Last month the WordPress Documentation Team announced a ban on links to commercial websites within the official docs. These include the HelpHubCode ReferencePlugin and Theme Developer Handbooks, Block Editor Handbook, and the Common APIs Handbook. The reason behind the ban was that heavily policing commercial links placed too much responsibility on the documentation team, when they are already working with limited time and resources.

The decision was instantly controversial, igniting a heated discussion in the comments. A blanket ban on links to commercial sites, without a clear outline of what that includes, was confusing.

“There isn’t clarity what will/won’t be allowed, you state that the rules are expected to change in the future (more lax after some trial and error), and end users lose in the end as a result of excluding actually helpful information because it’s free but at a domain that has non-free content,” Core contributor Clifford Paulick commented on the ban announcement.

The level of opposition seemed to indicate that there may not have been enough discussion up front and that other branches of the WordPress contributor community, including commercial entities who are also contributors, were not considered.

“Discussion on [the] external linking policy is going in the way we wanted to avoid,” Milana Cap said during the July 13th docs team meeting. “I was thinking to explore a different approach.” She gave more background on why the team is reconsidering the ban:

The reason we didn’t want to allow ‘commercial’ links is to avoid abuse and make it ‘fair’ for everyone and not promote any product. We also wanted to save time for our members in a matter of maintenance and sort of automate the process. The further and deeper discussion goes I’m realizing this will not be possible. It won’t be fair, we won’t save time because we’ll have to do through discussion every time someone suggest ‘commercial’ link and I’m pretty sure we’ll never come to agreement on what’s ‘commercial.’ Personal blogs, services, products.. all of it is mixed now. So my suggestion is to allow them all, make process transparent and set strict rules about the actual ‘content.’

A Google document is now home to a collaborative effort on a new policy that Cap says is “fundamentally different from previous discussions.” The new approach proposes a set of criteria for allowing external links, banning things such as product promotion within the tutorial, affiliate links, paywalls, and tracking. The specific criteria and wording of the new policy are still under active discussion.

Sometimes it pays to speak up, if you have a strong opinion about a decision. Reconsideration of this external linking policy is the direct result of feedback on the initial controversial decision, even after it seemed to be final. This may result in a better solution for all stakeholders involved in this discussion.

Next week the Documentation Team will be hosting a Zoom call to discuss the proposal they have been collaborating on in Google docs. This meeting is for anyone who is interested, not just Documentation team members. If you want to get in on the discussion, check out the Doodle poll for the proposed dates and times.

WordPress Documentation Team Bans Links to Commercial Websites

This week WordPress’ Documentation team announced a ban on links to commercial websites in a revision to its external linking policy:

During discussion about external linking policy, we came to conclusion that we won’t allow, at least in the beginning and for the time being, any commercial blogs. So before you start arguing that some popular plugin’s blogs have valuable information, let me stop you right there.

Allowing “popular plugin’s/theme’s/services’ etc blogs” and all other commercial blogs will put us in a position to protect documentation from being abused as marketing media, to protect ourselves from accusations of being biased and to defend every decision we make along the way. And still, there will be dissatisfied sides claiming we weren’t fair and did them wrong. The idea of allowing external linking will become its own purpose.

Despite the announcement’s abrasive phrasing discouraging further discussion on the matter, the controversial decision stirred up a heated conversation in the comments. Yoast founder Joost de Valk contends that companies contributing to WordPress might as well receive some promotion as a benefit:

I understand that you want to prevent discussions about bias.

But I think your premise here is wrong: you’re saying you’re not “biased” if you’re not linking to commercial companies. I would say we’re all inherently biased, because some of those companies do a lot for the WordPress community, while others do not.

The companies that contribute to WordPress a lot used to get some links, and thus some promotion as benefit from the fact that they’re contributing. By removing that from them, you’re basically treating those that don’t give back the same as companies that do give back, something which I think is simply wrong. So I very heavily disagree with this decision.

Milana Cap, the Documentation Team member who penned the announcement, clarified that the policy change does not remove external links to commercial sites from WordPress.org. It only applies to documentation sites, including HelpHubCode ReferencePlugin and Theme Developer Handbook, Block Editor HandbookCommon APIs Handbook.

“There is no way to make this fair,” Cap said. “And we can discuss about many unfair parallels happening in open source communities; such as how many hours per week can be contributed by a freelancer vs paid company contributor, meeting times (where decisions are made) in the middle of the night in your timezone etc.”

Timi Wahalahti suggested one solution would be to better utilize the Five for the Future pledges page to identify significant contributors to documentation if links to commercial sites are no longer an option.

Several commenters noted the value of linking to additional examples and resources but also recommended WordPress put a version or timestamp in place to give the reader more context.

WordPress agency owner Jon Brown characterized the ban as “undesirable gatekeeping,” saying that the policy suggests all things commercial are “inherently corrupt and not trustworthy nor valuable.”

“A links value is inherently subjective and ought to be delt with subjectively,” Brown said. “Trying to create high level objective rules doesn’t seem beneficial or realistic. I certainly disagree that all ‘commercial’ sites should be blanket banned.

“I do think there are some low level disqualifiers that could guide authors and moderators in what links are appropriate. Those should be criteria that directly impact the users of docs, and being commercial doesn’t. Those are things like, the source being accessible, the source not being pay walled, etc.”

Cap responded, saying that the root of the issue is that allowing commercial links puts the documentation team in the unwanted position of having to find a fair way to decide on which links are allowed to be included. She also indicated that the policy may evolve over time but that for now the decision on the ban is final.

“Perhaps over time we’ll figure that out,” Cap said. “We’ll certainly know more once we start doing it. For now, this is the decision.”

External sources can be valuable supplements to documentation, but this conversation underscores the need for better incentives for people to spend time documenting WordPress. As the team is already running on limited resources, they are trying to avoid having to heavily police links to commercial websites.

“The bottom line is: we haven’t figured out the best way to deal with commercial blogs or sites in a fair manner and thus our focus is going to be on links that don’t drop into that grey zone,” Cap said. “We do expect to eventually get towards discussing how we can safely include commercial blog links (if this even is possible).”

WordPress Contributors Seek Sponsorship for Improving Gutenberg Developer Docs

WordPress developers Milana Cap and Jonathan Bossenger are starting a fundraiser for improving Gutenberg developer documentation. The conversation began yesterday when Cap tweeted about how documentation is often overlooked when companies hire full-time contributors to work on WordPress.

“When your community is unable to learn your software then you have no contributors,” Cap said. “Documentation and tutorials are far more important for Open Source Software projects than people realize.”

The first time Cap began asking for Gutenberg documentation was at the Community Summit in Paris, 2017. She has been trying to direct the community’s attention to it since then.

“There are many holes in block editor documentation for developers but the most obvious one is how to start,” Cap said. “The beginning of documentation for developers doesn’t say anything about getting started. “It says only what you can do with a block but not _how_. Junior developers, PHP-only developers and anyone for whom is that documentation meant, doesn’t know how a block’s code looks, where to put it, how to include it, etc, let alone how to build a custom block with custom components and settings.”

Part of the challenge of documenting the block editor is that it is under active development. Enhancements and refinements are constantly pushed out to the Gutenberg plugin and keeping track of what is or is not currently available in core is not always easy. As WordPress is imminently introducing block directory search, it is a good time to formalize block creation documentation.

“Code examples are alarmingly missing all over docs,” Cap said. “The most basic examples exist but how to actually build something usable is missing. So, on this first page we are sent to a tutorial but that tutorial is not optimized for people who have never built a block before. Following it, I have and will fail to build the block.”

Marcus Kazmierczak and a team of documentation contributors are attempting to rebuild the tutorial in the official block editor handbook. A GitHub issue focused on addressing gaps in the current developer documentation is home to an active discussion about the best way to rewrite the docs for people who are new to block development.

“This is a very good start but there’s still a lot of work to be done,” Cap said. “Complete documentation is written by people who know and understand React and Gutenberg but are ‘cursed with knowledge.’ They don’t have much time to spend on understanding just how much others don’t know and in what detail documentation should be written. To be honest, I don’t think they should spend their time on that. We have a Documentation Team and we are willing to jump in but some sort of bridge is necessary.”

The Problem with Gutenberg Developer Documentation: It’s Not Friendly for Newcomers

“The ‘problem’ as I see it with the block editor documentation is that, unlike other WordPress documentation, it is written for experienced JavaScript developers, and not aimed at beginners,” Bossenger said. “I should also point out, this is by no means a shot at the folks who have put the current documentation together, and I appreciate any and all work they have done so far, it’s just in serious need of a review and some refinement.”

Bossenger said in the past WordPress made it very easy for anyone with a limited amount of PHP knowledge to quickly build a plugin or theme using action and filter hooks. It was easy to look at the code and understand what it was supposed to do.

“Modern JavaScript, and specifically React, is a very different kettle of fish,” Bossenger said. “It requires a deeper level of knowledge of how React works, including new terminology and practices. Modern JavaScript can also be very confusing, especially if this is the first time you’re seeing things like arrow functions, or less verbose if statements.

“If the closest you have come to working with JavaScript in WordPress has been using jQuery, switching to React based Gutenberg development still requires some learning on your part.”

After taking two courses before he could build anything for the editor, one on React and one on Gutenberg, Bossenger said the current Block Editor handbook is not written for developers with no experience in React and modern JavaScript. He believes it needs a restructuring to better explain new concepts and fit a pattern that is easier for a newcomer to consume. He highlighted the Plugin Developer handbook as an example where the chapters follow a structure and use terminology that is more like a text book, slowly introducing the reader to new concepts.

“I would argue that it would be quite possible for someone with no plugin or PHP knowledge, armed with this handbook and Google, to build a simple plugin to meet their specific requirements quite quickly,” Bossenger said. “Currently the block editor handbook is not conducive to this.”

Bossenger is not alone in his opinion of the current documentation. Peter Tasker at Delicious Brains recently published a tutorial on creating a custom Gutenberg block. Even after working with React full-time for the past year, he found the official block editor docs to be “kind of all over the place” and difficult to parse.

After Cap commented about the lack of companies sponsoring full-time work on documentation, Bossenger tested the waters with a tweet asking if the two of them might be able to raise funds for improving Gutenberg docs.

“Just the same as Block Editor Team (and any other Make team), the Documentation Team is understaffed,” Cap said. “We can’t afford to dedicate few members to first learn and then write documentation on developing with block editor. This is the main reason for my tweet. You’ll see sponsored contributors all over core but not in documentation and I’ll dare to say that both are equally important.”

Before launching their fundraiser, Cap and Bossenger plan to go through the existing documentation, pinpoint obvious holes, and identify questions that remain unanswered for those who are new to developing for the block editor.

“Once we have a plan we can predict how much time is needed for each part,” she said. “With this plan, we will go in search for sponsors. I think there will be an option to donate even before that but nothing is certain at this point.”

Blocks are the new frontier of WordPress development. Investing in solid documentation and tutorials for beginners could have a major impact on expanding the block ecosystem. This also indirectly benefits users as they end up with a more diverse directory of blocks to choose from when customizing their WordPress sites.

Bossenger and Cap are currently working on a plan for the docs ahead of announcing their fundraiser. In the meantime, anyone who wants to contribute to improving the block creation documentation can jump in on the GitHub discussion.

How COVID-19 Affects Information Archiving

At the time of writing this text, in early April 2020, there were 1,348,628 people infected with COVID-19 worldwide, 367,758 across the States. A month later, the figure stands at 4.18 million cases of infection and 1.37 million cases in the US.

It’s been a little over three months since the WHO declared COVID-19 outbreak a global health emergency. In the meantime, the virus has managed to spread across the globe, taking lives, jobs, and families apart.

Creating a Readable REST API

When you are creating a RESTful API, it’s easy to get overwhelmed by all the different things you need to take into consideration: throttling, REST verbs, security, authentication, input validation, etc., so it’s easy to forget about the more subtle issues that can make a lot of difference in the long run. Most of the topics described above were already discussed (extensively if not exhaustively) elsewhere, so I’ll try to give my take on how to create a readable API for developers to consume. It’s a more subtle and less-discussed topic that can have a significant impact on the success of your API. After all, an API that no one can read, no one will use.

Use a convention for endpoint URLs and method names: plural vs singular – pick one. There is nothing worse than trying to fetch information from /api/v1/orders/{id} and debugging this forever just to find out that this is the only place where you have chose to use /api/v1/order/{id} (singular instead of plural) as the endpoint URL.