Closed casperdcl closed 3 years ago
Awesome! I'm glad we're planning to place documentation on to cml.dev 😄 A couple questions about this:
@julieg18 I think a lot of this is up to us (well, you guys) to decide. Quick comments:
doc.cml.dev instead of cml.dev/doc~s~?
this is a pending discussion actually, but hopefully that's mostly the docs team's problem and won't affect the bulk of the web eng request.
And if this will be on a subdomain, with documentation code be inside this repo or a separate repo?
Same repo - personally I often tend to set up my hosting configs/engines to mirror X.domain.com/
and domain.com/X/
so I was hoping that it would be easy to set up the custom engine here to push a doc/
folder in this repo to either public URL format (subdmain or subfolder).
are we planning to basically copy dvc.orgs design
Copy the effective functionality, and do whatever is easiest for design for now (long term plan is to keep design the same, but if for now just having a basic design is easiest then go ahead)
When it comes to creating the pages, are we planning to do it the same way dvc.org does it? Aka, created markdown pages, converting them to nodes, create pages with those nodes, etc.
Yes plz. I don't know if you want to discuss with @shcheklein other higher-level issues of potentially switching to gh-pages
(Jekyll) and our own Jekyll theme (should make web eng much easier in the long term?)
straight-up copying the docs engine from dvc.org
definitely something to ask @shcheklein about - rather than copy it's probably best to extract into separate repo and then have both websites depend on it. At that stage again I'd say gh-pages
+ custom Jekyll theme is a better idea than maintaining our own engine (equally powerful/customisable with *.html|js|scss
and no headache of maintaining an entire engine).
straight-up copying the docs engine from dvc.org
dvc.org is very unique as a Gatsby website, and to an extent that unique architecture is a weakness as much as (if not more than) a strength- many parts of the more intricate functionality are a bit fragile, and very unwieldy to fix or add to.
To @casperdcl's point, using and contributing to an existing docs solution is, at least in my opinion, the clear path forward as it saves us development resources, gives us features, and allows us to contribute to the wider community by improving or writing plugins/guides/content for an open source docs project.
Whether that solution be a Gatsby plugin or GH Pages + Jekyll, especially since the doc writing experience between the two is nearly identical, depends on what we want out of the docs user experience compared to what GHP+Jekyll solutions can offer us.
If we want plain ol' HTML text docs with a sidebar and search like 95+% of docs do (for good reason, don't get me wrong) then a Jekyll GHA site could really simplify things. On the other hand, if we want more functionality on top of that like interactive custom components or integrating with the rest of the site, the cost/benefit starts to shift more in Gatsby's favor.
Should we decide to go with GHP+Jekyll docs, we can try to integrate it with the existing site, which would take on a "marketing" role as opposed to the GHP docs. It could be that having the sites use the same colors and link to each other is enough integration, but doing so will require us to maintain a separate Jekyll-compatible design alongside our React one.
in summary:
edit: also worth noting Gatsby can be used on GH Pages, though I'm not confident that we'd gain much overall compared to our current setup, particularly where we're already very invested in Heroku hosting.
My take and context:
Can we try to prototype something with Jekyll to see how much stuff we'll have to write (it might turn out that pretty much the same amount):
So summary:
If there are no takers for (1) then we should get started on (2) soon because we need docs!
Okay, I can find some resources (at least try). But quick questions before - why is it p0? :) To me still content is most valuable part - we can iterate on the content within dvc.org for a while, right?
p0 - usually means that something is completely broken, it severely blocks someone from doing anything, etc.
Well this is an issue on the cml-website
repo so I assumed p0
was the most appropriate tag since it's more important than the other issues on this particular repo atm? Feel free to downgrade if you disagree.
@casperdcl no, I'm fine, you decide with the team on this. I just shared what it means in other repos.
I think this is easily at least p1, p0 may be a bit much for the entire docs engine but at least making a plan to move forward with is p0-worthy.
If there are no takers for (1) then we should get started on (2) soon because we need docs!
I don't think there's takers for 1, without a prebuilt Jekyll solution that takes care of all the functionality we want, which given this list seems unlikely, we'll want to move forward with 2, extending the Gatsby site, at least for now.
We should be able to reuse quite a bit of DVC's docs engine logic, and it's worth investigating, but I can't guarantee it'll translate easily or well and will require some research.
@julieg18 would you be able to do some research into dvc.org's docs engine, specifically oriented toward implementing it on other sites? Off the top of my head, I believe they're based on gatsby-plugin-remark
and use this technique for using custom components (unlike the blog, which uses a different way) and sidebar logic is scattered in a few util files and components.
There's a lot of extra config that has to be applied to get everything together so I suspect some files will have to be blended together and it won't be truly "drop-in".
@julieg18 would you be able to do some research into dvc.org's docs engine, specifically oriented toward implementing it on other sites?
Sure! When you say "dvc's docs engine" are you referring to the way that dvc.org renders the documentation pages? Taking the markdown, adding or converting certain elements, creating nodes, using nodes to create pages, etc?
I'm assigning this for myself for now. Let me try to get someone do this first step fast. Then we can think about generalizing, etc.
Sure! When you say "dvc's docs engine" are you referring to the way that dvc.org renders the documentation pages? Taking the markdown, adding or converting certain elements, creating nodes, using nodes to create pages, etc?
Yep! That and the sidebar, which is equally important to the content. Some specific features we need from the sidebar:
Are we good to close this issue since the docs engine is now implemented?
fixed by #60
Implementation request for website team (if you're from CML or Documentation teams and want to discuss specifics please see #55 instead).
Blank pages corresponding to folders:
doc.cml.dev/
CML Documentation/start/
Getting Started/start/github/
Getting Started with GitHub <-- sub-page/ref/
Command Reference/ref/#send-comment
cml-send-comment <-- in-page<h2>
s which show up in the ToCEach page can be blank for now (I'll fill in content) :pray: @rogermparent @julieg18