Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish documentation #321

Closed
wilcoschoneveld opened this issue Jan 20, 2017 · 10 comments
Closed

Publish documentation #321

wilcoschoneveld opened this issue Jan 20, 2017 · 10 comments

Comments

@wilcoschoneveld
Copy link

e.g. with Sphinx integrated it should be possible to import the repository at https://readthedocs.org/.

@seemethere can you facilitate this?

@wilcoschoneveld
Copy link
Author

@kdelwat fyi

@kdelwat
Copy link
Contributor

kdelwat commented Jan 20, 2017

The problem is that Read the Docs doesn't support Python 3.5 syntax natively yet, as discussed here. There seems to be a workaround using Conda in that thread which would be a good solution.

@zkanda
Copy link
Contributor

zkanda commented Jan 20, 2017

If you look on that issue, this seems to be it: http://stackoverflow.com/a/36144269

I can send a PR if using conda is an accepted solution here.

@wilcoschoneveld
Copy link
Author

IMO conda is a good solution.

@seemethere
Copy link
Member

This could be a possibility in the future but I don't see the added benefit just yet. The on-github docs done by @kdelwat seem to work great and if there's not a reason to add complexity then we shouldn't.

@luizberti
Copy link

luizberti commented Jan 30, 2017

I would say migrating docs into GitHub's built in Wiki feature and allowing for community edits would be a great way to improve the currently bare-boned docs right now.

Besides it taking away much of the overhead from contributing documentation, not having to fork, clone, edit, push, PR, merge or anything, it's also nice having doc contributions separate from actual code contributions. It declutters the PR interface, and is overall less stuff to micro-manage.

@JordanP
Copy link

JordanP commented Jan 30, 2017

it's also nice having doc contributions separate from actual code contributions.

Nope. Good practice is too treat doc as code, and have it in the same repo.

fork, clone, edit, push, PR, merge or anything

People are very used to this workflow.

Also being not too tied with Github might be a good idea.

@luizberti
Copy link

luizberti commented Jan 30, 2017

It would not be tied to GitHub at all, it's still a Git repository that will live under github.com/channelcat/sanic.wiki.git, except it will appear integrated into this repo under the Wiki tab instead of as a new repo under channelcat's user.

You can still clone it and move it wherever you want, it's just a git versioned folder of Markdown files (much like what docs currently is) except it has navigation controls and a nice Web editing interface that lets you contribute docs without forking the whole thing and dealing with the bureaucracy of PRs which might be routine stuff for many, but I still believe it's burdensome to most.

It would be a relatively painless thing to implement and try out, and it might lead to more contributions given that it lowers the barrier of effort needed to submit improvements. Might be worth testing out, all it takes is mirroring the Markdown documents from the docs folder into the Wiki and seeing how it goes...

@zkanda
Copy link
Contributor

zkanda commented Jan 31, 2017

I think this can be closed: https://sanic.readthedocs.io/en/latest/

@luizberti maybe open a different issue for that?

@seemethere
Copy link
Member

I'd agree. I like the wiki style for some things but I think the docs should stay checked in with the code.

Maybe we can agree for some of the docs to go to the wiki (like extensions).

But @zkanda is right I'll close this issue.

@luizberti feel free to open a different issue regarding moving the docs to a github wiki.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants