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

📝 Punctualize, stylize CLI Guide #1013

Open
JFWooten4 opened this issue Oct 1, 2024 · 1 comment
Open

📝 Punctualize, stylize CLI Guide #1013

JFWooten4 opened this issue Oct 1, 2024 · 1 comment

Comments

@JFWooten4
Copy link
Contributor

JFWooten4 commented Oct 1, 2024

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. 💭

  1. Preferred Simplicity: 🌌 Change the edit links to reference the actual base page via yarn build settings.

  2. Technical Explainer: 👩‍🏭 Add README explainers to the direct pages to edit in GitHub for all instances2 where this happens.3

What 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

  1. Innovation in the sense that anyone could easily ready, ideate, and upgrade the docs. 💡

  2. 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. 👨‍👩‍👧‍👦

  3. One option could be to duplicate instructions for each placement in the parent directory of the rendered source host. 📂

@ElliotFriend
Copy link
Contributor

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:

  1. There is custom_edit_url field available in the frontmatter for docs pages, so we can indeed specify what the URL should be for those pages. I almost forgot, but there's an existing issue to address this in the stellar-cli repo: Cookbook files should define the custom_edit_url frontmatter stellar-cli#1608 (there's also the potential of doing this programmatically, akin to how pnpm.io's docs site does for its localized pages. this is achievable, but maybe more of a long-term approach, since it may indeed be complex to encompass the various "edit this page" cases we have.)
  2. I think the start you've made to a CONTRIBUTING.md file is a great effort! We could include in that file a section on "hard to edit" or "not obvious sources" or something like that to document as much of this kind of stuff as we can.

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

No branches or pull requests

2 participants