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

Update Dev Tools & Resources #359

Closed
waldmatias opened this issue Mar 10, 2024 · 11 comments
Closed

Update Dev Tools & Resources #359

waldmatias opened this issue Mar 10, 2024 · 11 comments

Comments

@waldmatias
Copy link
Contributor

Checking docs/tools/developer-tools.mdx we seem to be missing "Hubble (BigQuery)"? I do know there's docs somewhere else, but maybe a link is needed here to those?

Also, looking at Sorobix's cargo.toml it seems they are not actively developing anymore. Perhaps we should take out and add later on if they come back?
@briwylde08 @ElliotFriend

@briwylde08
Copy link
Contributor

briwylde08 commented Mar 13, 2024

Hiya! Hubble's documentation lives in the top nav bar under Network - Data Availability - Hubble alongside RPC and Horizon (https://developers.stellar.org/network/hubble). What do you think about that organization? Is it intuitive enough? Or maybe we do need to mention something in Tools that helps direct people. We could even link over to them under the Data Indexers section.

As for Sorobix, thanks for the heads up, I'm going to do some investigating!

@waldmatias
Copy link
Contributor Author

waldmatias commented Mar 13, 2024

It makes sense to have Hubble with the other data-related items such as RPC and Horizon ... maybe this is just me, but I'm not sure about the "Network" label. Glancing over these names, I somehow feel these are "Services".
BTW, and this just echoing other docs I've come across ... what if:
"Docs" -> "Learn"
"Learn" -> "Build"
"Tools" -> good IMO
"Network" -> "Services"?
... it would be actually good to get some other people's view on this!

@briwylde08
Copy link
Contributor

If you only knew how much we have hemmed and hawed over the terminology!!! We DO plan on adjusting these labels. I think Docs will become Build and include smart contracts in v2. Network is up for debate and I think Services is not a bad label. This merge is only v1 and we welcome all input!

@waldmatias
Copy link
Contributor Author

waldmatias commented Mar 13, 2024

Got it! Though current "Docs" seems like more of a general overview and just about getting your feet wet in how Stellar works. That's why I brought up using a label "Learn".

Also, If you look at the contents of what's now under "Learn", someone would use this content to actually "Build" something on Stellar.

But yes -- naming things is hard, and don't get me started on getting a TOC and content strategy right 😄

@briwylde08
Copy link
Contributor

briwylde08 commented Mar 13, 2024

So the Learn section is mostly explanatory content. Like what is the SCP, how does authorization work, and what is an anchor. It's not actually supposed to tell you how to do anything but more about how things work.

I like "Services" but wonder if setting up a validator fits under that label.

@waldmatias
Copy link
Contributor Author

waldmatias commented Mar 14, 2024

Now that you mention it -- yes, there's some intermingling between content on "Docs" and "Learn", in terms that some content describes what while other goes into how it is implemented or how you could use it to build something. I also have in the back of my mind the old Soroban docs which try to do both.

Perhaps safest route is to first finish the merge and then iterate to reorganize if needed.

However, I would really recommend to have a highly visible "Build" section entirely devoted to the process of going from Zero-to-dApp... which provides more of a dev journey into Stellar than just unrelated tutorials.

@waldmatias
Copy link
Contributor Author

BTW if you want to be picky, then "Network" would be "Infrastructure" and then you would have "Core Infrastructure" (aka nodes) and "Services" (where some people would say "Core Services" and "Boundary Services"). But I don't think there's any need to be so formal!

@ElliotFriend
Copy link
Contributor

Hey, there! So, the (very unofficial, kinda rambly) way I see the "Docs" vs. "Build" vs. "Learn" dilemma is:

  • Remember that the "Docs" section used to be the only section in the docs. All the organizing was done within "Docs." In its current state, it's a bit of a grab-bag of "leftover content" that doesn't neatly fit into one of the newer sections (those being "Learn," "Tools," "Network" (kinda formerly "APIs"), "Reference" (coming soon), and "Smart Contracts" (coming soon also)). The stuff left in "Docs" after "v1" of the merger is just kindof orphaned there.
  • Much of what will be left in the "Docs" section is a lot of pre-soroban tutorials (though, not exclusively).
  • Similarly, the "Smart Contracts" section will essentially be the "leftovers" from the soroban-docs repo that didn't neatly fit into the other, broader categories.
  • These two sections (together) can logically make up a single "Build" section. One is more geared towards smart contract devs and the other is more geared toward (d)application devs. Broadly speaking, those two categories cover most of our dev audience: these two unique (though certainly not exclusive) skillsets are what we've been targeting (intentionally or not) with our tutorials and other "Build"-type docs content.
  • v2 of the merger will likely see a concerted effort to bring these two sections together under a single umbrella, while still providing the wayfinding necessary for someone to have that zero-to-dapp "aha" moment, regardless of which of the two audiences they may relate most to.
  • I keep pushing things off to a magical, someday "v2" of what this will look like, but it's not an attempt to hand-wave the issues away. One of the big goals we're going to achieve with this drive is to get ALL the technical docs under one roof, allowing (critically) a more universal search that will index and return content from the two (previously separate) collections. This'll be a big win on its own. Then, we can fine-tune the structure, layout, calls-to-action, etc. as we understand a bit better how the docs (as a single collection) are being used.

As for the "Networks" section:

  • I'll echo exactly what Bri said about the hemming and hawing we've done already about it 🤣
  • Internally, we've gone through several (dozen?) conversations about what word/words perfectly capture the essence of what we're trying to group here. "Platforms," "Products," "Infrastructure," "Network Infrastructure," "Network," "Data Availability," and so many more were pitched, discussed, brainstormed, etc.
  • At the end of it, I don't know that there is a perfect label for this section. "Network" seemed to get closest in that all the stuff in there is (generalizing here) software to interact with the network. Some runs the network, like infrastructure. Some runs on top of and/or alongside the network, like a software product (anchor/disbursement platform). Some are a means to see what's happening on the network, like services (horizon, hubble, etc.).
  • For me, "Network" seemed like a common enough denominator to run with. It feels clear(er) compared to most of the other labels we considered, and I think it's intuitive enough that people wouldn't be surprised to find anything we've put there. For better or worse, that's my take lol

@briwylde08
Copy link
Contributor

Hear hear!!

@waldmatias
Copy link
Contributor Author

"software to interact with the network" -- that's the definition of a service 🤣

@briwylde08
Copy link
Contributor

Heya @waldmatias! See and participate in naming discussions here: #494
We are adding to the Hubble docs here: #504

Going to close this issue! Excited to see what you think about the naming!

@github-project-automation github-project-automation bot moved this from Backlog to Done in Dev Docs Apr 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants