I suggest recategorize “Development” and “Application & Ecosystem” into
“Infrastructure” / “Infra Development” / … - for developers who build for other builders. All protocol (CKB, Fiber, …) and infrastructure (SDKs, common scripts, debuggers, testing harness, …) dev talks happen here.
“Application” / “App Development” / … - for developers who build for end users.
Both types of builders are vital to the ecosystem, but they differ greatly in their principles and methods.
The category name “Community Space” is also unclear - it could even refer to Nervos Talk itself. A name like “DAOs” could be better, as it’s more specific and suggests governance and treasury-related activities.
Speaking of dev topics, I had a small question about cross-domain discussions under the new category structure.
The old language-based sections had one practical advantage: discoverability was rather good, as people could see most discussions in one place. For infra or tooling projects, a topic may start in infrastructure, but occasionally wander, quite legitimately, into applications, governance, or protocol semantics.
So i guess my question is how infra-oriented work should maintain a sensible path to its downstream users under the new structure? I mean, without drifting too much into self-promotion
Would it make sense to keep the main thread in the most natural category, and only add short linked RFC or milestone posts when the discussion genuinely needs to poke its head into another room? Or would the community prefer such projects to stay strictly within infrastructure for clarity?
I quite like this direction, provided we keep its ambitions modest.
One small concern is that Nervos Talk is not yet suffering from the terrible curse of excessive traffic. So before we build too many elegant little rooms, we should probably make sure there are enough people in the house.
To me, a project log / builder log would work best as a lightweight continuity layer, not as a separate discussion silo. It could be used for milestones, design notes, progress updates, RFC links, test results, and retrospectives. But broader debate, support questions, grant discussion, governance discussion, and ecosystem feedback should still live in the normal public categories.
In other words, the log probably should not become a private chapel for one’s own project. It should be more like a well-kept index, changelog, and map, of a place that preserves context, then points people back to the actual rooms where conversation happens.
That would give long-running work a bit more memory, without further thinning out the already rather precious forum traffic.