-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Turning project Wiki into a community hub? #382
Comments
So this discussion hasn't seen any movement in some time now, but here's a new thought: What if instead of hosting docs in the Wiki, we turned into a hub for community resources? Right now we have 2 issues in the tracker concerning nothing but what projects use Sanic and where it's being used, namely #396 and #292. What if we forgot about migrating the docs, turned the wiki into a shrine of community resources instead? Sounds like it could be useful to have a centralized listing of these things, and moving them away from the issue tracker. Curious to hear thoughts on this. |
Sounds like a better idea than moving the docs according to comments. I don't see why wiki docs is such a big deal tbh, its a better idea than having them moved offsite and having "allowed" people to change, because they are the ones the most busy, meaning the docs won't update as the code updates. There will only be large updates late into future. Tons of legit projects on github use the wiki without issue. Even a simple disclaimer of unofficial docs could be added to slay those naysayers. |
tagging #699 |
Just read the Wiki and noticed it sorta became a hub for examples. Closing this... |
As proposed in issue #321 it might be an interesting idea to move a copy of the docs to the GitHub Wiki, as it tends to reduce the barrier to contributions for having a simplified interface and workflow.
Given that one of Sanic's biggest shortcomings right now is the lack of documentation regarding several portions of the source code, something that might increase contributions should not be so quickly frowned uppon.
While there is a strong argument for keeping docs checked in and versioned with code, revolving around the benefit of always having docs for the current version you're working on in the source even if you roll back, as of right now the existing documentation poorly reflects the capabilities of the software.
I think it would be more beneficial to the community, especially on such a rapidly changing project, to enable the documentation to evolve as rapidly as the source itself does. This is still pre 1.0 software, and I think there's more benefit in leveraging that we can still get a pass on having less strict versioning rules if it results in a more complete docset. Besides, nothing keeps us from syncing the docs into the repo when tagging new releases.
The text was updated successfully, but these errors were encountered: