Feature Request: Tagging for Apps with issues

[joethreepwood]

Is your feature request related to a problem?

We currently have several apps with significant issues. These include:

• Shopify ("Creates an infinite stream of events," says @marcushyett-ph)
• Pagerduty ("It's completely broken," says @yakkomajuri)
• Hubspot ("Has some issues with fields," says @kappa90)
• Salesforce ("Had some problems for a while," says @marcushyett-ph)
• Engage ("I'm worried it might be unreliable," says @Twixes)
• Airbyte ("Problem with schemas," says David)

And there are probably others. We aren't currently prioritising fixes for these apps and, even if we did, with the focus on community apps it's (to quote @neilkakkar) not feasible for us to 'fix' all community apps.

However, we continue to feature these apps prominently via the App store and homepage, and do nothing to either set expectations for these apps or warn users who may already be reliant on them.

Problem: Users may have a bad experience by installing and expecting an app to work when it doesn't, or having no idea that it has issues. This is less of an issue for apps like Engage (which just has some odd code), but is significant for PagerDuty (which doesn't work at all).

Describe the solution you'd like

We currently use the following tags for apps.

I'd suggest we introduce a new tag for apps which have known issues - either a Beta tag to indicate that it is non-final state, or simply a ⚠️ / 🔧 icon to indicate maintenance. We can add a tooltip which says something to the effect of: There are currently some issues reported with this app. Please see the repo for info, or to suggest a fix.

Whenever a significant issue is identified with an app, we should add this tag to it.

Describe alternatives you've considered

We could just fix all the apps, but that probably won't scale well against other priorities.

We could simply remove apps with this issue, but that would impact user experience.

We could add information into the app installation flow to set expectations and clarify that users install apps at their own risk, but that would harm credibility and be an over-correction.

Additional context

Tagging @lottiecoxon and @clarkus from a tag/UI perspective too.

Thank you for your feature request – we love each and every one!

[jamesefhawkins]

I think a Known Issues tag, that then links to the github issues would be a really neat solution here to clarify exactly what isn't working

Whereas a big "THIS IS BROKEN" esque sign will scare everyone off, when sometimes these apps may be useful

[clarkus]

I feel like if we know it's broken, it shouldn't able to be enabled. Secondary to that, some affordance that communicates why it's broken and how a user might recover or learn more is a good thing. A tag could work, but really some higher priority status would be more effective. Tags are really for users or products to classify and organize things. This feels closer to an error state and that doesn't really map to tagging for me.

[kappa90]

Should new installs be disabled until these apps are going to fixed? I'd rather do that than letting people potentially have a broken experience.

[joethreepwood]

I think probably worth getting @yakkomajuri s thoughts on the PagerDuty app specifically. I also think if we're disabling new installs we should recognize it's worth telling existing users, which potentially feels like an over correction.

[mariusandra]

I feel like if we know it's broken, it shouldn't able to be enabled.

Seconded.

I sense this issue came out of frustration. Is the situation now as bad as it was 2 months ago? @yakkomajuri @joethreepwood

Found the issue as part of the bug cleaning sprint.

[joethreepwood]

Should new installs be disabled until these apps are going to fixed?

I think this is possibly a better solution, but it's also more complicated to implement.

I feel, if we're stopping broken/buggy apps from being installed, we should also update the apps list on posthog.com/apps to avoid confusion and misleading customers.

We should also have a way to notify customers who are currently using them, so that they don't continue using a broken element of the product -- possibly, we should automatically disable the app.

Finally, we'd need a way to clearly qualify what counts as a 'broken' app (which we would pull from the site and apps list) and what's merely an app with some known issues but otherwise works as intended.

I think a Known Issues tag, that then links to the github issues would be a really neat solution here to clarify exactly what isn't working

I think this is the neatest solution, especially because it may give users the info to actually go and directly fix the app. However, may be worth getting thoughts from @pjhul on whether we want this stuff in the docs instead?

Is the situation now as bad as it was 2 months ago? @yakkomajuri @joethreepwood

AFAIK there are still some broken apps, as I've not heard about any of the apps mentioned above being repaired -- but I'll defer to @yakkomajuri