New Documentation Structure #104
confused-Techie
started this conversation in
Documentation & Website
Replies: 1 comment
-
I definitely liked the idea of what they aimed for with "hacking atom" in naming but I felt the sections were too broad. Like there should've been a basic, intermediate and advanced sections. (with appropriate short descriptions of what the section contains) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Alright, so as confirmed by @Daeraxa we are essentially done with Phase 1 of docs. That is get everything onto the website in the same format that Atom had.
But as we've seen, and like many members of docs have mentioned that old format of the Flight Manual Book doesn't really work anymore, discoverability isn't as easy for new users, and can seem (in my opinion are clunky and unwieldy compared to any good modern doc website).
So I'd like to propose and discuss the possibly changes we could make to update these, and get things more modern.
Ideally the changes here would relate mostly to shuffling around our existing docs rather than the creation of all new docs, but of course we can touch on whatever is needed.
As I am mostly on the backend side of things I'll obviously have the most opinions there but here's what I think.
We have less subsections. Currently our docs have super broad expansive sections such as "Hacking the Core" that go from Building the editor from source, to publishing a package, finding your crash logs. I personally would much rather see us have a page long list of different sections, with each then only having a few sections within them.
The main benefit to a move like this is so that when I as a brand new user come to our docs saying "I need to learn where my logs go" I don't have to assume "Hacking the Core" will get me there, then scroll through a two page long list of options till I see "Debugging".
And I'll suggest the layout for the section I'm most worried about, again being the package. But could be roughly something like this (With other docs excluded, but hopefully standardizing a way we can talk about depth of docs)
But this is only one small section, but already we can see from this, if one of the header sections of our Docs is "Authoring Pulsar Packages" then anybody that aims to do so will know exactly where to go, and would find exactly what they expect to find here. Then the Resources section could contain a friendly table of the whole section, while at the top including links to background information that should be known, while not having to include it in the docs or this section of docs as a whole. This could aim to be especially helpful for all the times the docs get to deep into how to use GitHub, and how to use git. Especially if we aim to support more platforms than GitHub, this becomes useless. Because realistically the only reason they included so much how to use GitHub is because this was made by those same people, so of course they could talk all day about the features and usage of GitHub, but we aren't them and should try to remove some of that out of here.
Beta Was this translation helpful? Give feedback.
All reactions