Mostly business as usual at the Ubuntu Project docs. A notable addition to the docs set is guidance relating to checking for accessibility issues. Aside from that, work continued on DMB (Developer Membership Board), and an initial structure has been put in place for the Release team’s docs.
Are you wondering what all this is about? Check out our entire article series:
Ubuntu Project docs
- Bringing together 20 years of documentation
- Ubuntu Project docs: MIR, ACLs, and more
- Ubuntu Project docs update: making sense of the contributor story
- Ubuntu Project docs: welcoming our first contributions!
- Ubuntu Project docs: Will it blend?
- Ubuntu Project docs: Sorting things out
- Ubuntu Project docs: Piloting ‘article series’
- Ubuntu Project docs: Another day at the office…
This is probably the briefest two-week update because both Sally and I were finishing our vacations, so we each were in for only four days out of ten. Still, some stuff happened 
Accessibility guidance
Thanks to @juanruitina and @marek-suchanek, we now have an article on how to check for accessibility issues. Anyone can use it to review their contributions and also provide feedback.
The article provides guidance mainly on visual checks, keyboard navigation, and screen reader; both what to look out for and how to use the assistive technologies themselves for testing.
DMB docs history and improvements
@sally-makin and @paelzer imported the wiki history for the DMB (Developer Membership Board) knowledge-base article. This is something we’ll be doing more of when importing/migrating other docs from the wiki or other Git repos.
The history of edits reflects the decision-making process and the timeline of changes (as well as who made them), so keeping that record is in some cases a prerequisite of any moves toward a consolidated docs set.
Christian and @jchittum also rewrote the DMB application-expectations page to make it a bit friendlier, with illustrative examples of what “good” looks like.
Initial setup for the Release team
Sally met with the Ubuntu Release team and had a good chat with them about their docs + needs. Based on that, she added an initial setup of their space (which included converting all of the Release team’s content into Markdown) and updated the CODEOWNERS file to give the team ownership of their content.
SRU, Governance docs discussion
I started a conversation with the SRU (Stable Release Updates) team and the Ubuntu Technical Board about bringing their respective docs into the Ubuntu Project docs fold.
Similarly to the MIR team, Archive Admins, and the Release team, these groups need to retain control over the content that’s published. In the case of the SRU team and the Board, things get a little trickier because they include community members who are not part of Canonical. Therefore, we want to make sure there are no misunderstandings, and the teams are on board with the ACL scheme we have set up.
You can read my initial (lengthy) email to the ubuntu-devel mailing list at SRU and Governance docs → Ubuntu Project docs.
Housekeeping
A small yet notable change in the way we handle copying from code blocks that include a command prompt. (This change happened a few weeks ago, but I forgot to mention in these updates.)
As you may have noticed, the docs offer a copy button when you hover the mouse cursor over a code block. This is a nifty little feature that allows you to quickly get the contents of a code block into the clipboard.
This copy button is configured to automatically exclude any command-line prompts from the copied content. When you’re copying an example command from the docs to try in your terminal, you don’t want any potential user@host:~$ stuff in the clipboard.
In this update, I added a regex-based configuration that is capable of detecting all kinds of prompts, including bare $ dollar or # hash signs, prompts with users, machines, directories, etc. It also recognizes \ backward slashes that divide long command lines and ensures the command is still copied properly. When there are multiple prompts in the code block, only the first command is copied.
Test it out, and let us know if it works as you’d expect.
What’s next?
Sally will be mainly working with the Release team on consolidating their docs, plus helping the DMB as they work through their reviews and updates. I will focus on improving the content about Merges, as well as preparing the SRU and Governance docs for their eventual move.
How to contribute/get involved
- If you’re looking for a quick-win kind of thing, then the Glossary is the place to go – there are still many term definitions missing, and they should be rather simple to knock out.
- If you’d like to contribute a substantial piece of content, look no further than the missing articles under QA and testing.
- As always, reviews of any content are welcome!