giseldo/neodataset huggingface dataset:
Assess and implement new user solution for e2e tests

<!---
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
--->
Our e2e tests must be updated to reflect the new onboarding flow that requires all new users to complete email code verification (and select 3+ hashtags) in order to use the site.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Set up a mechanism to bypass the email code verification requirement for new users in the e2e test environment.

Implement centralisation of functions related to getting a new e2e user through the onboarding steps and able to use the site, so the e2e house of cards doesn't collapse when onboarding requirements change in future. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
e2e tests pass

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
n/a 

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->
Devs

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] email code verification bypass mechanism implemented
- [ ] New user strategy considered and implemented 
- [ ] e2e tests pass 

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Display Boost CTAs in admin queue

<!---
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

Enable admins to preview link CTAs for Boosts with click goals so that they can accurately review the Boost contents before approving.

## What needs to be done

Display CTAs and their links in the admin Boost queue. Links can be linked to check their contents.

## 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.
--->

[Figma](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=1561%3A33086&t=TyigfUpoArAnysCu-1)

![Boost_CTA](/uploads/5810bde707921b980aa9b8d413aeec81/Boost_CTA.png)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] The url is displayed in the admin console

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Web: Display Boost CTAs

<!---
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

Display CTAs for Boosts configured with CTAs to improve click through rates of Boosts.

## What needs to be done

- If the goal is to grow their following, when the Boost is presented, present the selected CTA
  - Clicking the CTA subscribes to the Boosted channel
  - If the user is subscribed to the channel, the display of CTA changes
- If their goal is to drive link clicks, when the Boost is presented, present the selected CTA
  - Ensure link clicks contribute to link click metrics for that Boost

## 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.
--->

![image](/uploads/fbcaad6e0d81b50909117bcb1984ce97/image.png)

[Figma Web](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=1317%3A23146&t=e2pyN1ddfi1oOsMg-1)

[Figma Mobile](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=1392%3A34632&t=e2pyN1ddfi1oOsMg-1)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Variations of the CTA show as in the figma designs
- [ ] The buttons are anchored to the bottom of the boost rotator and not hidden

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Web: Refresh Groups home feed design

<!---
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

Enable aggressive, confident experimentation with Groups as a vehicle for user retention by refreshing the home feed screen to use modern design system and UI.

## What needs to be done

Refresh the home feed layout for using the modern design system.

- Remove option to start a Gathering.
- Move Make closed, Disable notifications, Report, and Delete group options to a dropdown menu in the header.
- `Members` tab clicks to the existing legacy `Members` screen (with invite functionality)

Assume that functionality available on the members list screen can continue to be served by the existing page without refreshing it, since that page isn't critical to Groups usability for most users and there's a lot of complexity there.

## 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.
--->

