badgers and non-badgers

:D

In fact, I like the setup: all the badges along the top and prose 
afterwards.

Yes, that’s a good compromise. Happy to make a change like that.

— Mike
On Saturday, 18 June 2016 21:54:03 UTC+2, Mauro wrote:
>
> As others in this thread, I was confused by (and thus ignored) those 
> documentation badges the first time I saw them, even though I was using 
> the travis badges regularly.  To help badges-challenged people like 
> myself, maybe add a normal link too?  In fact, I like the setup: all the 
> badges along the top and prose afterwards.  This serves both the badgers 
> and non-badgers.  (I agree though that you can keep the readme short if 
> other docs are provided.) 
>
> PS: Thanks, Mike, for all your work on the Julia documentation system! 
> It has come along nicely and a very long way since you started working 
> on it. 
>
> On Sat, 2016-06-18 at 18:34, Michael Hatherly <michael...@gmail.com 
> <javascript:>> wrote: 
> > Here is the entire section from the raw file 
> > 
> > “Raw file” is the key here: those are image links below the sentence. 
> Look 
> > at 
> > the rendered version on the GitHub repo rather and you’ll be able to see 
> the 
> > docs badges correctly. That’s the most common way people will be 
> browsing 
> > for 
> > packages. I can try make those more obvious/informative in their raw 
> form 
> > though. 
> > 
> > without a link in the README 
> > 
> > There are links in the README. 
> > 
> > it is standard for Julia packages to have a short introduction and 
> > documentation in the README. 
> > 
> > I’m aware of what some packages chose to do. I have chosen to provide 
> very 
> > clear links to the documentation instead. I would say that part of the 
> > reason 
> > that packages make use of the README for their documentation is that 
> there 
> > have not been many other viable options. To me a README should provide 
> more 
> > developer-orientated details of a project, that’s just my view though :) 
> > 
> > I saw that line too. 
> > 
> > I GUESSED that maybe Markdown 
> > 
> > If you saw that line then “guessed” can’t really be the right word. 
> > I’ll add a more clear point in the introduction though. 
> > 
> > use markdown syntax inside docstrings 
> > 
> > That is covered by the main Julia manual. A link could be provided to 
> that, 
> > but 
> > generally the route potential users should be taking is to read the 
> Julia 
> > manual first and then go looking for packages that they need. 
> > 
> > If I didn’t already know some Markdown 
> > 
> > Yes, a link could be provided to resources that teach markdown. I’d be 
> fine 
> > with that, but Documenter’s manual is not the place to teach markdown 
> syntax 
> > from scratch. 
> > 
> > I think it’s great that now there is a documentation package for Julia 
> and 
> > I’m very glad you wrote one. So thank you for that. If I get the time, I 
> > will make a PR. 
> > 
> > Thanks, and I’d also like to thank you for all your input on the 
> docsystem 
> > discussions in #3988 and elsewhere. 
> > 
> > — Mike 
> > 
> > 
> > On Saturday, 18 June 2016 17:30:54 UTC+2, Daniel Carrera wrote: 
> >> 
> >> Hi Mike, 
> >> 
> >> Thanks for being cool about my (hopefully constructive) criticism. I'm 
> >> very glad that there is now a package for documenting Julia code, and I 
> >> expect to use it in the future. So thanks for that. 
> >> 
> >> 
> >> On 18 June 2016 at 15:20, Michael Hatherly <michael...@gmail.com 
> >> <javascript:>> wrote: 
> >> 
> >>> It has two lines on installation, one line on project status, and two 
> >>> sentences on “contributing and questions”. 
> >>> 
> >>> You’ve missed out the section called “Documentation” there. Perhaps 
> you’re 
> >>> viewing a cached version of the README that isn’t showing it for some 
> >>> reason. 
> >>> 
> >> 
> >> The "Documentation" section has literally one sentence (one I don't 
> really 
> >> understand). Here is the entire section from the raw file: 
> >> 
> >> -------------------------- 
> >> 
> >> # Documentation 
> >> 
> >> Documentation is built automatically with help from *MkDocs* on *Travis 
> CI* and hosted by *GitHub Pages*. 
> >> 
> >> [![][docs-latest-img]][docs-latest-url] 
> [![][docs-stable-img]][docs-stable-url] 
> >> 
> >> ## Project Status 
> >> 
> >> -------------------------- 
> >> 
> >> 
> >> 
> >>> the README file of a documentation package should have at least as 
> much 
> >>> documentation as the README files of other non-documentation Julia 
> packages 
> >>> 
> >>> Adding additional duplicated documentation to the README when there is 
> >>> already 
> >>> a substantial amount of documentation elsewhere isn’t really worth 
> doing 
> >>> in my 
> >>> view 
> >>> 
> >> Well, the point of a README file so to have useful information about 
> the 
> >> package. The current file is close to empty (but maybe I'm looking at 
> an 
> >> old version?). Also, how are people going to find documentation without 
> a 
> >> link in the README? Lastly, it is standard for Julia packages to have a 
> >> short introduction and documentation in the README. This file is also 
> often 
> >> used as a gateway to the rest of the documentation. For example: 
> >> 
> >> 
> >> https://github.com/plotly/Plotly.jl 
> >> https://github.com/stevengj/PyCall.jl 
> >> https://github.com/JuliaLang/ODE.jl 
> >> https://github.com/staticfloat/Opus.jl 
> >> 
> >> 
> >> Notice that PyCall has a very extensive README. But even a very short 
> >> README like the one from Opus.jl still includes sample code, and some 
> >> information about usage. I would call Opus.jl an example of a poorly 
> >> documented module, and the author still thought it was a good idea to 
> >> explain a bit about how the package works and what it does. In 
> contrast, 
> >> with Documentation.jl the only way I know to find information is to go 
> to 
> >> my email client and find this thread. 
> >> 
> >> you should state what markup language you are using. 
> >>> 
> >>> That is mentioned directly above the feature list in the summary line: 
> >>> 
> >>> A package for building documentation from docstrings and markdown 
> files. 
> >>> 
> >>> so I didn’t feel the need to duplicate that again in the feature list. 
> >>> 
> >> 
> >> It is not duplication, it is clarity. I saw that line too. This is 
> partly 
> >> why I GUESSED that maybe Markdown is used. That, and the file that 
> Julia 
> >> docs often use Markdown; but I only know that because I've been around 
> >> Julia for a while. The one sentence you are referring to does not in 
> any 
> >> way say or imply that you can use markdown syntax inside docstrings. I 
> >> mean... cant you actually use Markdown inside docstrings? I suspect you 
> >> can, but I don't actually know for sure. I know that in your email you 
> >> basically said "yes". But how much of Markdown do you support? Which 
> >> flavor? I think that these are things I should have been able to infer 
> >> easily since this is the core feature of your package (unless I 
> >> misunderstood the package). 
> >> 
> >> There is such a thing as too much duplication, but you are nowhere near 
> >> having that problem. Currently the documentation is closer to the 
> opposite 
> >> end, where you tend to write the bare minimum and it seems like you 
> expect 
> >> users to try to guess what you might have been thinking. That's not 
> where 
> >> you want to be. I would also argue that it's better to err on the side 
> of 
> >> being "too clear", rather than not clear enough. 
> >> 
> >> 
> >> 
> >> 
> >>> Maybe add some examples showing the use of Markdown. 
> >>> 
> >>> There’s already a number of examples that illustrate the syntax in the 
> >>> “Guide” 
> >>> page and “Syntax” page. 
> >>> 
> >> 
> >> I did scan at the Syntax page.  On a second look, I do see examples of 
> >> Markdown. If I didn't already know some Markdown, I think I would have 
> >> missed it on the second look as well. The thrust of this section seems 
> to 
> >> be about @doc, @autodocs, and the other blocks in the package. I didn't 
> >> imagine that the examples were supposed to introduce some bits of 
> Markdown 
> >> syntax. 
> >> 
> >> 
> >> 
> >>> PRs to improve the docs are most welcome since it’s always difficult 
> to 
> >>> read 
> >>> the docs from the point-of-view of a new user. Thanks for taking the 
> time 
> >>> to 
> >>> have a look at the package Daniel. 
> >>> 
> >> 
> >> I think it's great that now there is a documentation package for Julia 
> and 
> >> I'm very glad you wrote one. So thank you for that. If I get the time, 
> I 
> >> will make a PR. 
> >> 
> >> Cheers, 
> >> Daniel. 
> >> 
>

Reply via email to