Skip to content

Change requests

Tell us what you need, why it matters, and how it would improve your work. This guide explains how to present an idea so we can evaluate it.

Before creating an issue

Please follow these steps before opening an issue:

  1. Make sure it is a change request. Change requests propose new behavior or improve existing behavior. If something does not work as expected, use our bug reporting guide instead.

  2. Search the project's documentation. The capability you need may already exist, or the documentation may show another way to achieve the same result.

  3. Search the project's issue tracker. Open issues mainly track known bugs. Closed change requests may contain relevant discussion or point to a backlog item.

  4. Search the public backlog. We track change requests under consideration across all projects there. An existing item may cover your idea; subscribe for updates.

If your idea is not covered, create a new change request. The next section explains how to describe the need, proposed change, and relevant use cases.

Don't know where to start? Ask the community in our free Discord channel or, if you're a Spark member, in a public Spark space. If the information you need to share may be confidential, use your organization's dedicated private space, if available.

Issue template

Our Open Source projects use issue templates to make change requests consistent and efficient for requesters and maintainers. They contain the following parts:

Title

Write a short, specific summary of the change you are proposing. Examples:

  • Allow navigation sections to be collapsed by default
  • Add a command for checking links without building the site
  • Show unresolved references in the editor

Context optional

Explain what you are trying to achieve and include relevant details about your workflow. Do not describe the proposed change here; use Description instead.

Why we ask: some needs appear only in particular workflows, environments, or project sizes.

Description

Describe the change you propose and how it should work. Keep its benefits for Use cases, and create separate requests for unrelated ideas.

Workaround: if you already use a customization or another way to achieve the result, share it so others can benefit and we can better understand the need.

Why we ask: a clear description helps us evaluate the scope and identify open questions before discussing implementation.

Use cases

Describe a concrete situation where you would use the change. Explain what you are trying to do, what is difficult today, and how the change would help. If you know of other workflows with the same need, mention those too.

Why we ask: multiple use cases help us understand the broader need and design an implementation that works across different workflows.

Visuals optional

Add sketches, screenshots, or mockups when they make the idea easier to understand. You can drag files into the field or link to external assets.

If you have seen a similar feature or workflow elsewhere, include it and explain what works well.

Why we ask: visuals can clarify layouts or interactions that are difficult to describe in words alone.

Share relevant documentation, issues, discussions, or similar implementations. If you found nothing relevant, write None found.

Why we ask: these links add context and show what has already been considered, helping us avoid repeating the same discussion.

Checklist

Use the checklist for a final review before submitting your request. Confirm only completed steps and provide any missing information so we can begin the review.