Let's kick off the New Year with Alvin Ashcraft as he demonstrates ways to contribute to the Microsoft Learn documentation. 📒 Sign-up using the Meetup link below.
During the last days, we optimized our #NumeRe#release process. Now, after compiling both x86 and x64 targets, creating the packages is completely automated. We'll now also ship an up-to-date PDF variant of the internal #documentation with over 160 pages replacing the previously embedded PDF documentation (which was awfully outdated). The contents of the PDF are identical to the internal documentation, it should however improve the reading experience.
#TechnicalWriting#SoftwareDocumentation#Docs#Documentation#SoftwareDevelopment: "You may wonder: how can I write technical content? Do I need to be a great coder? Do I need to have a background in writing? Let me answer those last two questions now: no. Writing is all about communication, as I discuss throughout Software Technical Writing: A Guidebook. If you have some technical skills and enjoy refining your communication skills, you have the mindset you need to write technical content.
Software Technical Writing: A Guidebook starts with an introduction to the role of a technical writer. The book then discusses guidance for writing, covering topics from clarity to style to code snippets. Finally, the book discusses how technical writing fits in with the rest of an organisation.
This book is written for people who want to start writing technical documents, or who are early in their careers and are looking to refine their skills. With that said, no matter where you are in your journey with technical writing, Software Technical Writing: A Guidebook contains tactical guidance you can use in your work."
My preferred containerization solution when I'm not using FreeBSD: LXC/LXD on Alpine Linux.
Back in 2020, I documented the (easy) installation and usage procedure of LXC on Alpine Linux in their wiki: https://wiki.alpinelinux.org/wiki/LXD
This will always mean fewer success cases, poorer views of your product within your ecosystem, more unhappy developers or users, and a negative impact on your brand or company.
Docs are a serious sub-product in their own right, are an investment, and must be part of your wider product strategy."
I wish more projects would add the ability to download the full documentation as an Epub to read leisurely in your e-reader. I am speaking mostly of documentations that are fairly large and would take some time to get through.
We're excited to announce a new conference as a part of Open Source Summit starting in NA in 2024: TechDocsCon 😃
TechDocsCon is for those interested in best practices for open source project documentation processes and communication, and provides an open forum to share real world experiences, how documentation impact and success is measured, what’s working and what’s not, and so much more.
I've been re-reconverting a lot of my "stuff" to the BSDs (Free, Open, Net). It's refreshing. The Linux every-tool-has-to-be-a-swiss-army-knife ethos is exhausting after a while. The relative simplicity and clean organization of *BSD (especially OpenBSD) re-affirms my fondness for UNIX-y things.
You might think there's not that much difference but, in many cases, I'd rather admin a BSD box. Try it, you'll see.
Also, NetBSD is soo lean, it has made my old Pentium III almost useful again. Even with 333Mhz and 128 MB of RAM 🙃
@rory Well, for OS71337 I took inspiration from @w84death 's #Floppinux and took his #documentation and went full "chimp banging rocks together" on it, but swapping #BusyBox for @landley 's #toybox since I prefer #bash over #ash and wanted something really basic that would do more than cat text files but provide i.e. a portable #SSH#client on a FDD.
Something that could serve as a foundation or rather plain "slate for my other projects in lieu of a THICC distro that is not practically auditable
Whether it's your very first contribution to an open-source project, or you're translating our docs, or you're contributing a how-to recipe, or you're preparing the accompanying documentation for your new Astro feature... we have a guide for that!
Want to level up your open-source documentation skills? We even have guides for reviewing docs PRs: what we look for when we work with, and bring out the best in, your contributions to us.
If you want to contribute to @astro Docs, or you're looking for some guidance you can follow to create your own project's docs, we hope you'll find our resources helpful.
Even with a #GalaxyBrainChair I'd rather want stuff to be reproduceable to the point that everyone able to read, type and follow instructions should be able to get it done.
I'd also want to prevent myself from becoming a #SPOF to any developments because I don't think that's a viable strategy outside of scamming tech-illiterates into never firing one, and that's just not something I want to roll with.