Replies: 1 comment 17 replies
-
|
I'm reviewing many document generator tools.
There are more: https://en.wikipedia.org/wiki/Comparison_of_documentation_generators Some are not free, so I'm not seriously considering them. DocFX is Microsoft's, and seems like the most natural fit so far. It has a large number of features, is actively maintained, integrates well with the tools. I'm not sure right now how much work would be required to get something like a responsive site output so that the docs could be called up on a mobile device, for example, but also having a desktop site that is capable of delivering a rich experience. How important is it that the generation process includes good integration with IDE tools (VS, VSCode, ... Rider? Eclipse?)? |
Beta Was this translation helpful? Give feedback.
-
|
BTW the reason I planned to do 2(i) on the separate branch is because we won't be ready to merge the move to DocFX until at least 2(iii) is done, if not also waiting for 2(iv). If we do 2(ii) separately from 2(iii), then merging it into |
Beta Was this translation helpful? Give feedback.
-
|
Well, like I said at the outset, I'm totally fine doing anything and everything that is related to documentation. I'm encouraging you to delegate stuff to me. I'll make sure that you understand and agree with anything I'm doing. So I can just start doing all of step 2 (i through iii) so that we can get to 2(iv). I'm in a good place to put in plenty of time just now. So I'm ready to do (a) and then (b), including any work that is needed to keep the new branch up to date with anything that might happen on the |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good to me! Since you're doing all the work, feel free to just set up your own branch, and when you're done we can do it as a normal PR against |
Beta Was this translation helpful? Give feedback.
-
|
To implement |
Beta Was this translation helpful? Give feedback.
-
|
I'm releasing a new build today, and I decided I should stop writing things in HTML and start writing them in Markdown so I don't just grow your backlog unnecessarily. 😂 Might as well start with the release notes, right? In an attempt to switch, it become apparent to me how much I'm doing that isn't Markdown compatible, like adding CSS classes and custom attributes to things. I spent some time noodling over the best way to completely get rid of custom HTML in the release notes, and I ended up with some creating CSS rule writing via a custom stylesheet that is only used for release notes. I considered also converting the index page, but I felt a little held back on the way tables are styled there, and I didn't want to bite off too much at once. Would be curious on your feedback on this commit, and the general strategy of using small CSS stylesheets that get added to particular page "types" to help keep the Markdown HTML-free. This is obviously going to be an ongoing problem across the site as everything moves to Markdown. 31ba316 |
Beta Was this translation helpful? Give feedback.
-
This is me introducing myself to the xUnit community and getting started on my pet project: bringing the overall documentation for xUnit to a higher quality than where it's at now. I don't have many details yet on what all that will mean, but at the start it will mean bringing back most (all?) of the reference docs that are currently absent from the documentation website. I have big ideas, but I'm new to being a long-term collaborator, so I'm expecting to just learn the ropes for now. That means going over all the issues and discussions related to documentation and digesting all of that before committing to anything beyond bringing back the reference docs.
Beta Was this translation helpful? Give feedback.
All reactions