[DEPR]: Deprecating the frontend-component-policy-banner repo

[dianakhuang]

Proposal Date

26 May 2023

Ticket Acceptance Date

16 June 2023

Technology Removal Date

16 June 2023

First Open edX Named Release Without This Functionality

Quince

Rationale

2U is no longer using this cookie banner, and we would like to move it to openedx-unsupported if no one else is using it either.

Removal

This entire repository will be archived and moved to openedx-unsupported.

Replacement

I don't believe there is a current openedx replacement, but it's possible that other operators have developed their own alternatives.

Deprecation

No response

Migration

No response

Additional Info

No response

[dyudyunov]

Raccoon Gang uses the modified openedx cookie banner component where we've removed the hardcoded edx.org and similar values and applied some theming tweaks

I've also proposed my help in implementing such changes and adapting them for the community in the issue #423 comments

[dianakhuang]

@dyudyunov would Raccoon Gang be interested in taking ownership of this repo? Or would you be fine just maintaining your own fork with your own tweaks?

[dyudyunov]

@dyudyunov would Raccoon Gang be interested in taking ownership of this repo? Or would you be fine just maintaining your own fork with your own tweaks?

hi @dianakhuang

I've initialized the discussion inside RG.
I'll return with updates ASAP

[dyudyunov]

hi @dianakhuang

The issue description says that there is no replacement for the cookie banner component and that 2U is no longer using this cookie banner

I'm curious if this is a requirement for GDPR and if yes, how will 2U and openedx operators satisfy it?

In case when RG will take ownership of the repo - what kind of communications/interactions with openedx will be required for roadmap development?

Some notes I have for now:

• Replacing hardcoded values (like references to edx.org) will require additional configuration for MFE's
• the banner component should probably be added to the Header component + additionally to MFEs where Header is not used
• the banner component should support both legacy and MFE frontends (allow configuration through props for legacy frontend?)

I'm just trying to gather as much info as I can before the upcoming internal discussion. It will be helpful to gather as many activities for maintenance as we can to have more precise estimates and validate if we have enough resources

[dianakhuang]

@dyudyunov 2U has our own internally maintained cookie banner. I'm not sure if other operators have their own custom cookie banners that they use themselves (like RG!). I believe if RG takes ownership of this repo in the openedx GitHub organization, they would be expected to follow all the usual maintainership rules that are being laid out, but if we move it to the raccoongang organization, RG can decide how they want to maintain it.

[dianakhuang]

@dyudyunov We are planning on moving forward with acceptance and archival/move to unsupported of this repo tomorrow (16 June) unless RG wants to take on ownership.

[dyudyunov]

Hi @dianakhuang

We have an ongoing internal discussion in RG (outside of my own team)
I'll try to get update/ping people

Thanks for notifying me

[GlugovGrGlib]

@dianakhuang we are in Raccoon Gang are ready to maintain Cookie Policy banner component. We want to leave the repo in the openedx organization and maintain it according to the OEP-55

[dianakhuang]

Since this has been transferred, I'm going to mark this as archived.