Start with the maintained documentation

• Documentation index for the available guides.
• Guided setup for the initial configuration workflow.
• Administration and storage and backup for operating notes.
• Protocols and client compatibility for client testing.

Describe your intended setup

Record the commit, host system, mail domains, clients and network path before a test. Explain where incoming and outgoing mail should travel and whether another gateway or reverse proxy is involved. Keep a test installation separate from the only copy of your live mail and configuration.

Bring a focused question

For setup questions, identify the configuration stage. For client problems, name the client and protocol. For delivery problems, provide the relevant redacted log sequence and expected route, without including message contents or credentials.

Use the dedicated Bongo forum for configuration questions, client compatibility, administration and development discussion. This page is a starting point; the repository documentation remains the reference for supported options and implementation status.

Find the project

Start with the Archie repository on Gitea. The tree contains the Archie and Prospero sources, configuration examples, manual material, build files, service definitions, a Web component and integration tests. Refer to that tree for the supported build and service configuration at the commit you are using.

Three questions to separate

• Indexing: which FTP archive is being examined, and was its directory information collected?
• Search: does the expected filename exist in the index, and what query was submitted?
• Access: which client or interface made the request, and did it reach the intended service?

Keeping these questions separate makes a report much more useful than simply saying that a file cannot be found. A search result points to an archive location; it does not guarantee that the remote file is still available or grant redistribution rights.

Share a useful result

Include the repository commit, host operating system, build result, interface used, search expression and expected filename. For indexing problems, include the relevant archive and a short log excerpt. Use public test archives or your own controlled setup, and keep account credentials out of reports.

The dedicated Archie forum is for setup questions, indexing and search results, historical material, and development discussion. Confirmed defects and patches should also be linked to the repository.

A simple report structure

1. Goal: what are you trying to do?
2. Environment: operating system, hardware or emulator, software version and relevant configuration.
3. Steps: the smallest sequence that reproduces the result.
4. Expected and actual result: include the exact error, not only a paraphrase.
5. What you tried: explain changes and whether they helped.

Keep the public record useful

Choose the closest forum section, use a descriptive title and link the blog article or repository that prompted the question. Remove passwords, tokens, private addresses and personal data from logs before posting. Registration and email validation are required; submissions can require moderation before they become publicly visible.

When a solution works, reply with the tested versions and the final steps. Suggest a documentation correction when an RTFM page is unclear. The resulting guide should state its scope and link back to the discussion instead of hiding the assumptions that made it work.

Include the essentials

• Host and target operating systems and architectures.
• Compiler, assembler, linker or runtime versions used by that project.
• The commands you ran, relevant build options and any local changes.
• The first meaningful error, or a concise account of a successful test.

For packaging and ebuild questions, use the Gentoo package forum. For DOS tools, drivers and other software, use the project forums. Keep broad design discussion in the forum and attach a focused patch or reproducible defect to the matching repository.

Before contributing, check the repository's license and contribution instructions. Preserve attribution for upstream and forked code, and avoid mixing unrelated changes into one report or patch.

When asking about an older article

Link the article, state the exact software version and operating system, and describe the operation: splitting, merging or another action. Include a small non-confidential example if one is needed to explain the problem. Do not upload private documents.

Separate a problem reproducing a historical version from a request about a different release. This makes it clear whether the answer should explain the archive, the original code or a newer environment.

Use Software, Drivers & Tools for questions and findings. A short, reproducible solution can later become a focused RTFM page.

Record the inputs

State the repository commit or release, build environment, target operating system and the origin and version of your own installation media. Follow the selected repository's README for the actual build steps; options and requirements belong to that version.

Describe the test

1. Use a disposable test disk or virtual machine and record its hardware configuration.
2. List the installer selections and any configuration changes.
3. Check what was installed, whether the target boots and which drivers load.
4. Report the first failing step, the exact message and the expected result.

Do not include commercial disk images, license keys or private files in a public report. Share the report in Software, Drivers & Tools, then open a repository issue when the problem is reproducible.

Mystic BBS and Disconnected by Peer

• mystic-theme: the Disconnected by Peer BBS theme.
• mysticd: the repository currently containing the existing Mystic installation scripts and integration files. The planned management daemon is future development; its planned administration, backup and plugin features are not presented here as completed functionality.
• BBS DokuWiki: BBS-specific documentation, separate from this English-language site, with German and English material.

DOS, drivers and tools

GitHub includes Open386MAX, GeosOne Dual Installer, classic-Windows and DOS tooling, storage drivers and other experiments. The retro-computing entry page groups the most relevant starting points. Gitea also contains projects such as Archie; consult their own documentation before choosing a build or deployment procedure.

Questions, bugs and contributions

Use the project forums for design discussions, help and test reports. Use the specific repository's tracker for a reproducible defect or a proposed change. Link related discussions in both places so the context remains discoverable.

Start with the sources and release notes

The mars-nwe repository is a source-code starting point. The blog contains the mars_nwe 0.99.pl26 and v0.99.pl27 release posts. Treat those posts as records of those releases, rather than a promise that an old configuration matches every current host.

Describe both ends of the connection

• Server operating system, mars_nwe version or commit, and relevant build options.
• Client operating system and NetWare client or requester version.
• Network path, protocol configuration and whether an emulator or virtual network is involved.
• The operation being tested: login, volume access, file transfer or another specific function.

Post questions and redacted configuration excerpts in the Novell, NetWare & mars_nwe forum. Include working combinations as well as failures: a clearly documented successful test is useful to the next person restoring a similar system.