Shortlinks (fuchsia.dev/go) are intended to be durable, have a meaningful name, and be of general interest. The links are durable and use a flat namespace, so it is desirable to carefully consider each proposal to limit the number of created short links.
Reviewers should consider the following factors to approve pending short link requests:
Will the proposed link be relevant for a long time? Links are intended to be durable, so you should be reasonably confident that a link will continue to be of general interest for a long time.
Positive example: A general Fuchsia FAQ page or the current list of supported hardware. Even though they will change over time, the topics will be relevant indefinitely.
Negative example: An RFC proposal that is under consideration. While the proposal is currently relevant, it will be either accepted or rejected. If accepted, it may be a suitable short link topic for reference.
Does the link cover a general topic or concept? Is it relevant for a wide audience?
- An overview of FIDL. This is a fundamental technology used by Fuchsia.
- The Fuchsia security model. This is of interest to both users and developers.
- Documentation for a single system call. A link to the list of system calls would be more relevant.
- Instructions for booting a specific model of NUC over Ethernet. A link to a more general page on booting Fuchsia on categories of devices would be of interest to a wider audience.
Does the link duplicate an existing easy-to-use link that is unlikely to change?
- Positive example:
is unlikely to change, so is probably redundant.
- Positive example:
Is the link name meaningful, and does it comply with the Respectful Code policy? Short links should be, of course, short, but not at the expense of being understood.
Positive example: Both of these examples are short and descriptive:
/docs/go/faq(renders as fuchsia.dev/go/faq).
/docs/go/hardware-specs(renders as fuchsia.dev/go/hardware-specs).
tolink point to a document inside of the