User Guide

Who is this for?

This guide is for engineering teams, team leads, managers, and operations stakeholders who use Pamela✨ GitHub Issue Bug Reminder to monitor unresolved bug issues and ensure they are followed up on in a timely, structured way.

Pamela✨ is designed to reduce delays in bug resolution by automatically checking open GitHub bug issues, sending reminder emails to assignees, and escalating unresolved issues up the management chain when necessary. Instead of relying on manual follow-up, Pamela✨ applies a clear reminder and escalation logic based on issue age and organizational reporting structure.

Primary users:

Bug Assignees — Receive reminder emails when a bug assigned to them remains unresolved past the defined threshold.

Managers — Receive escalation emails when a team member’s unresolved bug continues past the first reminder stage.

Senior Leaders / Higher Management — Receive higher-level escalations for persistent unresolved bugs that continue through multiple escalation cycles.

This feature is most useful if:

1. your team tracks bugs in GitHub,

2. bug issues are labeled consistently with “BUG”,

3. issues are assigned to owners,

4. and your organization has supervisory structure data available for escalation routing.

This feature is not intended to:

1. auto-assign or reassign bugs,

2. classify bug severity,

3. prioritize bugs with AI,

4. integrate with non-GitHub project tools in this version,

5. or send real-time streaming notifications.

Pamela✨ in this feature works as a scheduled reminder and escalation system, not a full issue-management platform.

---

Before We Begin (Getting Started)

For Pamela✨ GitHub Issue Bug Reminder to work properly, the following must be in place:

GitHub setup

1. The repositories to be monitored are configured.

2. The issues to be monitored are open issues.

3. Those issues are labeled with “BUG.”

4. Each issue has an assignee if it is expected to enter the reminder workflow. Issues without assignees are skipped.

Issue metadata

1. Pamela✨ uses issue information from GitHub to determine how long a bug has remained open and whether it should enter the reminder flow.

Email delivery

1. Pamela✨ sends notifications through Gmail integration.

2. Email recipients may include assignees, direct managers, and higher-level managers based on escalation stage.

Organizational data

1. Pamela✨ needs access to supervisory structure data so it can determine the correct escalation chain.

2. If supervisory data is missing or incomplete, Pamela✨ should handle that gracefully rather than failing completely.

Automation schedule

1. Pamela✨ runs on a daily automated check cycle by default, though the interval is configurable depending on deployment.

Overview

Pamela✨ GitHub Issue Bug Reminder is an automated follow-up system for unresolved GitHub bug issues.

It works by:

1. checking configured repositories for open issues,

2. filtering for issues labeled BUG,

3. identifying assigned owners,

4. checking how long the issue has remained unresolved,

5. applying the correct reminder or escalation rule,

6. sending email notifications,

7. and tracking notification history and escalation level over time.

At a high level, Pamela✨ helps teams make sure open bugs do not stay unresolved without visibility or follow-up.

---

Core Operating Rules

Pamela✨ follows several important rules in this feature:

Only open issues are monitored. Closed issues do not continue in the reminder or escalation flow.

Only issues labeled “BUG” are included. Other issue types are outside this workflow.

Issues must have assignees to enter the reminder flow. If a bug issue has no assignee, Pamela✨ skips it.

Escalation happens progressively every 7 days. After the first reminder, unresolved issues continue escalating up the hierarchy at 7-day intervals until resolved or until the highest organizational level is reached.

Pamela✨ checks resolution before sending any new reminder. If the issue has been closed, escalation stops.

Notification state is tracked. Pamela✨ records which reminder or escalation has already been sent so duplicate notifications are not sent unnecessarily.

How Pamela✨ Detects Eligible Bug Issues

On each scheduled run, Pamela✨:

1. fetches open issues from configured repositories,

2. filters issues with the BUG label,

3. identifies the assignee,

4. and stores the creation date for threshold calculations.

If an issue is:

1. not open,

2. not labeled BUG,

3. or missing an assignee, it is not processed for reminder delivery.

Reminder Logic for Bugs

Pamela✨ uses issue age to determine when reminders and escalations should be sent for unresolved bug issues.

First reminder

Pamela✨ sends the first reminder to the assignee when:

1. the bug is still open,

2. assigned,

3. labeled as BUG,

4. and has been open for 7 days.

This reminder includes:

1. issue summary,

2. GitHub issue link,

3. assignee name,

4. creation date,

5. and number of days the issue has remained open.

The first reminder is only sent once at that stage. Pamela✨ records that the reminder has already been sent so it does not send the same notification repeatedly.

Second reminder / manager escalation

If the bug is still unresolved 7 days after the first reminder, Pamela✨ sends an escalation email to the assignee’s direct manager.

