Updating IDP Homepage Docs - #39393
Conversation
Added section for configuring homepage and updated with GitLab and Linear integrations
Preview links (active after the
|
domalessi
left a comment
There was a problem hiding this comment.
Thanks, Amrita! Some feedback inline, plus some overarching things:
Prerequisites
Setup requirements show up in Prerequisites and again under GitHub, GitLab, Jira, and Linear, and they've already drifted a bit. I also think the Prerequisites format can be cleaned up a bit.
Something like:
The Homepage aggregates data from your Datadog integrations. Configure the following before using the Homepage.
**GitHub**
Required for the **GitHub** tab in **Your PRs**. An administrator configures the GitHub integration and webhook, and each user signs in with their GitHub account.
[Set up the GitHub integration][1].
**GitLab Source Code**
Required for the **GitLab** tab in **Your PRs**. An administrator configures the GitLab Source Code integration and webhook, and each user signs in with their GitLab account.
[Set up the GitLab Source Code integration][2].
**Jira**
Required for the **Jira** tab in **Your Tickets**. An administrator configures the Jira integration and webhook.
[Set up the Jira webhook][3].
**Linear**
Required for the **Linear** tab in **Your Tickets**. An administrator configures the Linear integration and webhook.
[Set up the Linear webhook][4].
How much UI to document
Several lists describe every status group and column. Useful for agents that can't see the product, but it drifts fast and is hard to maintain. I suggest trimming -- short statement of what the tab is for, plus anything you can't get from the UI.
| - **Comment counts**, including resolved and unresolved discussion counts | ||
| - **Age**, shown as the time since the last update | ||
|
|
||
| Like GitHub, this tab requires two setup steps, in order: an administrator connects the GitLab integration for the organization, and each user signs in with their own GitLab account. After you authorize access, the tab loads your merge requests, grouped by status. |
There was a problem hiding this comment.
Prerequisites already cover the GitLab Source Code integration and webhook. Repeating them here is what drifted out of sync with the GitHub tab.
| Like GitHub, this tab requires two setup steps, in order: an administrator connects the GitLab integration for the organization, and each user signs in with their own GitLab account. After you authorize access, the tab loads your merge requests, grouped by status. | |
| After you sign in with your GitLab account, the tab loads your merge requests, grouped by status. For setup steps, see [GitLab Source Code][2]. |
| - **Priority** | ||
| - **Due** | ||
|
|
||
| An administrator authorizes the Linear integration for the organization. After setup, Datadog detects your assigned issues, and they appear automatically. For setup steps, see [Linear][4]. |
There was a problem hiding this comment.
Same as GitLab: keep setup in Prerequisites so these sections don't drift.
| An administrator authorizes the Linear integration for the organization. After setup, Datadog detects your assigned issues, and they appear automatically. For setup steps, see [Linear][4]. | |
| After setup, your assigned issues appear automatically. For setup steps, see [Configure a Linear webhook][4]. |
| - **Due** | ||
| - **Assignee** | ||
|
|
||
| An administrator configures the Jira integration and sets up a Jira webhook so that issue events reach Datadog. After setup, your assigned tickets appear automatically. For setup steps, see [Configure a Jira webhook][3]. |
There was a problem hiding this comment.
Same trim as Linear so the two ticket tabs stay parallel.
| An administrator configures the Jira integration and sets up a Jira webhook so that issue events reach Datadog. After setup, your assigned tickets appear automatically. For setup steps, see [Configure a Jira webhook][3]. | |
| After setup, your assigned tickets appear automatically. For setup steps, see [Configure a Jira webhook][3]. |
| - **Assignee / Reviewer** | ||
|
|
||
| This section requires two setup steps, in order: an administrator connects the GitHub integration for the organization, and each user signs in with their own GitHub account. After you authorize access, the section loads your pull requests, grouped by status. | ||
| This tab requires two setup steps, in order: an administrator connects the GitHub integration for the organization, and each user signs in with their own GitHub account. After you authorize access, the tab loads your pull requests, grouped by status. |
There was a problem hiding this comment.
Trimming this keeps the GitHub and GitLab tabs parallel. The permissions list and empty-state prompt below are still worth keeping; they aren't in Prerequisites.
| This tab requires two setup steps, in order: an administrator connects the GitHub integration for the organization, and each user signs in with their own GitHub account. After you authorize access, the tab loads your pull requests, grouped by status. | |
| After you sign in with your GitHub account, the tab loads your pull requests, grouped by status. |
| - Checks: Read | ||
|
|
||
| The section also requires a configured GitHub webhook so that pull request events reach Datadog in real time. For setup steps, see [GitHub][1]. | ||
| The tab also requires a configured GitHub webhook so that pull request events reach Datadog in real time. For setup steps, see [GitHub][1]. |
There was a problem hiding this comment.
Delete this line. Webhook setup and the GitHub docs link are already in Prerequisites, and the empty-state sentence above already links the GitHub tile.
| - **Assignee / Reviewer** | ||
|
|
||
| This section requires two setup steps, in order: an administrator connects the GitHub integration for the organization, and each user signs in with their own GitHub account. After you authorize access, the section loads your pull requests, grouped by status. | ||
| This tab requires two setup steps, in order: an administrator connects the GitHub integration for the organization, and each user signs in with their own GitHub account. After you authorize access, the tab loads your pull requests, grouped by status. |
There was a problem hiding this comment.
If you keep these setup steps rather than trimming them as suggested on this paragraph, use a numbered list. Sequential steps shouldn't live in one sentence.
| This tab requires two setup steps, in order: an administrator connects the GitHub integration for the organization, and each user signs in with their own GitHub account. After you authorize access, the tab loads your pull requests, grouped by status. | |
| The **GitHub** tab requires two setup steps: | |
| 1. An administrator connects the GitHub integration for the organization. | |
| 2. Each user signs in with their own GitHub account. | |
| After you authorize access, the tab loads your pull requests, grouped by status. |
| - **Comment counts**, including resolved and unresolved discussion counts | ||
| - **Age**, shown as the time since the last update | ||
|
|
||
| Like GitHub, this tab requires two setup steps, in order: an administrator connects the GitLab integration for the organization, and each user signs in with their own GitLab account. After you authorize access, the tab loads your merge requests, grouped by status. |
There was a problem hiding this comment.
Same as GitHub: if you keep these steps rather than trimming them, use a numbered list.
| Like GitHub, this tab requires two setup steps, in order: an administrator connects the GitLab integration for the organization, and each user signs in with their own GitLab account. After you authorize access, the tab loads your merge requests, grouped by status. | |
| The **GitLab** tab requires two setup steps: | |
| 1. An administrator connects the GitLab Source Code integration for the organization. | |
| 2. Each user signs in with their own GitLab account. | |
| After you authorize access, the tab loads your merge requests, grouped by status. |
| --- | ||
|
|
||
| {{< img src="tracing/software_catalog/idp_homepage.png" alt="IDP Homepage showing a personalized view of GitHub pull requests awaiting review and Jira tickets" style="width:100%;" >}} | ||
| {{< img src="tracing/software_catalog/idp_homepage.png" alt="IDP Homepage showing a personalized view of pull requests awaiting review and tickets" style="width:100%;" >}} |
There was a problem hiding this comment.
Don't overwrite idp_homepage.png in place (same for services_entities_table.png). Add the new screenshots under new filenames and update the Markdown. See Update Image Repository.
There was a problem hiding this comment.
The new screenshots need to be added under new filenames, and you'll need to update the Markdown. More details here: https://datadoghq.atlassian.net/wiki/spaces/docs4docs/pages/1985314888/Screenshots+and+Videos#Update-Image-Repository.
| --- | ||
| title: Homepage | ||
| site_support_id: idp | ||
| description: The Internal Developer Portal Homepage gives you a centralized view of your team's entities, GitHub pull requests, Jira tickets, and Datadog Work Items in one place. |
There was a problem hiding this comment.
Should update to include GitLab and Linear
Added section for configuring homepage and updated with GitLab and Linear integrations
What does this PR do? What is the motivation?
Merge readiness
For Datadog employees:
<name>/<description>convention and include the forward slash (/). If you've already created your PR with an incorrect branch name, please rename your branch and open a fresh PR./reviewto run an automated check that catches common issues before a Documentation team member reviews your PR.AI assistance
Additional notes