Closed Feature Requests

I recommend leaving feature requests unsolved which have a workaround (or other resolution), but not an official feature implementation. For example Ability to create a line divider lists a hack and Rem Reference Aliases references a roadmap item.

After all the Feature Requests should reflect the current state of RemNote.
What do you think?



The community should have a place to discuss a feature/idea until it’s actually implemented.

1 Like

I don’t know. If the developers have committed to a path, it’s useless to be discussing very different alternatives.

Discussions about workarounds, they are useful to have but, do they really belong to the “feature requests” category? If the discussed feature is on the roadmap but the thread has useful information, it could be moved to a more appropriate category, I suppose.

1 Like

Let’s take “Dividers” as a simple example to discuss your concerns:

  • Being on the roadmap means for the devs: “We think this is useful and fits RemNote and we want to implement it at some point.” It does not mean that they already have an idea if it should be 1 or 2 pixel high, have a shadow, how it could be inserted (shortcut, /divider or /hr. I think you underestimate how much a feature can change between planning and final implementation.
  • Workarounds are useful as temporary solutions. Maybe someone drops RemNote because he can’t divide his sections with a line? (Stupid example, I know). Generally workarounds can be a series of steps to accomplish the same thing as a feature whould do in one step. You are right that they do not exactly shape a feature, but I think they should be documented in conjunction with the request because:
    • They make concrete what someone wants to accomplish.
    • They can somehow shift the priority for a feature (no workarounds have higher priority).
    • And it makes a nice thematic grouping since workarounds would have to be visibly linked to the corresponding feature request anyway.

Also: The Feature Request category can serve as a base for a public roadmap where the votes are the priority of a feature, i.e the rough order in which features are implemented.


I agree. If it’s on the roadmap in such amorphous state, it would be useful to keep it open. But if there’s something more concrete in the minds of the devs, it could be closed with a link to the thread on the workaround. I figured voting could still be available even if the topic was closed for discussion, but yes, that sounds useful in all cases.

1 Like