How does LifterLMS handle Feature Requests?

Before Submitting a Feature Request

# Top

Before submitting a feature request, please check if it is already listed on the LifterLMS Road Map and Feature Voting trello board.

There are many ways to search this Trello board for existing feature requests. The most straightforward way is to use the Search field in the screenshot below. However, this may not always work as expected.

Search field in Trello.

How to search in Trello.

In cases like this, you have two options: use advanced search or use a keyboard shortcut.

Advanced Search


Click on Advanced search shown below to perform an advanced search.

Advanced search button.

On the screen that loads, click on the LifterLMS Road Map and Feature Voting under Filter cards by Board. That step allows you to see the search results, as shown below.

Click on the LifterLMS Road Map and Feature Voting under Filter cards by Board.

Keyboard Shortcut


Note that you can avoid performing advanced search by just using the browser’s find command (usually Ctrl + F on Windows/Linux or Cmd + F on macOS) to find a particular feature, as shown below.

Using keyboard shortcut to search.

Every feature card shows the number of votes and number of comments added to it.

To vote on a feature request, click on any feature card and add your vote. You can also leave a comment if you want to give additional detail or use-cases for this feature.

To vote on a feature request, click on any feature card and add your vote.

What happens after a Feature Request is submitted?

# Top

Once you submit a feature request, it goes to the support and development team for review. A member of the support team will get back to you and may ask you a few questions to get more clarity. All such feature requests are tagged in the support software:

In addition, during the course of support or other conversations, the LifterLMS team may identify something as a feature request even though it hasn’t been submitted as such.

All such feature requests are also added to an internal (private) Trello board where they are logged, organised and tracked. They are then discussed internally within the team on multiple occasions:

  • A weekly team meeting where any new feature requests or user feedback is discussed briefly.
  • An internal monthly feature request scrub where all these features are discussed one by one, in detail.
  • They are also discussed asynchronously from time to time, on our internal slack channels.

Each feature request is considered in the context of various factors. The demand for a feature request is obviously significant. However other factors like the clarity of a feature, feasibility, etc are also important.

Once we have a somewhat clear idea of what the feature would ultimately look like and a lot of folks express a need for the feature directly (through feature requests) or indirectly (during support resolutions), the feature is moved to the public trello board for voting.

How does a Feature Request move into Development?

# Top

As described in the previous section, each submitted feature request is discussed internally with the whole team on multiple occasions in detail before deciding to start development on it.

This depends on a lot of factors, including, but not limited to:

  • How much is the demand for the feature?
  • How clearly defined is the feature? Does it need more inputs or clarity?
  • How easy is it to implement the feature within the current codebase? How much does the existing code need to change to make this new feature possible?
  • What is the potential impact of the new feature on existing features? Is it going to change the user experience drastically?
  • How much resources (manpower and hours) would this feature take? How easily and when are these resources going to be available?
  • How well does the feature align with our internal roadmaps and plans?

As you may notice, a lot of these questions need technical inputs and skills. In addition, they can sometimes get complicated and need a lot of deliberation which can make the progress appear slow.

If you are a developer or have a developer on your team, you could help accelerate this process by getting involved on our slack channel and our contributor site at make.lifterlms.com. Here’s a guide to get you started quickly: https://lifterlms.com/docs/contributing-to-lifterlms/.

If you’re not a developer but would still like to help, you can do so by providing as much detail as possible. This is true for when you submit a new feature request or comment on an existing one.

Last Updated on
Was this article helpful?