Team Process Definition - Hinduino/CareerConnect GitHub Wiki

1. General Workflow

The team employs an Agile methodology driven by Atlassian Jira, which serves as our primary Agile tracker for logging user stories, organizing the backlog, prioritizing tasks, and managing sprint capacity. GitHub remains our central hub strictly for version control. Task management is organized using Jira issues, acting as the primary artifacts for defining user stories, technical tasks, and bug fixes. Each issue is categorized and assigned to specific team members to ensure clear ownership, visibility, and traceability across the entire sprint lifecycle.

​To maintain momentum and address project dependencies, prioritization is managed through the Jira project board's column structure, moving tasks through distinct phases: "To Do", "In Progress", "Ready for Review", "In Review", "Verification", and "Done". Urgent tasks and upcoming deliverables are governed by specific target completion dates and sprint allocations directly within Jira. Communication is intentionally compartmentalized to avoid clutter: technical discussions, code feedback, and integration details are kept directly within GitHub Pull Requests and threads, while broader strategic planning, team coordination, and official meeting minutes are managed through our dedicated Microsoft Teams channels.

​Maintaining a clean, readable version history is critical for our team's collaboration. Our commit standards dictate that every code push must be accompanied by a clear, descriptive, and atomic commit message outlining the specific changes made. Furthermore, developers are expected to reference the associated Jira ID directly in their commit summaries, ensuring a seamless link between our living codebase and our project management board.

2. Branching Strategy

The repository follows a feature-branch workflow to protect the production-ready code.

  • Main Branch: The main branch holds the stable, review-approved code.
  • Feature Branches: Developers create dedicated branches off main for specific user stories or bug fixes.
  • Merge Authority: To prevent integration confusion and maintain quality control, only 3 designated team members hold the authority to merge code into the main branch.

3. Pull Request (PR)

Process Pull Requests represent the gateway for integrating new features. A PR should only be created once the assigned user story is completely implemented and ready for review.

Naming Convention:

PR titles must strictly follow this format:

  • New features (Early development): NEW: (JIRA ID, e.g., SCRUM-666) [Title]
  • Added features (Standard): FEAT: (JIRA ID) [Title]
  • Bug fixes: BUG: (JIRA ID) [Title]

Description Requirements:

The PR body must include a summary of the important changes made, a direct link to the related Jira user story, and visual assets (images/screenshots) if they help demonstrate UI/UX changes.

Approval Gates:

Before any PR can be merged by the designated merge team, it must receive exactly two approvals. All merge conflicts, requested changes, and comment threads must be fully resolved beforehand.

4. Automated Pipeline (Planned for Sprint 2):

When a Pull Request is created, the code will go through a 4-stage automated pipeline to ensure quality and stability. At any stage, if the code does not respect the established standards or fails testing, it will not continue forward to subsequent stages.

  • Stage 1: Code quality & linting – The code is verified against structural and security standards. Any syntax errors, code formatting discrepancies, or security vulnerabilities are caught here before the code executes.
  • Stage 2: Unit testing – Each function, component, or UI utility logic is tested to guarantee it yields the desired output and that individual modules function properly.
  • Stage 3: API and integration testing – The communication between application components is tested, including authentication, database queries, and external APIs.
  • Stage 4: E2E Browser Testing – A browser environment is created to simulate user actions, ensuring the complete web app (UI, backend services, databases, and external APIs) works seamlessly end-to-end.

5. Code Review Process

The code review process relies on peer collaboration and strict communication protocols within the dedicated PR review channel.

Notification:

Once a PR is ready, the author posts a message in the PR channel containing:

  • Story Title
  • Link to the Jira Story
  • Link to the GitHub PR

Claiming a Review:

Two reviewers must claim the review by reacting to the channel message with a standard emoji.

Review Criteria:

Reviewers are required to:

  • Scrutinize the code carefully, leaving comments for any required clarifications or changes.
  • Suggest refactoring opportunities to make the code cleaner, simpler, and more maintainable.
  • Verify import statements to ensure only necessary modules/functions are imported (avoiding full library imports when only a small fragment is needed).

Discussion:

All questions and feedback must be kept within the specific message thread of that PR to avoid cross-conversation clutter.

Approval:

Once a reviewer approves the PR and verifies it is fully functional, they must react to the original channel message with a ✅ (green check mark) to signal completion.

6. Definition of Ready (DoR)

A user story is considered "Ready" for a developer to begin work when:

  • It is logged as a User Story in Jira with a clear title and description.
  • It is assigned to a specific sprint and team member.
  • If urgent, it is properly flagged within the "Deadline" folder.
  • The technical approach and acceptance criteria are understood by the assigned developer.

7. Definition of Done (DoD)

A user story is considered "Done" and complete when:

  • The code is fully implemented and tested locally.
  • Every push includes a valid description.
  • A PR is submitted using the exact naming and description conventions.
  • Two peer reviewers have reviewed the code, verified imports/cleanliness, and marked it approved (✅).
  • All PR comments and merge conflicts are resolved.
  • Verification Checkup: A final checkup is completed once testing and review are done, ensuring everything was covered and all pipeline tests pass.
  • One of the 3 designated merge managers successfully merges the PR into the main branch.
  • Final Status: The corresponding Jira story is moved to the final "Done" status, indicating the code is merged with a 100% passing pipeline.