Define Security Products Documentation Strategy

Problem to solve

There are already a number of issues that discuss improving the documentation around our ~Secure products. We have open discussions around the quality, information architecture, location, and strategies but many of these feel symptomatic rather than unifying with an overall strategy.

This issue is to discuss our preferred documentation strategy that will drive how we respond to issues around documenting our tools.

Further details

What do we want to document and What do we want to avoid documenting?

All documentation is a tradeoff between cost of maintenance of the documentation and providing maximum flexibility to our users, however with work on exposing more configuration (i.e. https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9676 and gitlab-org/security-products/sast!122 (merged)) we are moving further away from convention-over-configuration.

Related issues around documentation:

  • Documentation for security tools maintenance and availability https://gitlab.com/gitlab-org/gitlab-ee/issues/9986
  • Reorganize existing Secure features documentation https://gitlab.com/gitlab-org/gitlab-ee/issues/7189
  • Document all the available options for SAST https://gitlab.com/gitlab-org/gitlab-ee/issues/10120
  • Document all the available options for Container Scanning https://gitlab.com/gitlab-org/gitlab-ee/issues/10123
  • Document all the available options for DAST https://gitlab.com/gitlab-org/gitlab-ee/issues/10122
  • Document all the available options for Dependency Scanning https://gitlab.com/gitlab-org/gitlab-ee/issues/10121
  • Assumptive Consideration Journey Map for Security Tools ux-research#151 (closed)

Proposal

Reach internal consensus on a strategy for documenting Security Products including where product documentation should live (READMEs or gitlab-docs) and what should be documented.

Who can address the issue

cc @gl-secure

Assignee Loading
Time tracking Loading