Skip to main content

Change requests

Zenzic is a static content analysis framework for Markdown documentation. We aim to support a wide range of use cases, and change requests are an essential mechanism for ensuring that our software meets the needs of our community.

How we manage change requests

We highly value every idea or contribution from our community, and we kindly ask you to take the time to read the following guidelines before submitting your change request in our public issue tracker. Before submitting a new idea, please take a moment to read [how we manage change requests].

Before creating an issue​

Before you invest your time filling out a change request, please answer the following preliminary questions to determine if your idea is a good fit for Zenzic.

It's not a bug, it's a feature​

Change requests are intended to suggest minor adjustments, propose ideas for new features, or provide input to the project's direction. They are not intended for reporting bugs — please refer to our bug reporting guide instead.

Look for sources of inspiration​

If you have seen your idea implemented in another tool, gather enough information about its implementation before submitting, as this will help us evaluate potential fit more quickly.

Keep track of all search terms and relevant links, you'll need them in the change request.

Issue template​

Our change request template consists of the following parts:

Title​

A good title is short and descriptive — a one-sentence executive summary of the idea, so the potential impact and benefit can be inferred at a glance.

Context optional​

Provide additional context to help us understand what you are trying to achieve. Don't write about the change request here.

Why this might be helpful: some ideas might only benefit specific settings or edge cases. Context helps us prioritize more accurately.

Description​

Provide a detailed and precise description of your idea. Explain why it is relevant to Zenzic specifically.

  • Explain the what, not the why – focus on describing the proposed change precisely. Benefits belong in Use cases.

  • Keep it short – be brief and to the point.

  • One idea at a time – open separate change requests for unrelated ideas.

Provide relevant links to issues or documentation sections related to your change request, including any prior community discussions.

Use cases​

Explain how your change request would work from an author's and user's perspective — what's the expected impact, who will benefit, and would it potentially break existing functionality?

Visuals optional​

If you have sketches, screenshots, mockups, or examples from other tools, share them here. You can drag and drop files into the text area or include links.

Checklist​

Thanks for following the guide and creating a high-quality change request. The checklist ensures that you have read this guide and provided us with every piece of information to review your idea.

We'll take it from here.

How we manage change requests​

Change requests are submitted as issues on our public issue tracker. Here's how we handle them:

  1. We read and review the request to understand the idea.
  2. We may leave comments to clarify intent or suggest alternatives.
  3. If the idea is out of scope, we will close the request and explain why.
  4. If the idea aligns with the project's vision, we'll move it to our backlog.
  5. Otherwise, we close the request to keep the issue tracker focused on bugs.

Rejected requests​

Your change request got rejected? We're sorry for that. We understand it can be frustrating, but as maintainers we always need to consider the needs of our entire community.

The following principles (in no particular order) form the basis for our decisions:

  • Alignment with the vision and goals of the project
  • Compatibility with existing features
  • Effort of implementation and maintenance
  • Usefulness to the majority of users
  • Simplicity and ease of use

If you're unsure why your change request was rejected, please don't hesitate to ask for clarification.