Erlang good first issues

The EDoc link resolver generates incorrect URIs for online documentation. Specifically, it includes an extra '/doc/' segment and uses an incompatible format for fragment identifiers (e.g., '-1' instead of '/1'). This prevents users from correctly navigating to the intended documentation pages.

This issue proposes adding new fields to existing Exhook request structures to improve device status tracking and topic authorization. Specifically, it requests the addition of `connected_at` and `disconnected_at` timestamps to client connection/disconnection requests, and a `QoS` field to client authorization requests to enable more granular control over topic subscriptions.

When building Erlang/OTP from a Git checkout with GNU Make 4.4 or later, the emulator version banner incorrectly reports '[source]' instead of '[source-<sha>]'. This is because GNU Make 4.4 no longer remakes `.PHONY` makefiles, preventing the `gen_git_version.mk` script from running and thus failing to capture the Git SHA for build provenance.

A regression introduced in OTP 28 prevents applications from reading control bytes like Ctrl+O, Ctrl+C, Ctrl+S, and Ctrl+Q as raw data when using prim_tty's raw mode. This is because the options to disable ISIG, IEXTEN, and IXON were removed, impacting third-party terminal UIs that relied on this functionality. A potential fix is proposed through the public shell:start_interactive/1 API.

This issue requests that the OTP library's public_key module be updated to tolerate `PrintableString` (ASN.1 tag 19) for the `DomainComponent` attribute in certificates, as some devices incorrectly encode it this way instead of the expected `IA5String` (tag 22). The reporter also suggests considering tolerance for `SerialNumber` encoded as `utf8-string` (tag 12) instead of `restricted-string` (tag 19), similar to existing workarounds for other attributes.

This issue proposes enhancing error reporting in the compiler to provide more precise source code locations. Currently, errors only point to a single character, but the goal is to support source ranges, allowing errors to highlight the entire relevant expression or construct for better debugging.

The Compilation Manager (cm) in the project is failing to detect type errors in applications within an umbrella project structure. Specifically, when using `rebar3 new umbrella` and specifying a sub-application with `-S`, `cm` does not identify any source files, preventing it from performing checks.

This issue proposes an enhancement to the type checker to improve dead-code detection. The goal is to make the handling of diverging expressions (like those in sequences or case scrutinees) consistent, ensuring that unreachable code is correctly identified and ignored by the type checker. This involves modifying the solver to handle disjunctions for unreachable code detection, allowing it to re-evaluate constraints when a path is found to be impossible.

This issue proposes a new Elvis linting rule, `max_native_record_fields`, which is analogous to the existing `max_record_fields` but specifically targets native records. The goal is to enforce a maximum number of fields in native record definitions to improve code readability and maintainability, similar to the rationale for tuple records.

This issue proposes creating a benchmark for type narrowing, inspired by a recent Elixir release. The goal is to measure the performance of type narrowing, likely within a specific programming context or tool.

The build process for Erlang/OTP versions 29.0 and 28.5 fails on AIX 7.3 (ppc64le) due to an error in the `make/doc.mk` file within the `lib/parsetools/doc` directory. This error occurs because the target pattern in the makefile is invalid, likely due to how documentation targets are defined or processed on this specific platform.

The current release handler suspends processes sequentially, leading to longer upgrade times and extended suspension periods. The proposed solution is to suspend processes concurrently to improve efficiency. The contributor is willing to help but seeks guidance on the design due to potential complexities.

This issue is a continuation of a case study on `jsone`, focusing on typechecking its functions. The primary task is to categorize newly introduced `?` functions, which likely involve handling optional or nullable values.