Contact

The fastest way to get a response is to open a public GitHub issue. Use email only for security and privacy matters.

1. Channels

• Bug reports & feature requests — GitHub Issues. Public, searchable, and benefit other users with the same problem. Most bugs are fixed within a few days.
• Security disclosures — email [email protected] with the subject prefix [security]. Please do not file security issues publicly until we have had a chance to respond.
• Privacy questions — see the privacy policy; for anything not covered there, email [email protected].
• General feedback — a GitHub issue tagged "feedback" works well. There is no mailing list and no Discord.

2. How to file a good bug report

A good bug report includes:

1. What you expected to happen. A single sentence is fine.
2. What actually happened. Include any error message verbatim, or a screenshot if it is a visual issue.
3. Steps to reproduce. The exact Markdown input and the sequence of clicks that triggers the bug. If the bug requires a specific image URL, include the smallest possible sample.
4. Environment. Browser name and version, operating system, and whether you are on the latest deployed version (the version number is shown in the changelog).

3. How to file a good feature request

Tell us:

1. The problem you are trying to solve. Not the solution — the problem. We have said no to many good ideas because they did not actually solve the user's underlying need.
2. How you currently work around it. The workaround is often more informative than the proposed fix, because it tells us what tools and formats you are already using.
3. Examples from other tools. Links to how Pandoc, Typora, Notion, or other converters handle the same problem are very helpful.

4. Response time

markdowntodoc is a small, independently maintained project. Realistic expectations:

• Bug reports: initial response within 3–5 business days.
• Security disclosures: within 48 hours, usually faster. We will acknowledge receipt and propose a disclosure timeline.
• Feature requests: no commitment on timeline.
• Pull requests: code review within 1–2 weeks for small PRs, longer for large ones.

5. Custom development and consulting

We do not offer paid support, custom development, or consulting. The source code is open and you are welcome to fork it. If you need a Markdown-to-Word feature for a production system, we recommend Pandoc as a battle-tested alternative.

6. Abuse and takedown

If you believe content accessed via the image proxy infringes your copyright or other rights, email [email protected] with the subject prefix [takedown] and include the URL, a description of the work, and your relationship to it. The image proxy does not retain content after the request completes, so there is nothing to remove from our side; we can however block the source domain from being proxied in the future.