Real-Time Collaboration (RTC) in comment and/or threads to replace internal GDocs dependency

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Internal teams at Gitlab depend heavily on GDocs for real-time collaboration during customer calls, team meetings, company meetings, etc. Google Drive is not well structured, difficult to maintain/govern, and creates additional complexity and overhead by having sources of truth in both Google Drive and Gitlab - let alone being expected to duplicate these truths to each environment for them to only fall out of sync.

Real-time collaboration (RTC) within the comment and/or threads section of an issue would facilitate a single source of truth, as well as simplifying the organizational structure considering each comment has a time-stamp, is embedded within an issue, and each issue is within a project that is (ideally) transparently maintained by the relative team. In short, this would remove our dependency upon GDocs for running-documentation, dramatically reducing our tool complexity (and in turn increase efficiency) with regards to in-house documentation and collaboration.

Index

Minimum Viable Change

Real-time collaboration (RTC) within the issue's comment thread to facilitate "running doc" requirements internally at Gitlab.

(Simplest) Create GDoc from comment

  1. From a comment I can select the "GDoc" button

Screen_Shot_2020-03-04_at_3.14.55_AM

  1. Will leverage GDoc API to create a document on Drive
    • In the post it will apply the 'issue title' as Title format within the GDoc header
    • In the post it will apply the 'comment' body in Header2 format within the GDoc at the highest line below the header
      • Will be hyperlinked to the comment within the issue
    • GDoc subtitle will be the issue number
      • Hyperlinked to the issue
    • Will post information such as "Assignees" into templated fields, along with any other relative context for the doc from the issue. Screen_Shot_2020-03-04_at_5.23.12_AM

(More Complex) Have a full real-time collaboration environment within either the comment or the thread itself.

  • Would replace need for GDocs entirely
  • Would highly resemble GDocs workflow but be within the Gitlab ecosystem
  • No options for GDoc embed, and couldn't find much on open source options (outside of IDE stuff)
    • May be more practical to go with the "More Complex" option if between the two

(Most Complex) Firebase (GCP) + Firepad/Monaco (Gitlab WebIDE)

  • Manage documentation within the WebIDE with new RTC capabilities
  • Somehow embody the running documentation into the codebase
    • Maybe a solid use-case for the wiki?

Screen_Shot_2020-03-04_at_2.21.29_AM

Our GCP environment offers some free Firebase resources for testing

Argument

Real-time within a thread has greater impact than real-time title or description, IMO.

  1. Real-time in the title and/or description would be fine at first, but eventually the convenience of editing in those locations would greatly out-weight the need for comments and before you know it descriptions would be gigantic dialogues that we see in gdocs - at least for sale's teams. They wan't gdocs, and if something works like gdocs and the "preferred" way doesn't, they will not care and will forge a path against the expected use-case for descriptions.

  2. Threads are greatly under-utilized by many non-dev folks, but especially the sales teams. If we facilitated a GDoc'esk collaboration environment, then it would improve the feature's applicability to all and help to keep necessary documentation organized and close to the relative issue/project.

  3. Putting it in a thread "within" a comment applies an inherited structure, such as the subject of the comment itself as context, timestamps/ledger, etc (separation of concerns). In short, this would replace our need for "running gdocs".

Running gdocs are what you see in the reoccurring meetings where each new meeting will be given a space at the top of the doc, often separated by "-----------" or something similar.

  1. Stakeholders within the sales structure often need to see data like "Made call with Ben" with the comment being related to an opportunity, etc. Having the doc posted as a thread to a comment would work well for sales folks in this fashion:

    • Comment: "Conference call with Mark and TVA team"
      • Thread: "GDoc - Conference call with Mark and TVA Team" (with the text being hyperlinked to the GDoc, and the GDoc back to the commend thread)

  2. This feature would enable us to (to my knowledge) do just about everything we need for each opportunity within the sales org - serving as a single source of truth. In other words, we would be able to use Gitlab for the sales workflow instead of scattered tools.

Context

We currently use GDocs for real-time collaboration during calls, meetings, conferences, etc. Sales folks are required to duplicate work by pasting stuff from the GDoc into the issue - which usually results in them not doing it. In short, the typical federal sales team member barely uses Gitlab and overall hesitates to do so due to duplication of work.

Pains

  • Multiple sources of truth not in sync (GDocs, Gitlab, Salesforce)
  • Lack of dog-fooding (No one wants to duplicate work from GDocs into Gitlab)
  • GDocs is simply better than Gitlab at this - additional tool complexity.
  • GDrive is very unorganized and lacking structure

Value prop

  • Single source of truth with 'ledger' structure embedded within project containing relative context
  • Single tool for sales teams' opportunity information and the necessary collaboration
  • Comment threads can be used for iterative, running documentation
    • We commonly add "--------" into a GDoc to imply a new section of a running doc. This can be facilitated by simply creating a new comment and then enabling a real-time running doc within the thread section.
    • Customer conversations would be easily found by navigating into the relative opportunity project and viewing the comments, in time-stamped order, expanding the comments that indicate that they contain a real-time thread within.
    • Removes the need for "Running Document" for each opportunity on GDrive (Difficult to find/manage)
  • Sales team would be more inclined to use Gitlab
    • Most sales folks that I have spoken to on this have made it clear that they fear working in the Gitlab ecosystem as they find it sub-par to using GDocs - some of this has to do with Markdown too.
  • GDrive would only be necessary for some GSlides and personal notes here and there, rather than being leveraged as a knowledgebase for sales opportunities within unorganized GDocs.
Edited by 🤖 GitLab Bot 🤖