Skip to content

Commit 1bd0389

Browse files
antonjim-teantonjim-te
committed
Follow OpenSource best practices
1 parent 91ae749 commit 1bd0389

10 files changed

Lines changed: 415 additions & 1 deletion

File tree

‎.github/CODEOWNERS‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
* @antonjim-te

‎.github/ISSUE_TEMPLATE/BUG_REPORT.md‎

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
---
2+
name: Bug Report
3+
about: Report a bug to help us improve
4+
title: ''
5+
labels: ''
6+
assignees: ''
7+
8+
---
9+
10+
## Description
11+
12+
Please provide a description of the problem.
13+
14+
## Expected Behavior
15+
16+
Please describe what you expected would happen.
17+
18+
## Actual Behavior
19+
20+
Please describe what happened instead.
21+
22+
## Affected Version
23+
24+
Please provide the version number where this issue was encountered.
25+
26+
## Steps to Reproduce
27+
28+
1. First step
29+
1. Second step
30+
1. etc.
31+
32+
## Checklist
33+
34+
<!-- TODO: Update the link below to point to your project's contributing guidelines -->
35+
- [ ] I have read the [contributing guidelines](/CONTRIBUTING.md)
36+
- [ ] I have verified this does not duplicate an existing issue

‎.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md‎

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
---
2+
name: Feature Request
3+
about: Suggest a feature for this project
4+
title: ''
5+
labels: ''
6+
assignees: ''
7+
8+
---
9+
10+
## Problem Statement
11+
12+
Please describe the problem to be addressed by the proposed feature.
13+
14+
## Proposed Solution
15+
16+
Please describe what you envision the solution to this problem would look like.
17+
18+
## Alternatives Considered
19+
20+
Please briefly describe which alternatives, if any, have been considered, including merits of alternate approaches and
21+
tradeoffs being made.
22+
23+
## Additional Context
24+
25+
Please provide any other information that may be relevant.

‎.github/settings.yml‎

Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
# These settings are synced to GitHub by https://probot.github.io/apps/settings/
2+
3+
repository:
4+
# See https://developer.github.com/v3/repos/#edit for all available settings.
5+
6+
# The name of the repository. Changing this will rename the repository
7+
name: .github
8+
9+
# A short description of the repository that will show up on GitHub
10+
description: Org-wide GitHub configurations
11+
12+
# A URL with more information about the repository
13+
#homepage: https://example.github.io/
14+
15+
# A comma-separated list of topics to set on the repository
16+
#topics: github, probot
17+
18+
# Either `true` to make the repository private, or `false` to make it public.
19+
#private: false
20+
21+
# Either `true` to enable issues for this repository, `false` to disable them.
22+
has_issues: true
23+
24+
# Either `true` to enable projects for this repository, or `false` to disable them.
25+
# If projects are disabled for the organization, passing `true` will cause an API error.
26+
has_projects: true
27+
28+
# Either `true` to enable the wiki for this repository, `false` to disable it.
29+
has_wiki: false
30+
31+
# Either `true` to enable downloads for this repository, `false` to disable them.
32+
has_downloads: true
33+
34+
# Updates the default branch for this repository.
35+
default_branch: main
36+
37+
# Either `true` to allow squash-merging pull requests, or `false` to prevent
38+
# squash-merging.
39+
allow_squash_merge: true
40+
41+
# Either `true` to allow merging pull requests with a merge commit, or `false`
42+
# to prevent merging pull requests with merge commits.
43+
allow_merge_commit: true
44+
45+
# Either `true` to allow rebase-merging pull requests, or `false` to prevent
46+
# rebase-merging.
47+
allow_rebase_merge: true
48+
49+
# Either `true` to enable automatic deletion of branches on merge, or `false` to disable
50+
delete_branch_on_merge: false
51+
52+
# Either `true` to enable automated security fixes, or `false` to disable
53+
# automated security fixes.
54+
enable_automated_security_fixes: true
55+
56+
# Either `true` to enable vulnerability alerts, or `false` to disable
57+
# vulnerability alerts.
58+
enable_vulnerability_alerts: true
59+
60+
# See https://developer.github.com/v3/teams/#add-or-update-team-repository for available options
61+
teams:
62+
# The permission to grant the team. Can be one of:
63+
# * `pull` - can pull, but not push to or administer this repository.
64+
# * `push` - can pull and push, but not administer this repository.
65+
# * `admin` - can pull, push and administer this repository.
66+
# * `maintain` - Recommended for project managers who need to manage the repository without access to sensitive or destructive actions.
67+
# * `triage` - Recommended for contributors who need to proactively manage issues and pull requests without write access.
68+
- name: org-admins
69+
permission: admin
70+
71+
branches:
72+
- name: main
73+
# https://developer.github.com/v3/repos/branches/#update-branch-protection
74+
# Branch Protection settings. Set to null to disable
75+
protection:
76+
# Required. Require at least one approving review on a pull request, before merging. Set to null to disable.
77+
required_pull_request_reviews:
78+
# The number of approvals required. (1-6)
79+
required_approving_review_count: 1
80+
# Dismiss approved reviews automatically when a new commit is pushed.
81+
dismiss_stale_reviews: true
82+
# Blocks merge until code owners have reviewed.
83+
require_code_owner_reviews: true
84+
# Specify which users and teams can dismiss pull request reviews. Pass an empty dismissal_restrictions object to disable. User and team dismissal_restrictions are only available for organization-owned repositories. Omit this parameter for personal repositories.
85+
dismissal_restrictions:
86+
users: []
87+
teams: []
88+
# Required. Require status checks to pass before merging. Set to null to disable
89+
required_status_checks:
90+
# Required. Require branches to be up to date before merging.
91+
strict: true
92+
# Required. The list of status checks to require in order to merge into this branch
93+
contexts: []
94+
# Required. Enforce all configured restrictions for administrators. Set to true to enforce required status checks for repository administrators. Set to null to disable.
95+
enforce_admins: true
96+
# Prevent merge commits from being pushed to matching branches
97+
required_linear_history: true
98+
# Required. Restrict who can push to this branch. Team and user restrictions are only available for organization-owned repositories. Set to null to disable.
99+
restrictions:
100+
apps: []
101+
users: []
102+
teams: []

