The current README is the generated one from create-react-app. The README needs to be updated to include development environment setup steps, dependencies, etc.

When a new Post or Thread is created we can update the related caches so that the new data is rendered immediately on submit.

The useMutation react-hook (https://www.apollographql.com/docs/react/api/react-hooks/) has an update callback that is called when the mutation has completed, this function can be used to update the caches.

Currently the /about page is rendered from a react component. What is the best practice for rendering static pages from a react app? 🤷‍♂️

We need to display user-input validation errors to the user when they are (or before they) submit a form.

I created a ValidationError component that I am using on the AddGroup form. I want to discuss server validation strategies and make a decision collectively how we want to handle this. The ValidationError component may not be the right strategy 🤷‍♂️.

We should also keep the form populated if they fail validation.

• Handle validation errors
• Form remains populated on validation failure

The postgresql database is running on the local server, colocated with the Hawthorn web application. When Digital Ocean performed some emergency maintenance on the physical hardware where the droplet is hosted on January 14 it resulted in complete data loss of the Hawthorn database.

We can move to a managed database that lives on separate servers, has redundancy and regular snapshots so that the application is more resilient to dataloss going forward.

Currently all Threads return for a Group. This should be limited through pagination.

Add versioning to both the frontend and backend.

The user-experience of the sign-in, register, and logout navigation could be improved by conditionally rendering the navs under various login states.

• Only show Sign-In nav when not logged in
• Only show Register nav when not logged in
• Only show Logout nav when logged in

We may need to keep state in cache or a cookie on signin to know when we are logged in, then clear it on logout 🤷‍♂️

A testing strategy needs to be implemented and a base test harness put in place for the front end code.

If a user forgets their password, send them an email with a link to reset their password.

I have had 3-4 requests for private communities during user interviews. This could be as simple as adding a boolean flag onto the table indicating privacy and not displaying returning these communities on the public community requests. In this model, the end user would need to navigate directly to the URL of the private group.

A logged in user may add a bio to their account.

Add a form that people can use to leave feedback or get involved with the project.

Should this form send an email, ping in discord, other ideas?

Currently if the application cannot communicate with the server it will fail catastrophically, no useful information is rendered to the end user.

What should happen in failure cases? Right we are displaying messages like "I'm so very sorry, a real bad error occurred while adding your response".

This issue is related to #9

Currently when a link is posted within a comment body it shows up as plain text. We can render links as anchor tags and make them navigable from the comment body.

Currently all of the Posts return on a Thread. This should be limited through pagination.

A logo would be nice for the application header and favicon, and for beginning to develop a brand.

When we have completed the small groups project and released the feature, let's send a newsletter to let people know about it. We can send it to:

• All hawthorn contributors
• People who have shown an interest in hawthorn
• People who have submitted their email through the "Contact us" form

Then let's celebrate!

Make sure we are catching all the possible errors returned from the graphql server.

How should error cases be handled by the front end? Where should the user be directed and what messaging should be delivered?

Sanitize input and/or encode rendered content to prevent attacks. We can start with looking at HTML injection attacks:
https://www.hackingarticles.in/beginner-guide-html-injection/

Do folks prefer to work in Typescript? What is the level of effort in converting this project to Typescript at this point?

As the number of communities and threads grow, there will need to be a way to find communities and threads of interest.

Some ideas that have been mentioned are a search feature and categorization by tags.

• A logged in user may reset their password
• A user may reset their password via email if they have forgotten it

Style the /account page.

Add code linting to the project for consistent code style.

What are peoples thoughts on using prettier?

If an invalid authentication code is exchanged for login an error is returned, we are not catching this error.

"networkError":null,"message":"GraphQL error: Invalid Authorization Code"

• Users receive email notifications with a summary of their communities' activities
  • Enable / disable email notifications - modifiable on account page
  • Configurable email frequency - modifiable on account page

Design

• Design email template for activity summary notifications

Frontend

• From Group component, a user can invite user by email
• From the user's account page you can view Groups that you have been invited to
  • A user can accept invitations to Groups they have been invited to

Backend

• Mutation invites a user to a group
• Mutation accepts invite
• Users receive email notification when invited to private community
  • Email is sent to invited existing user, prompting them to login and accept the invite
  • Email is sent to invited non-existing user, prompting them to create an account and join the group
    • User is added to all groups they are invited to upon registration

Design

• Design email template for community invitations

When a user registers for their account we will send an email for verification.

Restrict user actions (posting) until email verification is complete?

• Create automated build for the frontend codebase
• Create automated build for the backend codebase

• User may create a new private community
  • Creator of the community is the community admin

• A user can register for an account

  • email (required) - used for password resets and notifications
  • password (required)
  • username (required) - used for login Id
  • photo - currently randomized Avatar
    • add on in future feature - upload custom avatar

• A user can login to their account

  • A user can view their account details

This task may be worked on simultaneously by multiple people.

Frontend

• initiate registration
• initiate login
• initiate logout
  • for registration, login, and logout we will navigate away from the app to the OAuth login portal, which is already implemented. So we just need to build the part that kicks off that redirect.

Backend

• OAuth registration flow (Trevor)
• OAuth authentication flow (Trevor)
• Get new access token from refresh token
• Store access token in session
• Kill session on logout
• Store session in Redis or alternate store? Session is killed on each restart, which is on save in dev

Currently everything is seemingly set in stone from the user's end once a comment is submitted. Not sure if this is feasible to implement though if the goal is to have no accounts and make all commenting anonymous

I don't know webpack or how to manage image assets in a web application.

There are some images co-located with components so that the About component can display them.

These should be packaged with webpack and live somewhere with other assets, outside of src/components.

Style the /register page

Need to add custom style to the login portal page so that it conforms to the rest of the site. The login portal is managed by the authorization provider (FusionAuth) and the customizable login template is stored in FusionAuth.

A logged in user may add their first and last name to their account.

Comments or posts are currently tied only to a conversation. This request is for responding with a comment directly to another comment. The UI should indicate that the response is related to the comment and not directly to the parent conversation.

A logged in user may update their account details:

• email
• username?
• first name
• last name
• bio

• serve the application over HTTPS
• secure the session in production

In transitioning the product from public to private we need to update some messaging and make some slight changes to existing functionality.

The only public community will be what is currently titled "Hawthorn Community Building" which can be used to discuss hawthorn topics globally, source feature requests, and whatever additional conversation that may emerge.

• Disable the ability to create new public communities
• Landing page describes the upcoming private community feature and anticipated time frame
• Form to collect an email address to notify the end user when the private feature comes online
  • pointing the user at the existing contact form and asking them to subscribe to newsletters

• An admin user of the community may define the community's set of norms
• Users joining a community must agree to the norms when joining the community
• Messaging states that users agree to and will abide by the norms when engaging with the community

Backend

• A community returns it's norms
• A user agrees with norms
• Norms may be added to a community

Frontend

• Create norms component
• Render norms within the community
• Checkbox agreeing with norms on joining community

Design

• Where should norms be placed on a community page?

On the server-side, we are making the call to FusionAuth to register a user using the fetch API. We can make this request with the FusionAuth node client instead. This will be beneficial if there are updates to the endpoint, as they can get updated with the client, and for consistency.

The reason why some of the other calls to FusionAuth are made using fetch are because the OAuth workflows (login, logout) are not available in the node client.

Add navigation to get back to the parent group when you are inside of a Thread.

The frontend currently uses bootstrap. I have been learning as I go for frontend development and design. This is an area that could use a lot of leadership and help right now.

A testing strategy needs to be implemented and a base test harness put in place for the back end code.

A user can add a new Thread on a Group ("Start a conversation").

In the frontend, there is an AddThread component that contains a form for adding a new Thread. It will need to be updated to take a groupId so that we know what Group to ad the Thread to.

The backend has a createThread Mutation that will create a new Thread on a Group.

Registration requires that the username, email, and password fields are all present. The authentication server also performs validation against username and email uniqueness, with the option to configure password validation rules. If these fields fail validation the authentication server returns errors.

We need to relay these to the end user so they can fix the issue on the registration form.

Feedback from multiple mental healthcare professionals has pointed to the necessity of content moderation for developing safe spaces for people to express vulnerability and meet each other in support.

We can start with an aggressive moderation policy for all groups to err on the safe side, and accept community proposals for modifications to moderation policies going forward.

I have a license to CleanSpeak that can be used for moderation. This service can can be configured to screen for vulgarity, bullying, sexual content, hate-speech, racism, etc. It can also be hosted on-premise.

Full disclosure, I work for the parent company of CleanSpeak. We can also source proposals for alternative moderation services.

• Add "Community Care Collective" as contributor for sharing Code of Conduct as a starting point for Hawthorn Code of Conduct
• Add "Denver Devs" as contributor for advising on community moderation practices, codes of conduct, and facilitating online communities
• Draft code of conduct (@moonquay)

Public and anonymous "Hawthorn Community Building" community

• Highly restrictive content filter scanning for bigotry, racism, bullying, and profanity
• Filter hits are queued for moderation, queued posts are not published until approved by moderator

Private community moderation

• Posts pass through moderation filter
• Community members may flag posts for violating the code of conduct or community norms
• Moderation score is calculated as a function of community moderation and automated filter score
• Community members each cast a vote on the community allowed content policy
  • Community member's votes are cast privately and are never disclosed to anyone other than that user
• Posts that do exceed voted upon threshold are not published

Cleanspeak is only necessary when developing against it (which is rare), so by default we can remove these containers for the development environment.