ADR: Chat

  • Status: Accepted

  • Last Modified: 2023-08-17

  • Related Issue: #105 (https://github.com/HHS/grants-equity/issues/105)

  • Deciders: Lucas Brown and Billy Daly

  • Tags: docs:adr topic:comms

Context and Problem Statement

We want to explore and evaluate options for group chat in order to facilitate effective cross-team and communication. This chat tool will be utilized by both internal individuals at HHS and the general public, requiring usability and effectiveness across diverse user needs. Additionally, the selected tool should have the capacity to scale and adapt as the project expands. There is currently a lack of a transparent chat tool that meets our requirements.

Assumptions We believe that a chat tool can enhance communication and collaboration in real-time for our open-source community. A chat tool can provide a more immediate and interactive means of communication, allowing community members to discuss ideas, ask questions, and provide feedback in a more dynamic manner. They can facilitate quicker decision-making, foster a sense of community, and enable easier coordination among contributors.

Decision Drivers

  • Functionality: consider the features and functionalities offered with each chat tool. Consider whether the chat solution provides essential capabilities like direct messaging, public channels for messaging, public and private channels, replying to messages in threads that other users can see, emojis to react to message, file sharing, search functionality, integrations.

  • Usability: chat solution should be user-friendly and intuitive. IT should be easy for team members, including both technical and non-technical individuals, to navigate and utilize effectively.

  • Scalability: solution should be able to accommodate the projected growth in the number of users, conversations, and data as the project expands. Ensure that the tool can handle demand without compromising performance

  • Integration capabilities: solution is able to integrate with other tools and platforms that the project relies on. Integration with project management tools, issue trackers, wiki, document sharing, sprint retro.

  • Accessibility: solution should be accessible for all individuals, including but not limited to individuals with visual, hearing or motor impairments. A chat solution should support keyboard navigation, screen reader compatibility, color contrast options, and support assistive technologies.

  • Community and support: consider the size and activity of the user community. An active community, similarly to an FOSS community, can provide valuable support, resources, and community-developed plugins or integrations.

  • Cost: evaluate the pricing structure, considering growth of users and additional features in the future.

  • Self-hosting vs. cloud-based: evaluate whether the solutions are self-hosted where we have complete control over data and infrastructure or cloud-based that handles hosting and maintenance.

  • Open-source: a solution that offers open-source is more likely to align with HHS values and provide transparency, customizability, community collaboration, longevity and continuity, cost effectiveness, and overall autonomy for our project.

Options Considered

Decision Outcome

At this time, it is recommended to use a basic paid version of Slack for internal and public users. Slack offers a wide range of functionality and features, making it a popular and widely adopted chat tool. It has robust integration capabilities and a user-friendly experience. The team's familiarity with Slack reduces the learning curve. Inviting the public to our paid version of Grants.gov Slack instance will allow us to get an understanding of number of users joining and usage patterns for chat. However, it's important to be mindful of pricing implications as the project grows. We should reassess if there is growth beyond 400 users. Moving to Slack’s free version is an option for the public, open-source community. Slack's free version has limitations like data retention but would be more cost-efficient.

Positive Consequences

  • Enhanced collaboration

  • Increased engagement

  • Faster onboarding

  • Improved accessibility

  • Smoother integration

  • Positive user experience

Negative Consequences

  • Limited functionality

  • Vendor lock-in

  • Security concerns

  • Learning curve

  • Communication fragmentation

  • Incompatible with existing workflows

Pros and Cons of the Options

✅ Feature available, meets requirement ❌ Feature not available, does not meet requirement 🔄 Partial feature, limited feature availability, feature in progress or undergoing improvements 1-3 Strength level, (1 being lowest, 3 being strongest) ❓Unknown

Pricing breakdown for top choices

To understand the cost as we grow and expand chat to become accessible to public users, we want to evaluate costs for our top chat options: Slack and Rocket.chat

Slack:

For free version of Slack:

  • No limit to channels or users

  • Data retention for 90 days

  • Limitations to message and file visibility limit at 90 days

  • You can add up to 10 third-party or custom apps.

For paid versions of Slack:

  • Guest Roles (External users that are not part of a paid workspace). Host pays for the guest roles for mult-channel use. Single channel based off number of members on host workspace.

  • Slack Connect (requires both your workspace and their workspace be on a paid plan or start a trial). There is no additional charge on either workspace. Slack Connect (More for users that already have their own paid workspace). These users can have multi-channel access at no additional charge.

  • Guest users (Allows for the host workspace to invite users under the host plan)

    • Single Channel guests would be no charge and multi-channel guests would be billed like regular members of your workspace.

    • Single-Channel Guests are free and can only access one channel. For every paid active member in your workspace, you can add up to 5 guests. For example, if you have 10 members, you can invite up to 50 Single-Channel Guests.

    • Multi Channel guests would be billed like a regular member of your workspace.

Rocket.chat

  • Rocket.chat has a couple different pricing models:

    • Registered users (appropriate for a small number of users)

    • Omni-channel model: that charges by unique monthly active users

    • Model to charge for monthly active users (not unique)

  • Rocket.chat does not currently have a use case where public users need to access or view channels and interact with channels, but could be willing to work out a solution.

  • Rocket.Chat's self-hosted community edition is free forever. There are limitations to the free version including high availability and scalability. - Rocket.chat’s free community edition is limited to a single instance and designed to support 150-200 users. We have the ability to build the screen reader functionality on our own instance.

Government offerings

Offerings

Last updated