How do you keep track of work from a reported problem to a released fix?
Keep one record for the problem, the person handling it and the result you expect. Add the proposed change when it is ready. Close the work after you know the fix reached users and the app behaves as expected.
When do you need a project management tool?
Start with one list you already use. Add a tool when a second person needs to pick up work, you keep losing decisions, or you need to follow a change through review and release.
| What you have | What to record |
|---|---|
| A task you can do next | Name the action, its owner and the result that would let the owner put it down. |
| A customer report about something that broke | Capture the steps, what actually happened and what should happen. Leave personal data out of a shared example. |
| A request or a product decision | Keep the reason and the chosen direction. Link to a task when someone takes responsibility for the next change. |
How do you take one issue from report to release?
Use a pretend booking app that gets stuck on “Saving” when it rejects a request before saving. You can do this rehearsal on paper. If you later use a test app, verify that its data is separate and that it cannot send real messages, charge anyone or create real bookings.
- Write what should happenGive the issue one owner. Write how to reproduce the problem, then write the result you expect. A rejected fake request should show “Couldn’t save. Try again.” and save nothing. A successful fake request should show one confirmation and save one booking.
- Attach the proposed changeGive the issue a short ID and add a link to the code proposal or a paper placeholder. A pull request is a proposed change to code. Keep the expected results on the issue so the next person knows what to check.
- Review the exact versionHave the person reviewing it check both outcomes in the disposable preview, or compare both on paper. Record which version they checked. If the proposal changes afterward, review the revised version before merging it into the shared code.
- Check the release separatelyImagine the proposal was approved and merged but customers still see the old page. Keep the issue waiting for release. Record the release that contains the fix. At the customer address, check any read-only evidence that the intended version is live, such as an existing version label. Run checks that save data, send messages or charge money only in an isolated test copy of that version.
Compare tools
Scroll the table sideways to read every column.
| Tool | Work coordinationWhat you create first and where the decision or test notes go. | Code linksWhat you can follow from the task and where code review happens. | Agent permissionsWhat controls the data and actions available to an agent. | Project exportWhich task records and discussion can move, and what needs a separate copy. | Guest costsWhat access an outside collaborator gets and how the role is billed. |
|---|---|---|---|---|---|
| Linear | Start with one issue, assign an owner and attach a longer decision if needed. | Link GitHub work with the issue ID. Reviews inside Linear need selected repository code access and a personal GitHub connection. GitHub controls approval and merge. | Linear Agent acts within the user’s access. Installed agents use the teams and action permissions they are granted. A delegated issue can keep a human owner. | Issue CSV keeps task fields. Selected issue Markdown can include comments and requests. Keep attachment files separately. | Free workspace users are admins. Restricted guests are available on Business and Enterprise and billed as regular members. |
| Notion | Start with a task database. Each item opens as a page for test notes or a decision. | Keep a pull request link on the task. The Business database sync copies selected GitHub fields as read-only data. Review comments and approval details stay in GitHub. | Notion Agent uses the user’s access. A Custom Agent has its own permissions and can expose information to people who cannot open the original page. | Export full-page databases as CSV and pages as Markdown or HTML. Check files and settings separately before moving. | Page guests are separate from paid workspace members and have a plan limit. Check the permissions of each shared page. |
Who gets to approve a change?
The issue owner makes sure the work meets the expected result. For code, an eligible reviewer records approval on the proposed change under the repository’s rules. An agent can propose work while a person remains responsible for checking it.
Check who can see an issue and who can see the code before connecting the tools. An integration can copy issue details or imported repository information into a place with a different audience. Start with a link that the reviewer can already open.
If an agent needs access, give it the specific project or task it needs. Find out what it can change and who can ask it for results before sharing it with a wider group.
What should you take with you if you move the project?
Keep the task records, the decisions they depend on and any files people need to finish or verify the work. Try moving one issue before switching the whole team.
Open the sample copy in the destination. Check the issue ID, status, owner, one comment or decision and one attachment. A link in a spreadsheet tells you where a file was. Open that link as the person who will need it or keep a separate copy.
Write down which system will own status changes after the move. Leave the old board available while people check links and access, then stop using it for updates.
What changes when you invite an outside collaborator?
Decide what the person needs to see and do before inviting them. A client who only needs to review one decision has a different job from a teammate who manages the full backlog.
Check whether the plan offers a restricted role and whether it charges for that person. Confirm access in connected tools separately. Someone might be able to open the task without being allowed to see its linked code or files.