giseldo/neodataset huggingface dataset:
New email verification templates for code/link email verifications

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Update the visual presentation of Minds email communications to (1) appear more consistently across multiple email clients, and (2) appear more credible.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

We're starting with the new template rollout by implementing it for email verification messages.

Create a new email template for code-based email verifications, that uses the copy defined below and the email HTML layout linked in the Design section.

- **Subject (code ver):** 000000 is your verification code for Minds
- **Email preview (code ver):** Verify your email address with Minds.
- **E-mail copy (code ver):** Enter this verification code on Minds to complete your registration.

---

- **Subject (link ver):** Verify your email address
- **Email preview (link ver):** One click to complete your registration on Minds.
- **E-mail copy (link ver):** Click the button below to complete your registration.
- **CTA (link ver):** Verify

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

Please find attached two email templates relating to email verifications. These templates have been tested using Litmus, are fully responsive.

Existing template -> https://gitlab.com/minds/engine/-/blob/master/Core/Email/V2/Common/default.tpl

### Assets

* [Preview - Verify Link](https://litmus.com/pub/f277e9c)
* [Preview - Verify Code](https://litmus.com/pub/9836287)

* [Verify__Link.zip](/uploads/2a03a77c14235ac038a5764c98f826c3/Verify__Link___1_.zip)
* [Verify__Code.zip](/uploads/54a98f55c13364a15327514714134143/Verify__Code___1_.zip)

## Personas

All new users

## Experiments

We should test the impact of switching to Codes for verification -- e.g. to measure do more or fewer or the same percentage of users complete verification. I believe this experiment will be handled with the front end component of this update, and that we don't need a separate test for this email component.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Code-based verification emails use the newly-defined template
- [ ] The email layout looks good in all major email clients -- some variance is expected, but they should not look broken

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Measure browser push notification clicks

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

We need to understand the value of browser push notifications, both to users and to Minds.

## What needs to be done

Enable the measurement push notification clicks.

Given the assumption that clicking a push notification opens a web URL, a possible solution is adding `utm` parameters to URLs for push notifications.

Consider using `onClick` from the service worker to avoid utm codes. Use existing snowplow click event.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

No design requirements.

## Personas

This primarily impacts Minds staff and data team.

## Experiments

No experiments associated with this change.

## Acceptance Criteria

- [ ] In Superset, we're able to understand what volume of pageviews and sessions were initiated via browser push notification.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
Request notifications permission from Notifications dropdown

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

Increase the % of users who opt into browser-based push notifications.

## What needs to be done

Add a button to the Notifications dropdown that allows the user to enable notifications for the current device. The button will request notifications permissions from the browser.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

- [Notification request design](https://www.figma.com/file/FiOiKZkuObKfZbHrWwe0pU/Notifications-%5BWeb%5D?node-id=101%3A4080)

![Screenshot_2022-05-10_at_13.30.49](/uploads/3e30890541ca34555030aa745e3e3b1d/Screenshot_2022-05-10_at_13.30.49.png)

## Personas

- All active users

## Experiments

This feature does not need an experiment.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] Given the user has not already enabled or blocked browser notifications for Minds, when the user clicks the Notifications bell and the Notifications dropdown appears, then the user sees a button to enable push notifications for the current device.
- [x] Given the user has not already enabled or blocked browser notifications for Minds, when the user clicks the button, then a browser-level prompt appears that asks the user to enable or block notifications for Minds.com.
- [x] Given the user HAS already blocked browser notifications for Minds, when the user clicks the button then display a toaster message to communicate "Your browser blocked Minds notifications. Change site settings in your browser to allow and try again."
- [x] When the user allows notifications permissions for Minds, then Minds enables push notifications for the device they're on.
- [x] Given notifications are enabled for the current device, when viewing the notifications settings screen (https://www.minds.com/settings/account/push-notifications), then the button under the `Push Notifications` heading is a button to disable notifications.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 2.0
Create Experiment::<Scope> labels.

## Goal
Quickly identify tickets that require an experiment from the Sprint board.

## What needs to be done
Create a Experiment::<Scope> labels as below:
- Experiment::Required
- Experiment::Disabled
- Experiment::Configured
- Experiment::InProgress


## QA
N/A

## UX/Design
N/A

## Personas
N/A

## Experiments
N/A

## Acceptance Criteria
- [ ] Labels created and assigned to the relevant tickets

## Definition of Ready Checklist

- [X] Definition Of Done (DoD)
- [X] Acceptance criteria
- [X] Weighted
- [X] QA
- [X] UX/Design
- [X] Personas
- [X] Experiments

Story points: 0.0
Update sandbox helm charts for FE/BE to use staging image instead of production

## Goal
Improve testing environments to avoid issues when deploying to sandbox during MRs.


## What needs to be done
Update helm charts for FE and BE to pull image from staging/latest if no branch exists.


## QA
Check that the correct image is being applied in sandbox.


## UX/Design
N/A


## Personas
N/A


## Experiments
N/A


## Acceptance Criteria
If FE or BE branch does not exist then the relative sandbox image must be applied from Staging/Latest image.

## Definition of Ready Checklist

- [X] Definition Of Done (DoD)
- [X] Acceptance criteria
- [X] Weighted
- [X] QA
- [X] UX/Design
- [X] Personas
- [X] Experiments

Story points: 0.0
Implement media engagement metrics

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

We're defining a general content engagement metric that counts interactions with media posts. We need to be able to measure when these interactions happen.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Create new analytics events that fire when a user interacts with media in the following ways:

- [x] Clicks an image or video to initiate a large modal view
- [x] Clicks to unmute an autoplay video (first time only)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

No design changes.

## Personas

Minds staff and data team.

## Experiments

No experiment needed for these changes.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Analytics events fire each time one of the above-listed actions is performed
- [ ] Events are related to the activity post IDs that the user is interacting with
- [ ] Events are matched to anonymized IDs of the users performing the engagement

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Update report categories (web)

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

The goal is to streamline the report modal by clarifying categories and removing duplicate and/or unused entries.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Report categories should be updated to reflect the chart in the following section. Below is a list of changes:

**Text-only changes**

1. Change 'pedophilia' to 'sexualization of minors'
2. Change 'Encourages or incites violence' to 'Incitement to violence'
3. Change 'Impersonates' to 'Impersonation'
4. Change 'Copyright' to 'Intellectual Property Violation'
5. Change 'Token manipulation' to 'Inauthentic engagement'
6. Change "Sex trafficking" to "Trafficking"

**Removals**

Remove the following categories:

1. Trademark infringement (because it is merged with IP violation)
2. Incorrect use of hashtags (because it does nothing)

**Modifications**

Under 'Intellectual Property Violations' (formerly 'Copyright') we need to link to the Zendesk DMCA form instead of saying to email to copyright@minds.com.

https://support.minds.com/hc/en-us/requests/new?ticket_form_id=360003221852

![image](/uploads/3468e4dcc934af01a792d1680dbaf7da/image.png)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Minimal QA: make sure reporting under the new labels generates the correct report.

Check emails.

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

...

## Personas

<!---
Who does this user impact and why
--->

This change impacts typical Minds users who make reports.

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

No experiments are needed.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Labels are correctly changed for users on the report modal
- [ ] Labels are correctly changed for admins in the report queue
- [ ] Labels are correct in emails

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Minds URLs often time out before share metadata is returned

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

When sharing minds.com URLs on third party sites that read open graph tags and other metadata to generate URL previews, the minds.com URL often times out.

### Steps to reproduce

- [Check a minds.com URL on Schema.org's validator](https://validator.schema.org/#url=http%3A%2F%2Fdebug.iframely.com%2F%3Furi%3Dhttps%253A%252F%252Fwww.minds.com%252Fnewsfeed%252F1362763459632042002)
- [Check a minds.com URL on Iframely's debugger](http://debug.iframely.com/?uri=https%3A%2F%2Fwww.minds.com%2Fnewsfeed%2F1362763459632042002)

### Platform information 

- MacOS + Chrome

### What is the current *bug* behavior?

- Validators (as linked above) often return only partial metadata results
- Third party sites like Twitter often generate incomplete previews of minds.com URLs

### What is the expected *correct* behavior?

- Validators reliably read all relevant metadata
- Third party sites like Twitter reliably generate complete previews

### Relevant logs and/or screenshots

Iframely with partial metadata returned:
![image](/uploads/0c7ab919fa5d02fb2ec4e37f97dfd855/image.png)

Iframely with complete metadata returned:
![image](/uploads/8d6711ff2d84a54f0575272dfe385726/image.png)

Note that in the second screenshot, oEmbed and Open Graph tabs appear, and the GIF media on the page is played.

### Possible fixes

I don't have a fix in mind, but guess that it's related to client-side rendering of pages. The initial document we serve from the server contains only partial metadata -- the rest of the metadata, including open graph tags, is rendered client side, which may get delayed / may happen too slowly for whatever timeout standards these sites use.

Story points: 2.0
Small update to minds.com homepage title

<!---
Please read this!

The Defintion of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Improve the appearance of Minds homepage when shared in other apps, to better drive clickthroughs and growth.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Bill requested a small update to the 

Current text:

> Minds: The Alternative Social Network

New text:

> Minds

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

- Validating the document tags match above can be done before release, but testing on Twitter will likely have to happen post release

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

None needed

## Personas

<!---
Who does this user impact and why
--->

Users not already on Minds; users who have friends on Minds; users who see Minds referenced on social media sites.

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

This change should not be deployed as an experiment.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] The following fields match the text spec'd above:
  - [ ] `title` tag
  - [ ] `og:title` meta tag
- [ ] When sharing the page on Twitter, the text spec'd above appears in the Twitter embed
- [ ] Ping @markryansallee when deployed

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 1.0
Apply has-seen ranking to Discovery:Top feed

<!---
Please read this!

The Defintion of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Increase the user engagement rate with the Discovery:Top feed on Minds by ensuring that users see fresh content every time they visit them.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Apply the same has-seen ranking filter that we use on the Newsfeed:Top feed to our Discovery:Top feed.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

...

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

No visual changes required.

## Personas

<!---
Who does this user impact and why
--->

Everyone, especially Core users who revisit the same feeds frequently.

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

We should deploy this as an experiment to understand the impact. Measure:

- Upvotes
- Comments
- Reminds
- Time on site
- Sessions per user

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Given the user has previously viewed Post A on the Discovery:Top feed,
  - when the user re-visits (reloads) the Discovery:Top feed,
  - then Post A is ranked lower than posts that the user has not already seen.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
In-feed notice: Update your interests tags

## Goal
- Increase the % of active users who have relevant interest tags selected.
- Given the recommendations algorithm Tasman is working on, this will improve both (1) the predictiveness of the recommendations, and (2) the ability to reach users with the recommendations.

## What needs to be done
Using the in-feed notices component we created, make a new notice that prompts users to update their interest tags, given the user matches conditions specified below. Clicking the modal will launch the existing Content Settings modal, allowing the user to select their interest tags, save, and close the modal to continue using the Newsfeed.

## Experiments
This does not need to be deployed via experiment.

### Dev notes

Discovery hashtags api endpoint includes all tag information.

## Acceptance
- [ ] Create a new in-feed notice that, given the correct conditions described below, can appear in the Newsfeed.
- [ ] The notice will prompt users to update their interest tags.
- [ ] The prompt will launch the Content Settings modal that lets users set their preferences.
- [ ] The prompt is dismissable.
- [ ] The prompt should show **only** to users who have not got any tags selected

![image](/uploads/710195e05007e7e83179d439ea0543fc/image.png)

### Conditions

- User has not already selected interest tags
- User HAS selected interest tags, but has not updated them recently (~60 days).

| Notice                    | Description                                                                                                                                                                                      | Dismissable | Position | Sticky | Display priority | Conditions                                                                                  | Primary action                                                            |
|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|----------|--------|------------------|---------------------------------------------------------------------------------------------|---------------------------------------------------------------------------|
| Update your preferences   | Updating your interest tags improves your experience on Minds, and makes it easier to discover creators and content you haven't found yet.                                                       | Yes         | In-feed  | No     | 2.1              | User has not selected tags, OR user has not recently (in last ~60 days) updated their tags. | Select interest tags    
                                                  |
## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [x] Weighted
- [ ] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
Channel recommendations click to "This channel doesn't appear to exist"

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

On a Channel page, after subscribing to user `vigilantfox`, the recommended channels that appeared all clicked to `This channel doesn't appear to exist` pages.

### Steps to reproduce

- Navigate to `vigitlantfox`'s channel page https://www.minds.com/vigilantfox/
- Subscribe to `vigilantfox`
- Observe the recommended channels that appear
- Click the usernames of the recommended channels (e.g. [`weplenty`](https://www.minds.com/weplenty/), [`Gracedd`](https://www.minds.com/Gracedd/))

### Platform information 

- MacOS + Chrome

### What is the current *bug* behavior?

- The component is recommending channels that don't exist

### What is the expected *correct* behavior?

- The component should recommend channels that do exist

### Relevant logs and/or screenshots

![image](/uploads/f81b7dd1fff8248b41388415e0ae4e13/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0