Skip to main content

How to Review a Feature

info

This guide is for stakeholders who have been asked to review a feature that is pending approval. It walks through what to look for, how to provide feedback, and how to formally approve or request changes.

Overview​

When a new feature or change is ready for stakeholder review, you'll be tagged in a comment on the GitLab issue for that feature. GitLab will send you an email notification with the comment and a direct link to the ticket — click that link to go straight to the issue and begin your review.

You can also visit the Pinpoint development board at any time and look at the Under Review list to see all tickets currently pending stakeholder review.

Your review helps ensure the feature meets requirements, is easy to use, and aligns with the goals of Pinpoint.

Before You Begin​

Before starting your review, make sure you have:

  • Access to GitLab — You should have an account on code.umd.edu and be able to view the issue you were tagged on.
  • Read the Review Instructions in the ticket — Every ticket includes a Review Instructions section written by the developer. This section contains a link to the preview environment, step-by-step testing instructions, the expected behavior, and any specific areas the developer wants you to focus on. Start here before doing anything else.
  • Context on the feature — Read through the issue description and acceptance criteria to understand what the feature is supposed to do and why.
  • A clear understanding of the target users — Know who the feature is for (e.g., students, makerspace staff, administrators) so you can evaluate it from their perspective.

What to Review​

Start by following the Steps to Test provided in the ticket's Review Instructions section. Once you've verified the core workflow, use the checklist below to evaluate the feature more broadly.

GitLab Review Instructions

1. Functionality​

  • Does the feature work as described in the requirements?
  • Follow the testing steps in the ticket — does the workflow complete successfully?
  • Test edge cases — what happens with empty inputs, unexpected values, or unusual sequences of actions?

2. Usability​

  • Is the feature intuitive? Could a new user figure it out without instructions?
  • Are labels, buttons, and messages clear and consistent with the rest of Pinpoint?
  • Is the flow logical? Are there unnecessary steps that could be simplified?

3. Visual Design​

  • Does the feature look consistent with the rest of the application?
  • Is the layout clean and readable on both desktop and mobile?
  • Are loading states, error messages, and empty states handled gracefully?

4. Accessibility​

  • Can you navigate the feature using only a keyboard?
  • Are interactive elements clearly labeled?
  • Does the color contrast seem sufficient for readability?

5. Requirements Alignment​

  • Does the feature match what was originally requested?
  • Are there any missing pieces or unexpected additions?
  • Does it integrate well with existing features?

How to Provide Feedback​

When providing feedback, follow these guidelines to keep the process efficient:

Be Specific​

Instead of "this doesn't look right," try "the date picker on the scheduling page doesn't show the correct time zone."

Categorize Your Feedback​

  • Blocker — Something that must be fixed before the feature can ship (e.g., broken functionality, data loss risk).
  • Improvement — Something that would make the feature better but isn't required for launch (e.g., a minor layout tweak).
  • Question — Something you're unsure about and want clarification on.

Where to Leave Feedback​

All feedback should be left as comments on the GitLab issue you were tagged on. This keeps everything in one place and makes it easy for the development team to track and respond.

GitLab Review Instructions

When commenting on the issue:

  • Text feedback — Describe what you observed and what you expected. Be as specific as possible.
  • Screenshots — You can paste or drag-and-drop images directly into a GitLab comment. Use screenshots to highlight visual issues, unexpected layouts, or confusing UI.
  • Screen recordings — For interaction issues or multi-step problems, a short screen recording is very helpful. Record your screen, then attach the file to your GitLab comment.
tip

On macOS, press Cmd + Shift + 5 to take screenshots or record your screen. On Windows, use Win + Shift + S for screenshots or the built-in Xbox Game Bar (Win + G) for recordings.

Approving or Requesting Changes​

Once you've completed your review, leave a comment on the GitLab issue indicating your decision:

  • Approve — If the feature meets requirements and you have no blockers, leave a comment confirming your approval (e.g., "Looks good, approved!").
  • Request Changes — If there are blockers, clearly list what needs to change in your comment. The development team will address the feedback and tag you again when updates are ready for another look. After you've commented, move the ticket back into the Awaiting Changes list so the developer knows it needs attention.

GitLab Board - Move Back

Timeline Expectations​

  • Reviews should ideally be completed within 3 business days of the review request, prior to the end of the sprint, and before the Sprint Retrospective & Planning meeting.
  • If you need more time, communicate that to the development team so timelines can be adjusted.
  • Prompt reviews help keep the project moving — your input is valuable and time-sensitive.

Questions?​

If you're unsure about anything during the review process, reach out to the development team directly. We're happy to walk through the feature with you or clarify any requirements.