How does LifterLMS handle Feature Requests?

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

You can use the browser’s find command (Ctrl + F or Cmd +F) to find a particular feature. Every feature card shows the number of votes and comments added to it.

Click on any feature card to open it and add your vote and comment.

Features that receive the most votes and details are more likely to be considered for the next stage of development. You could help a lot by providing mockups, designs, use cases, expected step-by-step user experience, etc. So, add as much detail about the feature as possible.

If the feature you need isn’t present on this board, head over to the Feature Request Submission form. Again, add as much detail as possible.

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.

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.