Help documentation
Pealboard is work management on GitHub Issues and Projects, with portals for the people who are not on GitHub.
GitHub is the system of record. Every issue, comment, label, milestone, project and project field value you see in Pealboard exists in GitHub first, in one of the repositories you connected. Pealboard holds only what GitHub cannot: who a customer is, which portal a request came through, which comments a customer may see, your saved views, your notifications, and billing.
Where to start
Section titled “Where to start”| If you are | Read |
|---|---|
| Setting Pealboard up for the first time | The five steps |
| Adding colleagues and deciding what they may do | Workspaces and members |
| Looking for work across repositories | List, table and board |
| Opening a portal for customers | Create a portal |
| Wiring Pealboard into a script or an agent | API keys and the developer documentation |
| Unsure what a word means | Glossary |
What this documentation assumes
Section titled “What this documentation assumes”It assumes you have a GitHub account and that your organization already uses GitHub Issues. It does not assume you write code, use Git, or know what a pull request is. Where a GitHub term is unavoidable, it is explained the first time it appears.
Three rules that explain most behavior
Section titled “Three rules that explain most behavior”- A write goes to GitHub first, then to Pealboard. If GitHub refuses the write, you see GitHub’s own refusal and nothing was changed.
- Customers see nothing from GitHub unless a member marked it public. The default for a comment written in GitHub is internal.
- A request is an issue. Removing a request from a portal deletes the request record. The issue in GitHub is not changed.