Ubuntu Project docs: post pit-stop push

Ubuntu Project docs: post pit-stop push

Despite our recent vacations, work still continues at a vigorous pace. With the efforts of our contributors we’re in a strong position as we look towards the final lap…

Are you wondering what all this is about? Check out our entire article series:

Ubuntu Project docs

  1. Bringing together 20 years of documentation
  2. Ubuntu Project docs: MIR, ACLs, and more
  3. Ubuntu Project docs update: making sense of the contributor story
  4. Ubuntu Project docs: welcoming our first contributions!
  5. Ubuntu Project docs: Will it blend?
  6. Ubuntu Project docs: Sorting things out
  7. Ubuntu Project docs: Piloting ‘article series’
  8. Ubuntu Project docs: Another day at the office…
  9. Ubuntu Project docs: post pit-stop push
  10. Ubuntu Project docs: Going (semi)official!

Thanks for contributing!

Over the last two weeks, we’ve had some excellent contributions. It’s fantastic to see people not just using the documentation, but actively improving it.

  • The Developer Membership Board has greatly clarified their expectations for applicants, and simplified some of their processes. In particular, they are now using Discourse to host applications, replacing the old wiki method, and they have updated their documentation to reflect this change. Thanks to the DMB, but particularly @paelzer and @utkarsh for their work in making this happen!
  • There are a number of popular packages and toolchains with very specific and specialized maintenance procedures and requirements. @maxgmr and @petrakat have created and contributed comprehensive documentation for Rust maintainers, which will hopefully be the first of many such documentation sets. Thank you both for all your hard work on this!
  • @paelzer also contributed the PGP guidelines, which provides recommendations for working with PGP keys.
  • @waveform has provided a helpful explainer about the available Debian maintainer scripts.
  • Thanks as well to @shanecrowley and the Desktop team for adding a description of WSL images.

Quality and quantity

Over the last two weeks, @rkratky and I have put our focus into different areas so that we can continue to make steady progress in all of them.

Robert has been paying close attention to the quality of what has already been migrated, and has made a wide range of improvements over the last two weeks – both behind the scenes and in front. From adding a CLA check to the repository, to making the index schema more intuitive, he’s been successfully finding all sorts of ways to make things simpler and more efficient. This has been most evident in the introduction of his article series approach, bringing together related topics to make them more discoverable. We’ve done this for a few different sections now, and the latest to receive the series treatment is the set of pages about Merging, where he also took the opportunity to streamline and better organize the pages about merging and syncs.

Meanwhile, I’ve been working closely with @utkarsh on reviewing the Release Team docs from the wiki – as we clean up and polish the docs I’m also setting up redirects from the wiki pages, so you may notice you’re finding your way to the Project docs more often. In particular, we’ve put together an “about the Release Team” page, and the list of releases has had a bit of a facelift as well. While some docs are finalized over time (like these) others are completed all at once! After all the de-duplication and page-blending efforts of the past weeks, the Ubuntu Maintainer’s Handbook (UMH) got its “redirects” today! Well, not redirects exactly (since it’s a GitHub repository), but each page does now have a link to its counterpart(s) in the Ubuntu Project docs. Those who use the UMH as a reference will still find the Server-team specific pages there, and it should still be a useful signpost.

What’s coming up next?

For the next two weeks, Robert will continue to blend, polish, streamline, and de-duplicate, while I will be finalizing the DMB docs and working with the Release Team on their public docs.

How to contribute/get involved

Since we’ve added a new Pull Request template, it’s a great time to jump in and propose some changes to the docs!

  • The Glossary is still a great place to make your first contribution – there are many terms needing definitions.
  • If you want more of a challenge, check out some of the issues in our issues list
  • Or, please feel very welcome to create issues if you spot anything incorrect, outdated or out of place! Use the “Give feedback” button at the top of any page to report problems.

We look forward to hearing from you!

4 Likes

Thank you … for all that good work!

Especially for the new succinct format of the list of releases.

Also, good to have the “Release Team” SPOC page, but … have you considered that should be Release-specific, i.e. 26.04* … or just 26.04.# ?

Or is that Release Team the same for every release (I couldn’t imagine so)?