opensearch-project / OpenSearch-Dashboards

📊 Open source visualization dashboards for OpenSearch.
https://opensearch.org/docs/latest/dashboards/index/
Apache License 2.0
1.65k stars 862 forks source link

[BUG] "Experimental" and Support SLAs #800

Open stockholmux opened 3 years ago

stockholmux commented 3 years ago

Describe the bug

When visualization and adding a control, there is messaging about support SLAs.

To Reproduce Steps to reproduce the behavior:

  1. Go to Visualize
  2. Click on Create New Visualization
  3. Hover over the "E" on the controls button.
  4. See the weird message about Support SLAs
  5. Click on controls
  6. See weird message "This visualization is experimental and is not subject to the support SLA of official GA features. For feedback, please create an issue in GitHub"

Expected behavior Support SLAs aren't part of an open source project, messaging that reflects this

OpenSearch Version 1.0

Dashboards Version 1.0 Plugins

All standard distribution plugins

Screenshots

If applicable, add screenshots to help explain your problem.

Screen Shot 2021-09-16 at 8 21 26 AM Screen Shot 2021-09-16 at 8 21 19 AM

** Experimental Features List Experimental Advanced settings

Big warning on top of Advanced Settings Experimental settings in advanced settings query.allowWildcards graphiteURLDescription quandlKeyDescription visualize:EnableLabs Experimental visualizations

Input controls viz Vega Map layer Time series datasources

Graphite Worldbank Worldbank Indicators Quandl Other mentions of experimental

These aren't experimental features, but rather provide support and surface messages for experimental features.

Experimental visualizations in visualization picker Experimental Viz banner Functional test page objects Experimental viz functional tests (test file) Experimental Viz tooltip Fetch experimental visualizations Experimental viz icon CSS

tmarkley commented 3 years ago

Thanks for documenting this Kyle! Do you have recommendations on what the new messaging should be? @aetter may have input?

aetter commented 3 years ago

Sure, a lot of it has to do with our attitude towards experimental features going forward. They're not something we've traditionally done, which indicates we should just do quick-fix wording and call it a day. If we plan to include experimental features in our releases with some regularity, though, we can and should put more thought into the wording and aim for more user engagement/feedback.

Quick-fix wording would be something like:

Experimental
We might remove or make major changes to this visualization in the future.

This visualization is experimental. To provide feedback on it, please [submit a GitHub issue](https://github.com/opensearch-project/OpenSearch-Dashboards/issues).
stockholmux commented 3 years ago

I like what @aetter is saying. I would question, though, if this is really experimental from the OpenSearch perspective. Is OpenSearch planning on removing or making major changes? If not, I think it can be trashed all together.

aetter commented 3 years ago

Agreed, yeah, if we plan to leave this feature in as-is for an extended period of time (and not really do experimental features going forward), trashing the message altogether also seems like a fine outcome.

tmarkley commented 2 years ago

Based on our team conversation, we'll want to remove the Experimental flag on Controls and check what else is marked as Experimental. We may need to address other uses on a case-by-case basis.

stockholmux commented 2 years ago

Hooray!

kavilla commented 2 years ago

we'll want to remove the Experimental flag on Controls and check what else is marked as Experimental. We may need to address other uses on a case-by-case basis.

To re-cap, we should have a list of all experimental features, and dive into current experience of experimental features and find out if anything was missing not make it non-experimental. If we do, we should still remove the experimental but address the issues.

For the future though, we shouldn't have experimental features. We should have feature flag stuff that is as close to producation ready as possible.

ashwin-pc commented 2 years ago

Here is a list of all experimental features and their occurrences. I may have missed a few references where these features are implemented, but these should cover all the features themselves

Experimental Advanced settings

  1. Big warning on top of Advanced Settings
  2. Experimental settings in advanced settings
    1. query.allowWildcards
    2. graphiteURLDescription
    3. quandlKeyDescription
    4. visualize:EnableLabs

Experimental visualizations

Time series datasources

Other mentions of experimental

These aren't experimental features, but rather provide support and surface messages for experimental features.

tmarkley commented 2 years ago

@ahopp from the product side do you have thoughts on the path forward for each of these "experimental" features? We need to decide which of them we should improve, which of them can remain the same with different messaging, and which should be removed.

tmarkley commented 2 years ago

Next step: document the state of each of these features individually (GitHub issue for each) in order to determine which path to take.

boktorbb commented 2 years ago

I'll start documenting for each experimental feature/setting. Do we have a preference on moving this into a new issue vs continuing in here?

tmarkley commented 2 years ago

I'll start documenting for each experimental feature/setting. Do we have a preference on moving this into a new issue vs continuing in here?

@boktorbb-amzn I'd say that this can be the meta/epic/parent issue and we should edit the description with a list of each of the features with their own issues.

joshuarrrr commented 2 years ago

For the future though, we shouldn't have experimental features. We should have feature flag stuff that is as close to producation ready as possible.

I think we've found that we'll actually want to keep many of the experimental visualization features, as they've been particularly useful in launching drag and drop: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1708

seanneumann commented 1 year ago

@KrooshalUX @ashwin-pc @ahopp can you take a look at this? What are next steps?

KrooshalUX commented 1 year ago

@seanneumann we are moving away from the E in favor of the new experimental guidance. We have updated OUI to include new experimental badges and messaging will be corrected there. We will need to create a separate issues to have each product change their experimental UI to the new guidance and new OUIExperimentalBadge component. I would suggest closing this out as a wont-do, and lets get a new issue open with a comprehensive list of current experimental features that are not using the new guidance. We can start with: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/800#issuecomment-1115362160

dblock commented 1 year ago

There's a concept of experimental in OpenSearch (https://github.com/opensearch-project/OpenSearch/issues/5147, https://github.com/opensearch-project/OpenSearch/issues/5087 are being built as "experimental"). Let's align those concepts across OpenSearch and OpenSearch Dashboards?

ashwin-pc commented 1 year ago

@seanneumann The guidance on experimental has changed over time in OpenSearch Dashboards. We initially decided against having anything as experimental, but now have quite a few greenfield projects either released as experimental or in line to be released as experimental. This is in addition to the existing features that are already marked as experimental since the fork.

While we have been a little ad-hoc with our experimental releases so far, I think the next steps for us should be:

  1. To clearly outline what an experimental feature is
  2. How do we release a feature as experimental
  3. How do we exit experimental

@KrooshalUX is working on the UX guidance for experimental, but we still need a process that defines what should and should not be experimental and how we want to release and exit it. As @dblock mentioned, we should also be aligned with how Engine handles similar features. @ahopp Can you help defining what these process's should look like?

I would suggest closing this out as a wont-do, and lets get a new issue open with a comprehensive list of current experimental features that are not using the new guidance. We can start with: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/800#issuecomment-1115362160

@KrooshalUX I wouldnt suggest closing this as it has a lot of context and momentum. I'd suggest we open a proposal for how we handle experimental features after we arrive at a consensus here. We can use our existing greenfield projects as a base to define this process and then use that as a template to act on the experimental features defined here: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/800#issuecomment-1115362160