Open vsoch opened 7 years ago
Hey @massich ! I really like sphinx too, but I've found it to be a harder learning curve using rst syntax than simple markdown. A jekyll site is harder to setup the base for, but once it's there, it's super easy for the layerperson or new user to add content! Jekyll renders automatically (meaning builds) on github pages, so there is huge advantage to that (eg, what you push to master renders live!) If we want preview for PRs I can definitely add that to circle!
The problem of jekyll is that you need to maintain the documentation in two different places.
I'm ok if you want to maintain docs with the pydicom code base - the pydicom.github.io can have a high level intro and then link there for more details. It's mostly important to have one cohesive entry point for finding all these things.
I agree that we should have a common place to introduce the community, the projects and testing data to get started. There's no problem in using Jeckyll for this introduction page.
However, I would keep the documentation related to each package within the package codebase (and using sphinx ... I will come back later on that). IMHO separating the examples from the codebase has two main problems: (1) they are harder to maintain, and (2) spreads the information which ends up confusing the user.
The documentation of pydicom (the software) could be improved. We could build a set of examples (using sphinx-gallery) and a more broader user guide, similarly to what we are using in our different projects in scikit-learn, nilearn, or imbalanced-learn. I am almost sure that similar thing can be drawn for the other packages which will be part of the pydicom community.
Acting in this regard, contributors will be able to focus on the project which they have more affinity with, which will be beneficial with more curated code and documentation. The pydicom organization will allow to bring all those together without duplicating efforts.
WDYT?
That sounds like a great idea! If we can have assurance that it will be relatively easy for any user to PR, or any admin to update docs, then I'm ambivalent to where they are. I would, however, advocate for a design that, even if it's not exact, at least sort of matches to give unity to the overall look. I'll hold off adding any more to this repo for pydicom as you update the sphinx docs, and then what we can do is have a main page for each code base on the pydicom.github.io site that links to their main docs.
My preference has migrated from sphinx to jekyll over the years because it removed an entire step of needing to host the sphinx docs somewhere, or if not using readthedocs, have some CI build and then deploy. And then there are sometimes bugs with the builds on readthedocs. I like jekyll because:
It's important to make the steps of contributing content, whether that is code or docs, as transparent and easy as possible. I can see a user being comfortable with copy pasting a markdown file and then adding it, versus having a harder time understanding how rst / sphinx works.
Some
This is great, and we can start by this. But shouldn't be be improving the package documentation and then let
sphinx
and cricle ci build the website as in sci-kit learn?I would definitely add one on how to use DCM and RTSS to load volumes and overlay ground truth.