‎.github/stale.yml‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# Configuration for probot-stale - https://github.com/probot/stale
2+
3+
# Number of days of inactivity before an Issue or Pull Request becomes stale
4+
daysUntilStale: 60
5+
6+
# Number of days of inactivity before an Issue or Pull Request with the stale label is closed.
7+
# Set to false to disable. If disabled, issues still need to be closed manually, but will remain marked as stale.
8+
daysUntilClose: 14
9+
10+
# Only issues or pull requests with all of these labels are check if stale. Defaults to `[]` (disabled)
11+
onlyLabels: []
12+
13+
# Issues or Pull Requests with these labels will never be considered stale. Set to `[]` to disable
14+
exemptLabels: []
15+
16+
# Set to true to ignore issues in a project (defaults to false)
17+
exemptProjects: false
18+
19+
# Set to true to ignore issues in a milestone (defaults to false)
20+
exemptMilestones: false
21+
22+
# Set to true to ignore issues with an assignee (defaults to false)
23+
exemptAssignees: false
24+
25+
# Label to use when marking as stale
26+
staleLabel: stale
27+
28+
# Comment to post when marking as stale. Set to `false` to disable
29+
markComment: >
30+
This issue has been automatically marked as stale because it has not had
31+
recent activity. It will be closed if no further activity occurs. Thank you
32+
for your contributions.
33+
34+
# Comment to post when removing the stale label.
35+
# unmarkComment: >
36+
# Your comment here.
37+
38+
# Comment to post when closing a stale Issue or Pull Request.
39+
# closeComment: >
40+
# Your comment here.
41+
42+
# Limit the number of actions per hour, from 1-30. Default is 30
43+
limitPerRun: 30

‎.github/workflows/scorecard.yml‎

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
name: scorecard
2+
3+
on:
4+
push:
5+
branches:
6+
# Run on pushes to default branch
7+
- main
8+
schedule:
9+
# Run weekly on Saturdays
10+
- cron: "30 1 * * 6"
11+
# Run when branch protection rules change
12+
branch_protection_rule:
13+
# Run the workflow manually
14+
workflow_dispatch:
15+
16+
# Declare default permissions as read-only
17+
permissions: read-all
18+
19+
jobs:
20+
run-scorecard:
21+
# Call reusable workflow file
22+
uses: cisco-ospo/.github/.github/workflows/_scorecard.yml@main
23+
permissions:
24+
id-token: write
25+
security-events: write
26+
secrets: inherit
27+
with:
28+
# Publish results of Scorecard analysis
29+
publish-results: true

‎CODE_OF_CONDUCT.md‎

