The SuggestionModal component needs to be refactored into a React Hook, and also needs a few slight UI fixes.

The header font needs to move a few pixels to the right, it's right by the left border.
The main issue is doing a little bit of string manipulation. In the screenshot, you can see 'costaRica' - we want to write a string manipulation function that will refactor that into Costa Rica, or if there are three words, into `Name Of Topic' - essentially, we want to take the camelCase object attribute, and turn it into a UI legible word.

Let me know if you have any question. The modal is accessible inside the Library of Context, the 'Document +' icon on the top right inside of a particular context.

Prior to launching the open-source project, I took steps to optimize a few things - including the bundle size. After I took a look at the npm modules using the source-map-explorer, I optimized a few libraries using efficient tree shaking, took out a few modules that were adding unnecessary burden (which resulted in the creation of the admin-console) and a few other things. As a result, the bundle size (after gzip, of course) is reasonable. After running npm run build, here is the CRA report.

Then, we can run the npm script npm run analyze to use the source-map-explorer, we can see that the total bundle size is 2.86 mb in total. A bit big, but frankly not outside the insane bundle size that node_modules foist upon us. As far as I know, CRA already 'uglifies' the code for us.

A big headache for us here is the quill.js - 250kb is by far the biggest dependency. Perhaps we should replace that, recommendations welcome.

Then comes the react core files themselves, which we obviously need. Then comes victory charts, which I don't want to replace (they are Seattle based, courtesy of Formidable) and we are only using them in a slight capacity. There is a lot more value we can get from them, and I want to see what that bundle size looks like then.

So, after that, looking at how else we can decrease our initial bundle size - we can look at lazy loading. The components with quill.js/the rich text editor replacement for it, and the components involving victory charts are prime candidates to shave off a bit of the file size.

Outside of that, what else can we add to the discussion?

This is a ticket that serves to have a list of things that need to be migrated when we can move out of alpha into beta:

1. System wide replace of id's with _id's, Mongo's built in identifier that has faster indexing performance.
2. Redeployment of all API's, creation of TEST api credentials to be used for continued development.

More to come, this is just something I wanted to write down before forgetting.

Self-explanatory, found in src/profile/Login.

Self-explanatory, refactor into Hook.

The planning documents for a team in a Sprint, for some reason, are duplicating/mirroring each other's state from one week to the next. I think their state in the Redux store isn't probably being cleared, week to week perhaps?

To reproduce: create a sprint, write out the goals for that sprint. Then, create a new sprint - and go to the planning. The planning text from the last weeks sprint has carried over for some reason.

We are currently passing a lot of state through React Router, in the form of childProps. While this doesn't have a performance implication, it does balloon the complexity of the state we are passing through - and we have already identified some unused state. Review what is being passed, potentially eliminate what is not needed. Make list for workflows to be migrated into Redux, if proper.

When we see the mobile/tablet nav at the bottom, it sometimes cuts off by 20 px or so the bottom most view of whatever screen we are on. Screenshot attached as an example!

A good chunk of the OS, like many before it, was designed for desktop experiences. However, for modules like the Arena - the user's will at least half the time interact with it on a mobile device. The biggest bottleneck that we see here is the navigation system - right now we have a BottomNav bar that pops up in tablet/mobile dimensions, but there are so many items/modules in the OS now/in the future to come that there is no way we can squeeze all of those items in. I would suggest an incredibly simple, Windows 7 Mobile (remember that?!) scrolling navigation component, with blocks/cards/links to your sprints, the library of context, to your curriculum, to leaderboards, to profiles - etc.

The long story short, is we need to make navigation on mobile MUCH more intuitive. Perhaps in the future, we can even have people customize the layout of their Home Screen and choose what's on top, what color the block/card is, etc. Here is a screenshot that has a rough idea of what we are looking for, but different - obviously.

Does anyone have any UI inspiration to contribute to this?

When changing the language in the NavBar component, it seems that there is a delay/failed propagation of state in the component tree. The language does not update immediately, though it does update when moving from one route to another. This could be caused because the I18n strings are set in index.js, which is separate from all of the moving state in childProps. It could be a different issue that I'm not seeing - needs to be investigated.

Currently, the Navbar takes up too much space in App.js, and should be added as it's own component in the 'component' folder. We would need to change certain values dependent on state, into props - and properly pass the requisite data into the imported component. App.js is currently 906 lines in length - way too much.

Can somebody take a look at the ExperienceSummary component, and provide some helpful UI suggestions/inspirations to see how we can improve the look and feel of the component?

Inside of src/learn/NewSubmitProofModal we want to re-factor that into a hook.

In src/context/ContextBuilder we want to refactor the Context Builder component from a class into a hook. This ticket is reserved for @Chris-isCoding - so, let's give him 72 hours to respond to this ticket (meaning, confirm that you are working on it). He sent me an email earlier today asking for specific guidance, so this is the result of that.

In index.js, we have a barebones Suspense integration - how can we more effectively utilize this? Take a look at React's documentation: https://reactjs.org/docs/concurrent-mode-suspense.html

We have a few options:

1. Could be used to show placeholder UI components while data is fetching, similar to Profile in src/profile/Profile.
2. Could we potentially replace the initial loading Modal, with the motivational quotes, with this? We need to gradually display the data in the initial fetch anyway, the motivational loading system is cute but ultimately takes way too long to present data to the users. A lot may be turned off, especially first time users loading things up, and waiting an extra 5 seconds while the lambda's heat up (because we have few to no users, as of 8.28.2021)
3. An integration with React's lazy loading, allowing us to split up our bundle and have smaller initial bundle sizes.

In src/profile/CreateUser let's add a

Pomodoro Vision - The ParetOS offers you the 20% of software that will give you 80% of the benefits you are looking for. Adding a Pomodoro timer, that in the future we will be able to track over time and apply towards your Arena score, verified by timers, will allow us to serve our Paretoans (or whatever we want to call users,, toans, I just don't like the word 'user').

We had previously integrated a Pomodoro timer, thanks to some functional looking boilerplate code that I found somewhere on the internet. And while, at first glance, everything seemed great, when navigating away from the tab, I found that the timer would lag/stop working completely. I figured this had something to do with JavaScripts execution threads, and after some quick Googling - I found I was right!

The UI for the primary part of the timer is already there, in src/components/pomodoro. We already have some good looking Side-nav placement in the desktop view, as you can see it is commented out towards the bottom of App.js. There are a few requirements here:

1. Replace the setInterval based timer method with one that takes advantage of Service Worker functionality. Read this article for reference and look at this GitHub repository for another reference.
2. Refactor into a Hook. If it pleases you, start over from scratch.
3. Have the ability to store a 25 minute work, 5 break, 25 work, 5 break, 25 work, 15 break cycle. Store the timestamps of each of these operations in localStorage. Once the pomodoro has been completed, store it as an object inside of a localStorage array called pomodoros. This data will eventually be stored in a database, but for now localStorage will suffice.
4. Create a component that will map through the localStorage pomodoros item and display those records in a simple Card view.
5. Maintain/improve the current UI. Will likely need to add a

   or something below the timer, indicating the current stage of the pomodoro ('Break', 'Work1', 'Work 2', 'Break 2', etc)

6. Add in sounds - a timer alarm that beeps when it's time for break/resume work. Add in browser-based compatibility checks, to make sure certain functionality doesn't break on Safari/Chrome/mobile.

This is an 'ownership' ticket, meaning that completion of this ticket (fully) will qualify you to become a 'core-contributor' of the project. This is an end-to-end piece of functionality, and future functionality/bug fixes/edits for this will be your responsibility as well! Leave questions below!

Currently, AWS Websocket connections to API Gateway will close in 10 minutes, if there is no activity. To attempt to counter this, I have put in some 'reconnect' logic, that you can see in App.js mostly between lines 237-326 in React. The problem may be somewhere there, but more likely the culprit is in the web socket connection API - instead of creating a new connection ID, things should simply be 'pinging' the web socket, keeping the connection open.

Right now, we have a container called 'NotFound', which displays if the user somehow navigates to a route that doesn't exist. Here is what it looks like right now.

We want to add a few things:

1. Add the Pareto logo, from the assets folder.
2. Make the component centered, and responsive to multiple screen sizes.
3. Maybe add a joke. Or a game, like in Chrome's offline mode. Or a music player. Or don't - my point is, if you can think of something to make this page POP, let's try it out. Like an Easter egg.

Right now, our test coverage is nearly non-existent. This is a problem, as manual testing of every pull-request ultimately creates a bottleneck for maintainers to approve code and keep things moving. This ticket is somewhat of a discussion about what our testing strategy should be, and how to keep things practical at first - and then, at some point, opening the floodgates for people to write ridiculously granular test coverage of components that don't need it.

My first thinking is to focus on writing some foundational headless browser tests through Cypress, mounting the application, fetching data through a real user account's ID, and then bouncing from route to route - checking to see if anything is obviously broken.

From there, we can expand the navigational tests to individual components, then to interactions through the actual application. Then, we can perhaps do some snapshot testing, to watch for excessively major UI changes.

From my perspective, while integration and navigational testing is very valuable, I've never quite understood the need for unit testing in modern JavaScript for UI components - can someone enlighten me and give me some new perspectives?

I would also like to hear feedback from the community in general about your thoughts on practical testing strategies (to start with) for open-source projects like this.

Due to some legacy decisions made a long time ago, the Experience objects for the Full-Stack Starter Kit look like the body in src/libs/createExperience, where each piece of experience is marked as _01 instead of a modules array, where each achievement is stored. This is due to using Sanity as a curriculum management system - it was great at first, because auto-generating the forms/creation studio was great when I was working on my own curriculum, but we want to open up the functionality to more users - to create an eco-system where subject matter experts/enthusiasts can create their own curriculums, to offer for either free or for pay.

It is time to create our own forms/creation studio for this sort of thing. This is a major expansion of functionality, with a couple of main phases.

The first phase - create the forms, components to successfully re-create the curriculum in the Sanity data-set. Support for multiple languages is a hard requirement. Update the Experience component/coaching feedback system to account for this new array based reality. Keep the old components functional, until the new system is totally ready. Will need Rich text editing in the forms, to replace Sanity. Image uploads/video uploads will be somewhat of a challenge. This needs to be thought through a lot, this is just an introduction to the concept of the Issue, to be recorded in the codebase. A more effective mobile UI needs to be considered - viewing the cards side by side on mobile doesn't make sure, perhaps a picker at the top of the page where you choose which article to review and a scrolling card below that?

Another part of this is to re-factor this API's that process the updated information from a polling to web socket based mechanism, so that way mentors and mentees are immediately notified when there is feedback to review.

The second phase - give people the ability to create their own courses and allow a simple mechanism for people to find them.

The third phase - create a marketplace for creators that is BETTER and MORE EFFECTIVE than something like Udemy, which for the most part just has video courses.

If you are interested in contributing towards this, leave a comment below - this is a large project, within this large project of ParetOS.

remove overflow-x and overflow-y properties to give better UI.

There have been some obvious UX flaws in the CreateSprint component. Here are the changes that we are requesting in this Issue:

1. When the component mounts, we want to automatically add ourselves to the list of competitors - and then remove ourselves from the list of potential competitors, before updating that state to allow items to choose from.
2. After adding a competitor to the Sprint, before creating/starting it, we want to be able to remove them. So, let's add a little red x or something like that next to each player, and when clicked on, removes them from the list and adds them BACK to the list of possible options.
3. Add some sort of loading animation to the drop-down forms for choosing the template and competitors while they are fetching their data. Perhaps display 'Now Loading' as the initial option, or add a placeholder CSS component.
4. For the form validation, do not allow someone to create a sprint without them having selected a template.

In general, if you have any design suggestions for this page, I am wide open to hearing them/seeing them. If you have any recommendations for feature updates/additions to this page, would love to hear them too.

When viewing a Mentee's profile as a coach, the current pattern is for the src/profile/Profile container to fetch from the db the Mentee's information, including Profile, Experiences and Sprints. At least some of this information is already available to us, through the initial Fetch.

Can we propagate that information down through props, to eliminate at least 1 unnecessary API call? We can probably have a faster 'time to paint' for this component, and wait for the rest of the information to load and render accordingly.

In index.js, we currently have our Service Worker disabled. In the past, I have tested and successfully passed the Lighthouse Audit to meet the requirements of a Progressive web app, but disabled it while things are still in alpha/beta. There are two parts of the ticket here.

1. We need to add a system to prompt users to download updated bundles, once we have issue an update to production. Otherwise, they will be rolling with old bundles, and will have no way of getting new ones unless they are accessing through Incognito mode (unlikely) or delete their cache/browser data (even more unlikely)
2. Review lighthouse audits, and check to see whether everything is still simpatico.

Some of the 'Tour' text is outdated, or doesn't take into account new UI changes. Let's update that text with something that makes more sense, and remove that which doesn't.

In src/profile/CreateUser, there is a form at the bottom the select which country you live in. As you can see, right now we are manually populating it with options. We need to have a more comprehensive selection, with the standard exclusions (North Korea, Syria, etc) - how should we do this? Should we use an external NPM component? If so, we need to make sure the bundle size contribution is small. Or, should we find a JSON file somewhere that has a list of each country, along with a link/hyper compressed image of each countries flag, and then just population HTML tags to choose from?

I leave the decision to you, but expect to see a breakdown of the bundle size contribution of either solution (or both). Remember that you can run the source-map-explorer by first building a production bundle with npm run build and the npm run analyze. NPM will usually tell you the bundle size contribution up front either way. Anything more than 20kb starts to get hairy, but I am open to suggestions.

A final consideration is that, for internationalization purposes, we need to keep in mind the 'value' of the component. We currently have 'support' for three languages, would like to add more at some point, and need to make sure that the 'value' of the country, can have some relation to the 'defaultLanguage' profile/Amplify I18n value. This is tricky, and there is wiggle room here.

Inside src/containers/WorkRise, we are fetching some jobs from the Work & Rise public API. The UI is totally a proof of concept. What we want to do is create a new Navigation bar item inside the LeftNav component that will display this the NavItem to navigate to this component IF the user's country is listed as Uganda (UG). So, conditional rendering of a route based on country of origin.

This is a proof of concept, of providing unique and helpful content to users based on their country of origin. We will likely want to integrate more things like this, to experiment and see if they provide value.

Let's create a Terms of Service Modal/Popup, that is launched in the src/profile/CreateUser container. Let's make acceptance (check the box) a condition of moving forward with the CreateUser flow.

Do not use the React-Bootstrap Modal - we are in the process of migrating away from those, as they are no longer updating that library and the modal uses outdated componentWillReceiveProps functionality.

In src/profile/EditProfile, as well as in the Arena Proof Modal, we are submitting items to s3, primarily as images. However, we want to be ready for mp3, video, etc - this ticket revolves around two things.

1. Making sure the s3 bucket can accept those file extensions
2. Open those file extensions inside the application, instead of lazily opening an external link to the s3 URL. Might need to use some HTML tags, that aren't currently there.

Right now, our initial fetch certainly takes a minute to get the user data Paretoans need to power their experience. It would be in our best interest to reduce the number of active API requests, and perhaps offer a progressive state drip into the application - opening up parts of the UI as the state data for that comes in, progressive opening up more and more as the fetch finishes. This could eliminate the need for the loading modal, and perhaps we can find another place for those quotes (perhaps a permanent bottom bar in desktop, as a frame around the OS, with a quote rotating in and out every few minutes?

An easy way to record progress on this is to check the Lighthouse scores for our production bundles, and see if we can figure out the right combination of progressive state drip into the application, consolidation of network requests and the clever use of placeholder components as things finish loading.

One place this is especially glaring is in the Experience section - every time you want to check your training/full-stack/algorithms curriculum, it reloads the code. This is partly to accommodate the polling-first approach and make sure we have fresh state, but that can be handled on a subsequent network call that quietly refreshes the state, while caching the original stuff. Hopefully this isn't being written too obtusely, I will come back at some point to elaborate on this.

Our vision is to support multiple languages with the ParetOS. To do so, we have added the Amplify I18N library to help us with replacing certain UI/UX language based on the device's detected language. Right now, we support Spanish and Luganda.

However, there is a problem. In App.js there is a language bar, in the side-nav, where someone can change the active language of the application. When they change the language, they can see the language changing in the side-nav - but not in the other components, until they migrate to another container (using the history object). Then, the language propagates. My theory is that these language props are not being propagated correctly somehow, perhaps the event needs to be triggered outside the side-nav? Maybe do some research on Google.

In ApproveExperienceModal, we want to change the coach notes from being a simple form field to being a rich-text field, where the coach can leave detailed feedback instead of simple font. We will then want to update the view on the mentee's side, to review the notes in dangerouslySetInnerHtml or another form to display the rich-text.

We already have quill.js, but I am not super happy with it (250kb in bundle size) - you can implement the same system we have already, but I am also open to other rich text suggestions. Please give an indication of what the bundle size contribution of a new NPM module is!

The bootstrap form look leaves a few things to be desired - can we get some ideas or inspiration how to update the styling to reflect a modern, unique look?

Either posting screenshots of forms you think are good, or writing some code and posting some screenshots with the accompanying CSS changes is preferred.

Something else to keep in mind, is that we will migrate our Form UI library, likely, at some point to React-Hook-Form. The reason why is pretty simple - it allows for simple validation functions in the future, and the number of re-renders it forces due to state updates is minimal. It is more performant than react-bootstrap, especially on devices that aren't iPhones or Pixels. We want the OS to run decently on cheap, $50-60 BLU phones available on Amazon, that don't even run the full version of Android. Android Go, or whatever, and a key part of that is LIMITING re-renders, especially those that are pointless.

I don't know what it is, but I just don't like the errorToast notification UI. Can somebody give some practical suggestions/inspirations for us to rework this?

Edit: the UI looks a little better now with thinner buttons, but still not a great experience.

Right now, we have an Order and Billing form component inside of src/learn that mostly handles the facilitation of the transaction to pay for the Full-Stack Starter Kit. I would also like to add in a simple route, that based on the URL - the price of the billing dynamically increases. Thinking through this, I am considering to take certain parts of the business logic from the Billing Form component, keeping that more as a pure form, and passing in the value props from the Order container. For example, when I'm running an SQL training session with a client in the next two weeks, I would like to simply send them to a link where it's something along the lines of paret0.com/billing/300 and it would bill them $300.

I'm assigning this to myself for now! This functionality can hopefully be re-purposed in the future, and I want to finesse these two containers either way. Perhaps convert to Hooks as well.

In src/profile/Signup.js, we want to refactor that component into a hook from a class.

Right now, our leaderboard component is minimalist but functional. It will sort the users passed in by score, and highlight yourself with a custom color. The boilerplate code we started from also has support for 'order by Name', which frankly is unnecessary.

There are a few things we want to implement:

1. Remove the references to 'orderByName' and generally simplify/consolidate the code needed for the component to run.
2. Refactor into a Hook
3. Test how the component handles more than 10 users at once - what if you are ranked number 27 out of 34 - should the leaderboard default to your place in the hierarchy? Probably.
4. Update the UI a bit - add an olympic podium of sorts.
5. This leaderboard needs to be slightly flexible, in that we want to be able to perhaps search for a particular member to see their score - maybe a search box is a good thing.
6. We want to be able to pass some props in to modify the purpose/UI of the leaderboard - it needs to be able to be active in a global competition context, a local context or a industry/vertical context.

We first need to run some multi-player tests on the Arena to make sure functionality is still working as it was - then we can dive into making this the world class leaderboard functionality it should be. Our goal should be to make it extensible, for many different purposes.

This qualifies as an 'ownership' ticket.

Adding in the language strings for the UI in Portugese, adding new entries in the strings.js file: https://github.com/mikhael28/paretOS/blob/main/src/libs/strings.js

Vision - The ParetOS offers our Toans (or whatever we end up calling our users, I hate the word 'user') the 20% of software that will give them 80% of the benefits they need in their daily life. One thing that people need is the ability to take some notes, organize them by day and search through them (potentially with some sort of tag system, that allows us to organize things by theme.

Right now we offer (Full Stack Starter Kit) users access to the 'Notepad', which is just a Rich Text Editor that saves your notes whenever you navigate away from the notepad, 'onBlur' event. What I would like to see is a type of journal/note/todo list that is a simple, organized by day, journal that is saved in something of a real-time capacity (but the onBlur pattern can remain as a prototype). The idea is to give people the ability to store lists of things to do, organize their study plans, whatever - on a day, by day basis.

This item revolves around implementing that functionality, hopefully with an npm module that is smaller in footprint than quill.js (which currently occupies 250kb in the source-map-explorer) bundle.

1. We want Toans to write down items in a daily entry. If they did not start writing anything on that day, then that day can be skipped (or added, dependent on which is easier).
2. We want to store each day's entry as a separate object inside a 'journal' array.
3. We want a Rich text editor with a lighter footprint than quill.js
4. We want a beautiful, full page typing experience, with an easy way to shuffle between days.
5. Bonus: we want a 'tag' system, that is searchable. I don't think this is really necessary - perhaps we can make a custom entry/document per tag, that is readily available to the user.

There are likely more requirements than have been enumerated, this is just a first stab. Think of Roam Research, but a very minimal version of what they offer.

This is an 'ownership' item - completion of this item (fully) qualifies you to be a 'core' member of the team. All subsequent maintenance/bug fix/feature updates to this particular piece of functionality are to be your responsibility, since you know the code!

In the ContextObject component within the Library of Context, we are currently simply opening up a new tab when clicking on a link. This, however, takes us away from the OS - which lessens the value of what we provide, as we are constantly sending people out of the tab (especially when loading as a ProgressiveWebApplication on MacOS, for example).

What we want to do, is to change the functionality from being an anchor tag, into the following:

1. When clicking/tapping the card media, we are going to open a modal with similar styling/structure as Modal.js inside the components folder. Simple, and clean.
2. The modal is going to have an iFrame loading that particularly web content. The modal should be responsive, with the iFrame dimensions stretching based on screen size.
3. There should be an easy to see/tap/click button that says 'Close', below the iFrame which closes the modal and unmount the iFrame.

This is a pretty simple ticket, not too much involved!

Your first ticket is to refactor the functionality inside the src/profile/ResetPassword component from a class component to a React Hook. Please create a branch called feature/reset-password-hook and submit it to the develop branch.

In the Landing component, we want to do a couple of things.

1. Add a secondary button next to SignUp, called Login.
2. Add a testimonial from yourself about the app or the open-source community.
3. Try to standardize/optimize the CSS a little bit.

The Paywall is a puzzle of sorts - a user can pay myself, the core-contributor of the project and author of 99% of the code+curriculum+open source issues $89 for some amazing educational products, physical and digital.

However, if you can figure out how to change a couple of values in the front-end code-base, you can completely bypass the paywall and create the accounts necessary to access the online curriculum for Full-Stack Development. If you can't figure it out, my view is that you should consider purchasing the products and investing in your education until you CAN figure it out.

The Paywall Modal has a few enhancements needed from a visual perspective:

1. The Button color needs to be different for the cancel - a red button.
2. On the Purchase form, the header of each form field is centered, but the placeholder text in each form field is aligned left The header of each form field should also be aligned left, in fact the form should be aligned left and not centered.
3. There should be a way to go back/cancel once you click the 'Purchase button'.
4. If you click outside of the modal, not just clicking Cancel, it should close the modal/redirect you to the home route.

There might be a few more things, but for now this is a great starting point. Lots of these enhancements are small.

Convert this class component into a Hook. Pretty self-explanatory, good first issue.

We are using essentially the same exact Tab Panel (the small functional component) in ContextBuilder.js and Sprint.js - can somebody please turn this into one exportable component, that is imported into both files?

One of the pieces of software that adds tremendous value is simple messaging. Going back to the days of AIM/MSN/IRC, simple chat clients provided tremendous value and captivated people. We would like to see a simple chat experience that allows members to communicate across channels. Those channels can be platform-wide (#main) or personal messaging threads. Let's keep things simple at first, and enable text, attachment sending and pictures.

Our users should be able to create new messaging threads. They should be able to reply to a thread. There should be optional notifications per thread, but it should not use the Notification API since not all browsers support it. Instead, we can store a running thread of notifications locally (but let's avoid persistent online notifications, such as email or SMS for now. I would like people to be able to shut off the OS, and not have it hound them across multiple access points. Just like with AIM, when you log-in - you can see the messages that you hadn't yet read, but there were no notifications sent to your email - the messages THEMSELVES were the notifications. Similar to Hey's policy for email.

Right now, the messaging system is built off an auto-generated GraphQL API using AWS-Amplify CLI, that stores messages in DynamoDB and has support for multiple channels out of the box. I would like to build off this system, unless it proves prohibitive in cost. Right now the Dynamo auto-scaling is turned off, so there is no chance for outrageous costs.

The most immediate item - we need to migrate the Messaging subscription operations out of Messaging.js and move it into App.js, so that way we can access/save the messages and not have to reload all the latest messages in Messaging.js every time we load. It's also necessary, so that we can listen for the subscriptions outside the Messaging container, and relay notifications system wide.

To add the right amount of polish and features for this item, qualifies it as an ownership ticket, which means you are qualified to become a maintainer of the repository upon completion of the Issue and desire to be a maintainer. You don't have to become a maintainer, but it's an option.

In src/libs/errorEmail we have a pretty decent, HTML designed email template that we are using.

1. We need to change the name of the file to just email, and we are deprecating the sendEmail functionality since we now have Sentry. Let's keep the generateEmail functionality, and apply it to all emails being sent on the platform, especially in src/profile/CreateUser where it is right now simply sending some blah ugly plain text onboarding emails.
2. For the onboarding emails, let's give them a bit more information about the features of the platform in the message, and more interesting content in general.

Inside of src/profile/Profile, when looking at your Mentee sprints, the UI needs a bit more imagination. Right now, it's an unresponsive card component that shows the completion percentage for the week, and let's you read their planning/review documents. We need some imagination into making this a more comprehensive review document - perhaps we need to integrate/further develop the Analytics component that can be found inside the src/arena/Sprint component, and plop it here as well.

Due to some fast and loose decision making in the past, the Edit Profile component has a lot of functionality/partial functionality that is there, bloating the file to a quite ridiculous 535 lines. We need to go through the component, see what state can be trimmed down and what additional refinements can be made.

1. saving the default language when the user makes a selection and showing a loading indicator - instead of relying on an ugly, mis-styled button.
2. Ability to edit/update GitHub username
3. Loading indicator when creating Projects
4. Editing your projects (and viewing them somewhere, in another component)