Contact

Questions about the documentation, corrections, or suggestions for new topics are welcome. This page covers how to reach the right place depending on what you need.

Documentation Feedback

If you found an error in the documentation, a broken example, or a section that could be clearer, the most helpful thing you can do is be specific. Include the page URL, the section heading, and a description of what is wrong or confusing. Vague reports like "the docs are wrong" are hard to act on.

Send documentation feedback to: docs@tribits.org

Technical Questions

For questions about how to use the TriBITS framework in your project, start with the documentation:

If the documentation does not answer your question, it probably means the documentation needs improvement. Send your question along with what you tried and what you expected to happen.

Security Issues

If you have found a security issue, do not report it through public channels. Send details directly to: security@tribits.org

See also: security.txt

Response Expectations

Documentation corrections are typically addressed within a few days. Feature requests and larger improvements take longer to evaluate. You will not receive an auto-reply, but reports are reviewed.

What Not to Contact About

This is a documentation site for the TriBITS framework. We cannot help with:

  • Issues specific to your project's code (as opposed to the framework itself).
  • General CMake questions unrelated to TriBITS.
  • Job postings, partnership requests, or marketing inquiries.

For general CMake questions, the official CMake documentation and community forums are better resources.

Mailing Address

TriBITS Documentation Project PO Box correspondence is not currently available. Use email for all inquiries.

Other Pages

Tips for Effective Communication

Good problem reports save time for everyone. When writing about a documentation issue or technical question, include enough context to avoid back-and-forth.

For Documentation Issues

Include the specific page URL and section heading where the problem is. If a code example does not work, describe what you tried, what you expected, and what happened instead. If you found incorrect information, include what you believe the correct information is and, if possible, how you verified it. Screenshots can help for formatting issues or confusing layouts.

For Technical Questions

Before sending a technical question, check whether the answer is already in the documentation. Many questions about package configuration, dependency declarations, and test categories are covered in the Guides and Reference sections. If you have already checked and could not find what you need, mention which pages you looked at. This helps us improve the documentation for future readers.

When describing a build problem, include the TriBITS version you are using, the CMake version, the operating system, and the relevant portion of the configure or build output. Sanitize proprietary information before sharing, but keep enough detail for the problem to be reproducible.

For Suggestions

If you have a suggestion for new documentation content, describe the topic and who would benefit from it. Suggestions that include a rough outline of what the page should cover are especially helpful. Even a few bullet points give us a starting point.

Communication Guidelines

Keep messages focused and professional. One topic per email works better than a message covering five different issues. Use descriptive subject lines. "Error in tribits_add_library docs" is more useful than "Question" as a subject.

We communicate in English. We welcome contributors from all backgrounds and geographic locations.

Open Source Participation

TriBITS is developed as open source software. If you are interested in contributing to the framework itself rather than just the documentation, the project's source repository is the right starting point. Contributions to documentation, examples, and test coverage are particularly valuable for the community.

Code contributions should follow the project's existing patterns and conventions. Review the Developers Guide to understand the framework's structure before submitting changes. Small, focused contributions are easier to review and merge than large, sweeping changes.

Acknowledgments

We appreciate all feedback, whether it is a typo correction or a detailed feature suggestion. Every report helps make the documentation more useful for the next person. Thank you for taking the time to write.

Frequently Asked Questions About Contacting Us

How long does it take to get a response? Documentation corrections and straightforward questions typically receive a response within a few business days. Larger requests, such as new page suggestions or feature proposals, may take longer as they are evaluated against the current content roadmap.

Can I request documentation for a specific TriBITS feature? Yes. If a framework feature is undocumented or poorly documented on this site, let us know. Include the feature name, the context in which you need it, and any existing documentation you have found. This helps us prioritize what to write next.

What if I found a security vulnerability? Do not report security issues through public channels or general email. Use the dedicated security contact at security@tribits.org or follow the instructions in our security.txt file. This ensures the issue is handled responsibly before any public disclosure.

Can I contribute directly to the documentation? Yes. If you have improvements ready to submit, reach out with your proposed changes. We welcome pull requests for documentation corrections, new examples, and expanded explanations. Please keep changes focused and well-tested against the current framework version.

Is there a community forum or chat channel? The primary communication channel for this documentation project is email. For broader community discussions about the TriBITS framework itself, check the project's source repository for community resources and discussion forums.