norms-communication.md

This file is deprecated. The most recent information should be at https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/platform/working-with-vsp/policies-work-norms/norms-communication.md

Norms for communication

Communicating "breaking changes"

Breaking changes are changes to design, content, or code that have the potential to affect (break) the work of other teams currently working on the Veteran-facing Services Platform (VSP).

For example:

• A new design pattern is added to the design system
• The Sketch file has been updated
• A change is made to how the feature flag works
• A change is made to how the website build process works
• A significant change is made to the content style guide

All instances of breaking changes should be posted to #vfs-all-teams.

The post needs to provide enough information so a designer, developer, or content person can know what they need to do in order to accommodate the change in their work. Some examples:

Sketch file has been updated to include new treatment for X. Find the Sketch file here [link].

We changed how the feature flag works. Instead of doing [describe the old way], you need to do X [describe the new way].

DSVA and Platform responsibilities

DSVA authorizes access for VFS teams

• To ensure we limit VA access to the right people, a DSVA person will add VFS team members.
  • If a new need arises (e.g., access to a new Github repo is needed), direct the request to the DSVA contact, who will determine access and permissions.

DSVA and the Platform team provide support

• DSVA and the Platform team will monitor the #vfs-platform-support Slack channel for product-focused questions/inquiries from VFS teams.

The Platform team can't direct VFS teams

The Platform team can't direct a VFS team's roadmap or tell them what project they should work on next. For example:

• What should I be working on?
• What task should I do next?

If these questions come up, the Platform team will ask the VFS team to contact their DSVA product contact.

However, we do want the Platform team and all VFS teams to collaborate because their projects will have dependencies and connections. For example, the Platform team may provide guidance or feedback on a VFS team's architecture so that adjustments can be made to allow dependent tools to work well together.

Gray areas

Questions are bound to come up that fall somewhere between "How do I?" and "What do I?" In these cases, the Platform team will direct VFS teams to their DSVA product contact, who will decide how to handle the question or request.

VFS team responsibilities

Look for documentation before posting a question in Slack (or contacting DSVA).

• See your team's Github "Product" folder or onboarding guides.
• If you don't find an answer, post your question in the #vfs-platform-support channel.

Use Slack channels for different purposes.

• For product questions use your team's "product" Slack channel.
  • Example question: "Where can I find previous research?"
• For process questions, use the #vfs-platform-support Slack channel.
  • Example questions: "I can't get the proxy to work" or "How do I integrate this into that?" or "How do I use Zenhub to do X?"
• For practice area questions use your practice area Slack channel (e.g., #design)

Use best communication method.

Slack - best communication method

• Slack channels allow us to do our work in the open so that others can learn from the questions asked and the answers provided. Please do the same.
• We discourage private Slack conversations (DMs) for the same reason.
• VFS teams should use public Slack channels as their first method of communication.

Meetings - slowest communication method

• If your team has a question about something, ask it in a Slack channel.
• Don't wait to organize a meeting to ask a question; this will slow down your team.

Email - least effective communication method

• Email communications aren't easily searchable or archivable.
• Use email as a last resort for communication.