Web GUI Feature Requests

web-ui

#1

Loving the Web GUI. Some Feature Requests:

  1. Add check boxes (or some means) in the “Send email after completion” dialog to allow “only if errors occur” or “only if successful”.
  2. Ability to graphically display repository history (especially useful when restoring, but also when considering what to prune if space is low).
  3. Ability to graphically display results of a diff between two revisions.
  4. Ability to search for a given file (perhaps a powerful but likely complex way to do this would be a view similar to Dropbox, allowing you to search and review historic versions of a file).

Keep up the great work - this is a fantastic product!


#2

Although these are nice ideas, (i’m just asking here) wouldn’t it be better if all of your requests are different posts? In this way i think tracking (via tags like #planned or #implemented) would be a little easier as it will be done for each different request.

Basically i’m asking if it would be a better idea not to use kitchen-sink feature requests .


#3

… and we avoid a “multi-topic” topic.


#4

I get your point. I didn’t want to spam the forum with my feature requests. The only problem with using tags is that I don’t know which suggestions, if any, @gchen wants to be #planned or #not-planned

I’ll let @gchen or any admin decide how to split this up, if desired.


#5

This is ok to me. I’m overdue for a ‘feature plan’ post that can serve as the centralized place to manage feature requests like these.

As for these requests, 1 and 2 can be implemented relatively quick while 3 and 4 may incur significant work.


#6

I think there are (at least) two aspects to consider regarding feature requests.

  1. It’s nice to have a (public) roadmap where planned features are listed in order or priority and, as much as possible, with an indication which release they are planned for. I suppose that is what you mean by “feature plan”.
  2. Before feature requests end up on the road map, they should be discussed. Even very straightforward and simple suggestions can often be tweaked to become even better. Others are may require user input in order weigh different options against each other and to understand their implications. This is what topics in the #feature category are for. And since multi-topic topics are difficult (if not frustrating) to read, we try to keep them focused on a single topic (not only in the #feature category) and encourage multiple posts rather than one.

That said, it is, sometimes difficult to determine whether something is a single topic with multiple sub-points or multiple topics. To decide whether A and B should be in a single topic or in multiple topics, it’s probably a good idea to ask yourself whether separate discussions are likely to include similar questions or even whether discussing A will inevitably lead to discussing B (or vice versa).

If in doubt, start with multiple topics. It’s easy to merge topics into one, it is impossible split a topic into separate topics once there is a reply that refers to more than one of these topics.

Oh, and perhaps there is a third aspect:

  1. When users read about a feature request, they should be able to see whether this feature is already #implemented, #planned or whether it has been rejected (#not-planned). Tagging posts in this manner will also make it easier to compile a roadmap. Since @gchen is the one to make these decisions, he should apply those tags.

#7

@gchen, @Christoph i suggest for “release roadmap” to follow what the discourse people are doing:
have a master release topic, which links to all the discussions related to the features.

As of 2019.02.22 this is how

As you can see each major change contains a dedicated topic for discussion (linked there), and they are :white_check_mark:ed whenever they are implemented.

(@gkoerk this is my reason for not wanting kitchen-sink feature requests from users)


#8

Okay - broke them out into separate topics. Another way I’ve seen projects handle this is via an actual “feature request” issue on GitHub, where it is discussed amongst developers and then implemented and tracked there if desired. However, features like I’m proposing have no technical implementation proposals, so the forum may well be the best place for things like this. Feel free to close this topic or leave it open for discussion about how to handle Feature Requests.


#9

The 4 requests are:

Feature Request: Conditional email sending after job completion
Feature Request: Graphically Display Repository History
Feature Request: Graphically Display Diff Between Revisions
Feature Request: Search Backups for File / See File History


Since the 4 features are now separate topics, I set this thread to close in a week. That should be more than enough time for anyone to add anything to this “how to organize the forum” topic (since this seems to be its new purpose :smile:).


closed #12

This topic was automatically closed after 3 days. New replies are no longer allowed.