PIP-228: Refactor Information Architecture of Pulsar Client Documentation

- Status: Accepted/Development in Progress
- Author: momo-jun
- Pull Request: https://github.com/apache/pulsar-site/pull/393
- Mailing List discussion: [Discussion](https://lists.apache.org/thread/bv6lwnt708dxst173knyzv2bfy4d1ox4), [Vote](https://lists.apache.org/thread/5g0mhvks90nx4sh7fnpmkqj6k2dvxjpp), [Staging/Review](https://lists.apache.org/thread/tgtgzlg286row231tlzxj9dos0tbxcz8).
- Release: 3.0.0 (tbd)

### Motivation

This proposal is focused on refactoring and improving the information architecture of the existing Pulsar client documentation. The benefits it can bring include:
- Improve the developer experience and help them get started by offering bite-sized basics.
- Build a solid content structure to make the doc set easier to increment and scale.
- Contribute to decision-making and Pulsar adoption.

### Goal

The following major issues of Client docs can be improved in terms of information architecture.
- The [Client concepts](https://pulsar.apache.org/docs/2.10.x/concepts-clients) topic does not introduce the basic client concepts and can be enriched with content relocated from other topics.
- Feature concept topic, e.g.,[ messaging](https://pulsar.apache.org/docs/next/concepts-messaging#compression), also includes concept/reference information of clients that should have been decoupled. For example, the content of Producers/Consumer and their attributes (send/access/receive modes) belongs to the scope of [Client concepts](https://pulsar.apache.org/docs/2.10.x/concepts-clients).
- The structure of Pulsar client library docs (e.g., [Java client](https://pulsar.apache.org/docs/2.10.x/client-libraries-java)) also compiles everything in one page:
- Lack of information typing/sorting - various types of information are coupled together, which makes it difficult to navigate and digest.
- Redundant: each client’s doc page somehow mirrors a few basic/advanced dev tasks for specific Pulsar features - overlapping feature IA and contents. Being isolated from feature contents (without single-sourcing) also makes updates easier to be missed when incremental improvements are implemented for feature contents.
In a nutshell, keeping the IA as is will make client doc more complex in both reading/consuming and developing/maintaining, especially when it scales with more features/supports added in the future.

In a nutshell, keeping the IA as is will make client doc more complex in both reading/consuming and developing/maintaining, especially when it scales with more features/supports added in the future. The goal of this PIP is to tackle this challenge by applying the following strategies:
- Make the overall content well-organized, bite-sized, and robustly linked.
- Curate a Get Started section for language-specific clients with minimum basics, such as installation, hello world examples, and links to more topics, which can be advanced dev tasks, feature contents, feature matrix, etc.
- Curate a couple of new topics to introduce advanced dev tasks regarding working with clients.

### Implementation

The following figure shows an example of the IA redesign work BEFORE & AFTER.

**Key changes**
- Concept, task, and reference types of information for Pulsar clients are well categorized and linked.
- The structure of Client Libraries is simple and straightforward to get developers started, from installations to hello world, with rich links only to more advanced tasks and feature contents. All topics are task-oriented with a clear purpose around using Pulsar features and branching into different languages.
- The new IA also enforces the same substructure of dev tasks to introduce how to work with language-specific clients with a sense of consistency. Language-specific code snippets are displayed via tabs.

**Task Breakdown**
- Implement the IA changes with content mapping
- Update doc and add incremental changes to align with code
- Curate an independent page for the client-feature matrix ([PIP-199](https://github.com/apache/pulsar/issues/17098))

### Reference
- Examples of client library docs: [Aerospike client library docs](https://developer.aerospike.com/client) can be a real-world example of what this proposal will direct to.
- Preceding works that relocate a couple of redundant dev tasks with examples to refactored feature docs:
- https://github.com/apache/pulsar/pull/18242
- https://github.com/apache/pulsar/pull/17666
- https://github.com/apache/pulsar/pull/17615