How to Access Community Support for Macro Inc.: Github Issues, Discussions, and More

You can access Macro Inc. community support through three primary channels: GitHub Issues for bug reports, GitHub Discussions for general questions, and real-time chat via Slack or Discord when linked in the repository.

Macro Inc. is an extensible, micro-service-based workspace that unifies messaging, documents, tasks, email, and AI-assisted tools under one permission model. Because the platform is open-source, the developers have structured all community support around GitHub and linked communication platforms. This guide shows you exactly where to go for help and how to write requests that get fast, useful responses.

Primary Support Channels

GitHub Issues

Use GitHub Issues when you need to report bugs, request features, or troubleshoot specific problems. The macro-inc/macro maintainers review new issues regularly and encourage community members to comment with workarounds or reproducible steps.

According to the README's "Macro Mail … support channels" section, this is the preferred channel for anything that might require code changes.

GitHub Discussions

For general usage questions, "how-to" topics, and best-practice sharing, use GitHub Discussions. Discussions are indexed, searchable, and allow community members to up-vote helpful answers. The repository's front page includes a Discussions tab automatically generated by GitHub for all public projects.

Community Chat (Slack or Discord)

When available, the project posts Slack or Discord invite links in the "Community" or "Support" sections of README.md or CONTRIBUTING.md. These links direct newcomers to channels where developers and users can chat in real-time. Check these files for the most current invite links.

How to Report Problems Effectively

The CONTRIBUTING.md file defines a structured workflow that speeds up resolution:

1. Search existing issues — Use the issue tracker's search bar to avoid duplicate reports.
2. Provide a minimal reproducible example — Include relevant code snippets, configuration files, and log output.
3. Tag the appropriate component — Macro's architecture spans multiple isolated services. Tagging ensures the right maintainers see your request.

Service-Specific Troubleshooting

Because Macro's services are isolated crates, the repository provides per-service README files with component-specific guidance. For example:

• services/document_storage_service/README.md — Database migration steps, local development commands
• services/email_service/README.md — SMTP configuration and testing procedures
• services/search_processing_service/README.md — Indexing troubleshooting

Reviewing the README of the service you're having trouble with often resolves issues without community assistance.

Code Examples for Support Requests

Use these templates when opening GitHub issues or discussions. They follow the repository's issue-template conventions and give maintainers the context they need.

Example 1: Reporting a Failing Migration

## Problem

Running `just migrate_db` for `document_storage_service` fails with:

error: relation "documents" does not exist

## Steps to Reproduce

1. Clone the repo and run `just setup_macrodb`.
2. Execute `just migrate_db` from the repository root.
3. Observe the error above.

## Environment

- OS: Ubuntu 22.04
- Rust toolchain: 1.77.0
- Docker Compose version: 2.23.0
- Database: PostgreSQL 15 (default Docker image)

Example 2: Asking for Integration Advice

I'm extending the Unfurl service to handle a new URL pattern. The current architecture supports adding parsers via `parse_custom_title()`. Could anyone share an example of registering a new parser and writing tests for it?

Relevant files:
- `services/unfurl_service/CUSTOM_PARSERS.md` – outlines the extensibility model.
- `services/unfurl_service/src/lib.rs` – contains the parser registry.

Key Files for Community Support

File	Purpose
README.md	High-level platform description and primary "support channels" link
CONTRIBUTING.md	Workflow for reporting bugs and requesting help
services/*/README.md	Service-specific troubleshooting steps and local-dev commands
docs/STYLE_GUIDE.md	Coding conventions for code-review assistance
.github/ISSUE_TEMPLATE/*	Templates ensuring you include all required details

Summary

• GitHub Issues — For bugs, feature requests, and troubleshooting with reproducible steps
• GitHub Discussions — For general questions, how-to topics, and best practices
• Service READMEs — First stop for component-specific problems before escalating
• Structured reports — Include environment details, reproduction steps, and relevant file paths to get faster responses

Frequently Asked Questions

How do I know whether to open an issue or a discussion?

Open a GitHub Issue when you've found a bug, need a feature, or have a problem with clear technical symptoms. Use GitHub Discussions when you're asking "how do I..." questions, seeking architectural advice, or sharing configuration approaches. The maintainers will redirect you if you choose the wrong venue.

Which maintainers handle which services?

Tag your issue with the appropriate service name (e.g., document_storage_service, email_service, search_processing_service). The repository's code owners file routes tagged issues to the developers responsible for each micro-service. You can find service names in the services/ directory structure.

What if I need help but can't share my code publicly?

Check the README and CONTRIBUTING files for a security contact or private support channel. Some open-source projects offer security@ email addresses for sensitive issues. For general usage questions, try to create a minimal example that reproduces your problem without exposing proprietary code.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}