[Figma](https://www.figma.com/file/ejrtrI9rNJjZYUcVw8U5iS/Groups-Refresh?node-id=21%3A1151&t=mBoIIYBfoWlvUkSI-1)

![updated_groups_1](/uploads/60c7fd3708bf4dad9f48f3a617620dce/updated_groups_1.png)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
Required for feature flag. Use the epic experiment name.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Group designs are updated to reflect the mockups
- [ ] Editing will go back to the old design

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
UXD: Surface Groups Tab hidden behind Subscribers button to main nav on a channel page

<!---
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
--->

Allow users to show off the groups they belong to without having to add every single group they belong to in their bio. Also, allows subscribers of any user to check out a person's list of groups they belong to and potentially join a group they're in which would help grow the usage and expansion of groups as a whole.


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

We currently have a solution for this built buried behind a user's subscriptions section. We just need to surface this information higher and make it clear for anyone to find.

**Current Tab structure on channel pages**

![Screenshot_2023-04-13_at_12.59.08_PM](/uploads/bf3d735b2861dcf8d9334d77daee9346/Screenshot_2023-04-13_at_12.59.08_PM.png)

**Hidden groups tab that needs to be surfaced next to 'Memberships' tab**

![Screenshot_2023-04-13_at_12.59.16_PM](/uploads/bce643ac65dc2d6c9f81d6b619da0ca6/Screenshot_2023-04-13_at_12.59.16_PM.png)

## 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.
--->

[Figma](https://www.figma.com/file/ejrtrI9rNJjZYUcVw8U5iS/Groups-Refresh?node-id=61%3A2762&t=A6vt8GYYYHM1PUtr-1)

![Add_Groups_tab_to_channel](/uploads/fa7550058b0191cc492f61ac8d0afea5/Add_Groups_tab_to_channel.png)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
UXD: Opt into Groups posts going to Newsfeed

<!---
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

As a Groups user, I want to control which Groups appear in my Newsfeed so that I can freely join Groups without worrying that their high volume will overwhelm my Newsfeed.

## What needs to be done

- Design a solution that enables a Minds user to be a member of a Group, and to manage whether or not posts from that Group appear in their Newsfeed.
- Solve for web + mobile app
- User test designs
- Get developer feedback on solution.

Scenarios to support:

| Group   | Joined | Posts appear in Newsfeed |
|---------|--------|--------------------------|
| Group A | Yes    | Yes                      |
| Group B | Yes    | No                       |
| Group C | No     | No                       |

---

Worth user testing this assumption, but I think we should default to YES for posts appearing in Newsfeed, with the option to disable on a per-group basis.

## 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.
--->

[Figma](https://www.figma.com/file/ejrtrI9rNJjZYUcVw8U5iS/Groups-Refresh?node-id=49%3A2576&t=oPW0EqMkkypXvhzX-1)

![Hide_in_Newsfeed](/uploads/bb47013012c14583cff4f735e6a360b0/Hide_in_Newsfeed.png)

![Show_in_Newsfeed](/uploads/aed876eff7a988e662d49a2e732f0e04/Show_in_Newsfeed.png)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
UXD: Display Groups posts in Newsfeed

<!---
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

Make it easier to follow new updates in Groups that I'm subscribed to.

## What needs to be done

- Design solution for displaying posts from subscribed Groups in the Newsfeed.
- Solve for web + mobile app
- User test designs
- Get developer feedback on solution.
- 
----

Some things to consider:

- Do they integrate with posts in the existing Latest & Top newsfeed? Or appear as their own feeds? (I favor the former, ala Reddit & Facebook)
- If they integrate with other posts, do we differentiate posts from Groups or somehow indicate that they came from a Group?

I have a separate task for determining how a user decides which Groups appear in the Newsfeed.

## 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.
--->

[Figma](https://www.figma.com/file/ejrtrI9rNJjZYUcVw8U5iS/Groups-Refresh?node-id=64%3A2703&t=SqAKOUcvmyTBAjz2-1)

![Groups_Feed_New](/uploads/a0db01f94eefefc0fb8df00005eb18b1/Groups_Feed_New.png)

![Groups_Feed_Mobile_New](/uploads/edb500ed00f32b9b991baa37e02170b4/Groups_Feed_Mobile_New.png)


## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Wefunder topbar banner

<!---
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
--->

Communicate the Wefunder campaign to the whole community


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Clone new referral top bar component
- Copy: Become an owner of Minds by [joining our Wefunder](https://wefunder.com/minds).

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Web/Mobile Web


## 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 other than text change

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Web: Update referrals screen with affiliates requirements

<!---
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

Incentivize and enable Minds users to refer new users to join Minds and transact.

## What needs to be done

Update the existing [Referrals screen](https://www.minds.com/settings/other/referrals).

- Rename screen to Affiliates
- Move link in Settings screen to the first level, above `Other`
- Promote ways that affiliate referrals can earn money
- Include existing mechanisms for generating referrals (copying link, emailing link, etc.)
- Update the `My referrals` table to log accounts you've referred, with a running total of earnings they've generated for you

---

Button functions:

- Invite and earn: Opens share sheet
  - Social buttons share URL (https://www.minds.com/?referrer=xxx)
  - Copy link: Copies link (https://www.minds.com/?referrer=xxx)

- View earnings: Links to wallet (https://www.minds.com/wallet/cash/earnings)

- Earn with link: Opens share sheet
  - Minds+: Copies link (https://www.minds.com/plus?referrer=xxx)
  - Boost: Copies link (https://www.minds.com/boost/boost-console?referrer=xxx)
  - Minds Pro: Copies link (https://www.minds.com/pro?referrer=xxx)
  - Creator: Copies link (https://www.minds.com/?referrer=xxx)
  - Copy link: Copies link (https://www.minds.com/?referrer=xxx)


## 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.
--->

[Figma](https://www.figma.com/file/NfZCO1DzPnw4YTzVKOu8O7/Referrals?node-id=717%3A18384)

![afills-invite](/uploads/888b3c02c5d84a51aed65bedbf952e8a/afills-invite.png)

![afills-creator](/uploads/7c8216d096726cbed06f648ee9e630a8/afills-creator.png)

![afills-web](/uploads/908285fe3bd0197214c92b315724de6f/afills-web.png)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [x] Is Mobile Required?

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

n/a

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Introduce a feature flag
- [x] Exclude the Invites section from this ticket
- [ ] UI resembles the Figma designs
- [ ] Total earnings calculation

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Update default tags in onboarding

<!---
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 differentiation in audience interests indicated by interest tags selected during onboarding by updating the default tags presented.

## What needs to be done

Update the default tags presented in the onboarding tag selection modal.

![image](/uploads/623c8bf2d3844b9a9885d082a80b011e/image.png)

| Order | Tag          | Change |
|-------|--------------|--------|
| 1     | technology   | keep   |
| 2     | crypto       | keep   |
| 3     | nature       | keep   |
| 4     | travel       | keep   |
| 5     | outdoors     | keep   |
| 6     | animals      | add    |
| 7     | memes        | keep   |
| 8     | erotica      | add    |
| 9     | news         | keep   |
| 10    | politics     | add    |
| 11    | spirituality | keep   |
| 12    | health       | add    |
| 13    | education    | add    |
| 14    | business     | add    |
| 15    | sports       | keep   |
| 16    | comedy       | keep   |
| 17    | fashion      | keep   |
| 18    | anime        | add    |
| 19    | gaming       | add    |
| 20    | art          | keep   |
| 21    | music        | keep   |
| 22    | photography  | keep   |


[Source](https://docs.google.com/spreadsheets/d/17YrfeEqFy6a7iyHAy0sr9hBQQIZScAwKlJxy4X5PPno/edit#gid=651592439)

OJM - these ones are removed: 
| REMOVE       |
|------------|
| blog      |
| minds      |
| myphoto    |
| videos     |
| journalism |
| blockchain |
| food       |
| nutrition  |
| film       |
| poetry     |

## 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.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Changes made as per table above

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0