That escalation includes:

1. issue summary,

2. GitHub link,

3. assignee name,

4. first reminder date,

5. and total number of days the issue has remained open.

Further escalation

As with due-date issues, unresolved bugs continue escalating every 7 days to higher management levels until the issue is closed or no higher escalation level exists.

This continues until:

1. the issue is resolved, or

2. the highest organizational level is reached.

Higher-level escalations include the escalation history, so leadership can see all previous reminder dates and recipients.

Escalation Chain

Pamela✨ uses supervisory structure integration to determine who should receive escalations.

The escalation path is:

1. assignee

2. direct manager

3. manager’s manager

4. next management level

5. continuing upward until the highest level is reached.

If Pamela✨ reaches the highest organizational level, it stops escalating further and logs that the top level has been reached.

When Escalation Stops

Pamela✨ stops reminder or escalation activity in these situations:

The issue is resolved or closed Before sending any new notification, Pamela✨ checks the issue status. If it is closed, no further reminders are sent. The notification record is updated to mark the issue as resolved, and the system logs the resolution date and final escalation level reached.

The highest escalation level has already been reached If there is no next management level, Pamela✨ does not continue escalating indefinitely.

Required supervisory structure data is missing If a manager cannot be identified, Pamela✨ should handle the situation gracefully, log the issue, and either skip the notification or route it to a fallback contact if configured.

What the Emails Contain

Pamela✨ uses different email templates depending on the notification type.

First reminder email to assignee

The first reminder focuses on the assigned owner and includes:

1. issue details,

2. GitHub link,

3. timeline details,

4. brief issue summary,

5. and action required.

Escalation email to manager

Manager escalation emails include:

1. issue details,

2. assignee name,

3. escalation timeline,

4. and a prompt for the manager to follow up with the team member.

Higher-level escalation

Higher-level escalation emails include:

1. issue details,

2. assignee,

3. direct manager,

4. escalation timeline,

5. and a stronger action-oriented message for leadership visibility.

Daily Automated Check Process

Pamela✨ does not wait for users to manually trigger reminders. It runs through a scheduled automated cycle.

On each daily run, Pamela✨:

1. starts the scheduled check,

2. fetches all relevant issues from GitHub,

3. processes them in batch,

4. applies threshold logic,

5. sends emails where required,

6. updates notification records,

7. and logs the results.

---

Example Scenarios

Scenario 1: Bug reaches reminder threshold

1. A bug issue is labeled BUG and assigned to an owner.

2. The issue remains open for 7 days.

3. Pamela✨ sends the first reminder to the assignee.

4. If the bug is still unresolved 7 days later, Pamela✨ escalates to the direct manager.

5. If it remains unresolved, Pamela✨ continues escalating weekly to the next management level.

Scenario 2: Issue closes after first reminder

1. Pamela✨ sends the first reminder.

2. Before the next escalation cycle, the bug is closed.

3. Pamela✨ detects the closed status and sends no further notifications.

Scenario 3: Missing assignee

1. A bug issue is open and labeled BUG, but no assignee is set.

2. Pamela✨ skips the issue and does not send a reminder until ownership is assigned

Troubleshooting & FAQs

Why didn’t a bug issue receive a reminder? Possible reasons:

1. it is not labeled BUG,

2. it is not open,

3. it has no assignee,

4. or it has not yet reached the reminder threshold.

Why didn’t escalation go to the manager? Possible reasons:

1. 7 days have not yet passed since the previous reminder,

2. the issue has already been resolved,

3. or supervisory structure data for the assignee is missing or incomplete.

Will Pamela✨ keep sending duplicate reminders every day? No. Pamela✨ tracks notification history and should not send duplicate reminders for the same threshold event.

What happens if GitHub API is down or rate-limited? Pamela✨ should log the issue, back off or retry later, and recover gracefully rather than crashing.

What happens if Gmail delivery fails? Pamela✨ should log notification attempts and failures, and recover gracefully from email service downtime.

Can Pamela✨ expose sensitive code or internal hierarchy details broadly? No. Email content should only include necessary issue metadata and should not expose sensitive information beyond what is needed for follow-up and escalation.

Current Limitations

This version of Pamela✨ does not support:

1. AI-powered prioritization,

2. automated bug assignment or reassignment,

3. severity analysis,

4. integrations beyond GitHub,

5. real-time streaming notifications,

6. or mobile application workflows.

It is a daily automated monitoring and escalation system, not a full issue-management platform.

---

End of Guide

Document Version: 0.1

Last Updated: April 2026

Subject to Change: This documentation may be updated as new features are added or requirements change.