-
Notifications
You must be signed in to change notification settings - Fork 130
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
📝 Punctualize, stylize CLI Guide #1013
Comments
Hi, @JFWooten4! Thanks for your continued attention and effort toward making our documentation as accessible as possible, for both readers and contributors! The particular example you bring up, is another instance of our content being "generated at build-time," although through a different means than it is for the OpenAPI docs in #991. You bring up a really good point, though. The places where we are doing this kind of "trickery" isn't well-documented, and isn't obvious to the contributor how someone might go about just fixing a stinkin' period 🤣. I think we can accomodate a bit of both approaches 1 and 2, as you outlined above:
|
What problem does your feature solve?
Re @ElliotFriend in #991, there are a number of pages which are materially-difficult to edit. One such page has an obvious typo whereby there is no period at the end of a sentence, which might be caused by a lack of a functional
✏ Edit this page
button. 🤔 Might we make it easier to rectify this and future typos for further contributions, and maybe even entice creative permissionless innovation?1 At a minimum, the diction across the Guides might benefit from consistent "proper" syntax.What would you like to see?
I can think of two solutions to this challenge. 💭
Preferred Simplicity: 🌌 Change the edit links to reference the actual base page via yarn build settings.
Technical Explainer: 👩🏭 Add
README
explainers to the direct pages to edit in GitHub for all instances2 where this happens.3What alternatives are there?
We could leave it as challenging as it is to edit a relatively large amount of the Stellar docs. While this could be an easier approach, I think we can look at the state of XRPL's documentation to see just how well the closed-source approach works. Might we make crowdsourced documentation a staple of the network? 🤝
Footnotes
Innovation in the sense that anyone could easily ready, ideate, and upgrade the docs. 💡 ↩
This issue presumes we can identify all the places in the code where this phenomenon happens. As I understand it, Tyler originally migrated this guide, but others likely have a wholistic concept on the infrastructure side. 👨👩👧👦 ↩
One option could be to duplicate instructions for each placement in the parent directory of the rendered source host. 📂 ↩
The text was updated successfully, but these errors were encountered: