Meds.com
Meds.com
Development Guidelines
🚩

Development Guidelines

✍️ Story Assignment in Azure DevOps

💡
For less experienced engineers, it is necessary to discuss the implementation plan with the Tech Lead or project lead before development.

Overview

  • The Tech Lead or Project Lead assigns the story in Azure DevOps.
  • Hierarchy: Epic → Feature → User Story → Task | Bug
  • Clarify the story scope prior to proceeding.

Task Breakdown

  • Divide the story into discrete tasks based on complexity and deliverables.
  • Each task should ideally correspond to a single Pull Request (PR). If a task necessitates multiple PRs, it should be re-scoped and divided accordingly. Combining several functionalities into one PR should be avoided.
  • Assign tasks to yourself or team members within Azure DevOps.

🔭 Pull Request (PR) Creation and Linking in GitHub

💡
Always link to Azure Task: Include AB#<TaskNumber> in the first line of the PR description.
  • Create separate branch for each task, our branch naming convention is:
    • For tasks: Task/<MMDDYY>-kebab-case-small-description
    • For bugs: Bugfix/<MMDDYY>-kebab-case-small-description
    • For urgent fix: Hotfix/<MMDDYY>-kebab-case-small-description
  • Push your branch to GitHub and create a Pull Request.
  • Provide a clear, concise description of the PR's contents.
    • For frontend/UI changes: include test cases, can be in form of text description, screenshots or brief demo videos.
    • Add labels to the PR if necessary, indicating its feature (e.g. AI, BC Gold, Multi-sub) and severity (e.g. hotfix, small).

⚖️ Requesting Reviews

💡
Always notify reviewers by clicking “Re-request review” after addressing their comments.
💡
The comment's author typically determines whether to resolve the comment.
💡
Following the merge, manually drag the Azure task to the "Closed" column
  • Request reviews when the PR's ready.
  • Reviewers must include:
    • The Tech Lead or project lead
    • Relevant members from the same group
    • Tag additional stakeholders if their input is deemed valuable.
  • Best practice: It is best for reviewers to review within 72h of the request
  • Move the corresponding Azure task to "Resolved" once the PR has been submitted for review.

Review Process

  • Utilize "Start a review" or "Add to review" in GitHub to block merging until feedback has been addressed.
  • Upon completion of the review round, check if there are outdated unresolved comments, then click "Submit review" and select "Request changes".

Addressing Review Comments

  • Update the PR to resolve all requested changes.
  • Repeat until all comments are addressed.

Merging the PR

  • Merge only after:
    • All review comments have been resolved.
    • All checks have passed.
  • If merging must be postponed (e.g., due to a release plan or dependency block):
    • The PR author must add a comment to block merging.
    • Add a dependency label to the PR to indicate release dependencies

🖼️ Image Handling for Front-end

💡
Always upload webp + png if there is transparent background, or jpg if there isn't one for optimization and speed purposes.
  • Original source size ≠ Export size
    • Images are scaled for layout in Figma, but original pixel data is preserved
  • Export images at 2× .jpeg the displayed size for higher quality support
  • Do not use original source exports unless explicitly specified

Last updated: @March 5, 2026