Lines changed: 79 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
2+
# Contributor Covenant Code of Conduct
3+
4+
## Our Pledge
5+
6+
In the interest of fostering an open and welcoming environment, we as
7+
contributors and maintainers pledge to make participation in our project and
8+
our community a harassment-free experience for everyone, regardless of age, body
9+
size, disability, ethnicity, sex characteristics, gender identity and expression,
10+
level of experience, education, socio-economic status, nationality, personal
11+
appearance, race, religion, or sexual identity and orientation.
12+
13+
## Our Standards
14+
15+
Examples of behavior that contributes to creating a positive environment
16+
include:
17+
18+
- Using welcoming and inclusive language
19+
- Being respectful of differing viewpoints and experiences
20+
- Gracefully accepting constructive criticism
21+
- Focusing on what is best for the community
22+
- Showing empathy towards other community members
23+
24+
Examples of unacceptable behavior by participants include:
25+
26+
- The use of sexualized language or imagery and unwelcome sexual attention or
27+
advances
28+
- Trolling, insulting/derogatory comments, and personal or political attacks
29+
- Public or private harassment
30+
- Publishing others' private information, such as a physical or electronic
31+
address, without explicit permission
32+
- Other conduct which could reasonably be considered inappropriate in a
33+
professional setting
34+
35+
## Our Responsibilities
36+
37+
Project maintainers are responsible for clarifying the standards of acceptable
38+
behavior and are expected to take appropriate and fair corrective action in
39+
response to any instances of unacceptable behavior.
40+
41+
Project maintainers have the right and responsibility to remove, edit, or
42+
reject comments, commits, code, wiki edits, issues, and other contributions
43+
that are not aligned to this Code of Conduct, or to ban temporarily or
44+
permanently any contributor for other behaviors that they deem inappropriate,
45+
threatening, offensive, or harmful.
46+
47+
## Scope
48+
49+
This Code of Conduct applies within all project spaces, and it also applies when
50+
an individual is representing the project or its community in public spaces.
51+
Examples of representing a project or community include using an official
52+
project e-mail address, posting via an official social media account, or acting
53+
as an appointed representative at an online or offline event. Representation of
54+
a project may be further defined and clarified by project maintainers.
55+
56+
## Enforcement
57+
58+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
59+
reported by contacting the project team at [oss-conduct@cisco.com][conduct-email]. All
60+
complaints will be reviewed and investigated and will result in a response that
61+
is deemed necessary and appropriate to the circumstances. The project team is
62+
obligated to maintain confidentiality with regard to the reporter of an incident.
63+
Further details of specific enforcement policies may be posted separately.
64+
65+
Project maintainers who do not follow or enforce the Code of Conduct in good
66+
faith may face temporary or permanent repercussions as determined by other
67+
members of the project's leadership.
68+
69+
[conduct-email]: mailto:oss-conduct@cisco.com
70+
71+
## Attribution
72+
73+
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
74+
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
75+
76+
[homepage]: https://www.contributor-covenant.org
77+
78+
For answers to common questions about this code of conduct, see
79+
https://www.contributor-covenant.org/faq

‎CONTRIBUTING.md‎

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
# Contributing Guide
2+
3+
Thanks for helping improve the ThousandEyes observability dashboards! This guide explains how to plan a contribution, keep the dashboards consistent, and submit a clean pull request.
4+
5+
## 1. Before You Start
6+
7+
- Familiarize yourself with the existing dashboards described in `README.md`.
8+
- Make sure you can import/export dashboards in the observability platform you plan to update (Splunk Observability Cloud, Grafana, DataDog, Dynatrace, New Relic, or Signoz).
9+
- Use a feature branch from `main` for every change.
10+
11+
## 2. Repository Overview
12+
13+
- Each integration lives in its own directory (for example `grafana/`, `datadog/`, `splunk/`) and contains the canonical `ThousandEyesDashboard.json`.
14+
- Platform-specific docs or assets stay alongside the dashboard file (for example `grafana/grafana-setup.md`, `grafana/images/`).
15+
- Global documentation (like this file and `README.md`) belongs at the repository root.
16+
17+
## 3. Workflow at a Glance
18+
19+
1. Open or pick up a GitHub Issue. Describe the platform, the data source, and the motivation.
20+
2. Create a branch named `feature/<short-description>` or `fix/<short-description>`.
21+
3. Make the change, keeping commits focused and well-described.
22+
4. Test the dashboard in the target platform (see section 5).
23+
5. Submit a pull request referencing the issue, including screenshots when visual changes occur.
24+
25+
## 4. Editing Dashboards
26+
27+
- Keep the file name `ThousandEyesDashboard.json` unless there is a strong reason not to; tooling and docs assume that name.
28+
- Preserve backwards compatibility when possible (for example, avoid deleting existing charts unless absolutely necessary).
29+
- Use human-friendly labels, and keep units/descriptions consistent across platforms.
30+
- When adding queries or widgets:
31+
- Prefer existing ThousandEyes metrics and dimensions before inventing new ones.
32+
- Document any required tags, variables, or template parameters in a README section or platform-specific doc.
33+
- Run the platform’s JSON formatter/validator so the diff remains readable.
34+
35+
## 5. Testing & Validation
36+
37+
- Import the updated dashboard into the relevant observability backend and verify:
38+
- All charts render without errors.
39+
- Variables / template controls resolve correctly against sample data.
40+
- Thresholds, colors, and legends make sense for ThousandEyes metrics.
41+
- Capture an updated screenshot (`.png`) if the visual layout changes significantly and place it next to the dashboard JSON.
42+
43+
## 6. Documentation & Assets
44+
45+
- Update `README.md` if you add or remove an integration.
46+
- Keep setup instructions in platform-specific Markdown files (for example, `grafana/grafana-setup.md`).
47+
- Store images in an `images/` subdirectory under the platform folder. Use lowercase, hyphenated filenames.
48+
49+
## 7. Pull Request Checklist
50+
51+
- [ ] Dashboard JSON validates / imports without errors.
52+
- [ ] README and setup docs describe any new requirements.
53+
- [ ] Screenshots reflect the new state when visuals change.
54+
- [ ] Tests or manual verification steps are documented in the PR description.
55+
- [ ] Commits are squashed.
56+
57+
## 8. Need Help?
58+
59+
Open a GitHub Discussion or Issue with the details of the observability platform, the ThousandEyes metrics involved, and any errors you encounter. Someone from the maintainers or community will be happy to help.

0 commit comments

Comments
 (0)