Student

The student role is the most workflow-heavy day-to-day experience. In the real platform, the journey starts before proposal upload. Students move from group formation into proposal submission, then into milestone delivery, and finally into evaluation readiness and final defense.

Why this role is the most visible

If most staff roles see the platform as a control system, students see it as the academic journey itself.

This role touches the largest number of workflow surfaces across the product. In practice, students experience group-leader approval, team formation, proposal creation, milestone submission, feedback loops, revision cycles, progress tracking, and defense readiness as one connected path rather than as separate administrative steps.

Fastest route through this guide

1. Read Landing area to see the student workspace.
2. Read Student journey from group formation to final defense for the real end-to-end path.
3. Read Core responsibilities to understand what students actually need to do, not just where they click.
4. Read Operational checkpoints if you want the recurring progress loop.
5. Continue to Project lifecycle if you want the full operating path by stage instead of by student experience.

Landing area

• Dashboard: /dashboard/student
• Key sections: my-project, team, submissions, milestones, upload-documents, defense, timeline, messages, announcements

Student journey from group formation to final defense

The student journey is strongest when documented as one continuous path.

Stage 1: Become eligible to lead or join a group

Before proposal work starts, the student has to enter the project-group layer correctly.

The current frontend and backend support two different early paths:

• a student can apply to become a group leader / project manager
• a student can browse existing groups and send a join request

The platform already exposes this in the team flow with real student tabs such as:

• My Group
• Browse Groups
• My Requests
• Become Manager

The current backend also confirms this behavior through student endpoints for:

• POST /group-leader-requests
• GET /group-leader-requests/me
• POST /project-groups/:groupId/join-requests
• GET /project-groups/me/join-requests

Stage 2: Form the project group

Once a student is approved as a group leader, group formation becomes the next major responsibility.

The current platform supports a real group-formation flow where the approved group leader can:

• create a draft group
• invite students directly
• approve or reject join requests
• remove members while the group is still editable
• submit the completed group for department review

The frontend team page already describes the process as:

1. Create group
2. Invite or accept members
3. Submit for approval
4. Wait for official registration

This matters because the proposal flow does not start from an isolated student account. It starts from an approved project group structure.

Stage 3: Wait for group approval and official registration

Students should not be described as immediately moving from team creation to proposal upload.

The group itself has a real lifecycle with states such as:

• DRAFT
• SUBMITTED
• APPROVED
• REJECTED

This means the student journey includes a real department-review step before the group becomes the official project unit.

Stage 4: Submit the proposal as the approved group leader

After group approval, the student group leader starts the proposal phase.

The current product behavior is clear:

• only an approved student group leader can create the proposal draft
• proposal mode lives inside the student upload flow
• the student provides three title options and uploads the proposal PDF
• the student submits the proposal for coordinator or department-head review

This is why the student page should connect the team, upload-documents, and submissions areas instead of treating them as unrelated pages.

Stage 5: Revise or move into an active project

After proposal submission, the student waits for review.

From the student perspective, two outcomes matter:

• if the proposal is rejected, the group revises and resubmits
• if the proposal is approved, the system creates a real project and the student journey moves into milestone-driven work

That approval is a major shift in the platform. After this point, the student is no longer only managing a proposal package. The group is operating inside a real project with milestones and advisor context.

Stage 6: Work through milestone delivery and advisor feedback

This is the longest and most repeated part of the student experience.

The current milestone flow already supports:

• milestone visibility on the student side
• upload of the current deliverable
• advisor feedback on the latest submission
• resubmission after feedback
• approval that unlocks the next milestone

The student dashboard, milestone page, submissions page, and upload page all work together here.

Stage 7: Prepare for evaluation and final defense

Late in the journey, the student experience changes from submission-heavy work into readiness-heavy work.

The defense page already frames this clearly: students prepare materials, track readiness, and stay aligned with final defense requirements.

At this stage, students need to watch:

• defense schedule details
• readiness percentage and checklist items
• final materials upload requirements
• late-stage communications from staff and evaluators

Stage 8: Reach the final defense as a prepared group

The student-side endpoint of the platform is not just “submission complete.” It is arrival at the final defense with:

• an approved group
• an approved proposal turned into a project
• milestone progress completed in sequence
• defense materials prepared
• schedule and venue information visible in the student workspace

First actions after invitation acceptance

1. Change the temporary password on first login.
2. Open the team area and confirm whether you need to apply as a group leader, join an existing group, or manage your current group.
3. Confirm your current stage: group formation, proposal, active project, or defense preparation.
4. Review the timeline, milestone expectations, and any pending submission or feedback work.
5. Track defense readiness and communications once the project reaches the late stage.

Core responsibilities

The student role is not only about uploading files. It is the role that converts platform workflow into academic progress.

Project and proposal ownership

• understand whether the group is still forming, waiting for group approval, in proposal mode, or already operating as an approved project
• keep the project context, team context, and required deliverables visible
• follow the department-defined sequence instead of skipping ahead to later work
• respond correctly when a proposal or milestone is sent back for revision

Group formation and team readiness

• understand whether the student is acting as a group leader or a group member
• apply to become a group leader when needed
• create or join a project group through the supported workflow instead of assembling the team outside the platform
• monitor group approval, join-request status, invitations, and official registration before proposal work begins

Submission and revision work

• upload proposal, milestone, and supporting files at the correct stage
• monitor whether a submission is still awaiting review or has already received feedback
• revise using actual advisor or staff feedback rather than uploading another version blindly
• track which milestone is open now and which next step is still locked

Late-stage readiness

• monitor project progress as defense approaches
• prepare final materials, checklists, and required readiness items
• follow defense schedule details carefully
• stay responsive to late-stage communications and readiness gaps

What the dashboard is designed for

The student workspace includes:

• group formation and team coordination surfaces
• project progress visibility
• milestone completion tracking
• document and deliverable submission
• defense preparation surfaces
• grade or concern-related actions where available

Operational checkpoints

Students usually experience the platform as a repeating progress loop, not a single one-time submission flow.

Checkpoint 1: Current stage clarity

The first question is always whether the student understands the current academic stage correctly.

Questions to answer:

• is the student still in group formation, waiting for group approval, preparing a proposal, or already operating inside milestone delivery
• which milestone or submission is active right now
• is the next action upload, wait, revise, or prepare for defense

Checkpoint 2: Group readiness

Before proposal work starts, the team has to exist in the right platform state.

Questions to answer:

• is the student approved as a group leader or clearly acting as a member
• is the group still editable, already submitted, or officially approved
• are join requests, invitations, and membership decisions already resolved

Checkpoint 3: Submission quality

The platform works better when students treat each upload as a meaningful academic deliverable rather than a checkbox.

Questions to answer:

• does the current submission actually match the requested deliverable
• has the group uploaded the right file for the right stage
• are there missing materials that will likely trigger preventable feedback

Checkpoint 4: Feedback response

Student progress often stalls not because work is impossible, but because feedback is not interpreted well enough.

Questions to answer:

• has the group read the latest feedback carefully
• is the next resubmission actually addressing the advisor's concerns
• is the group stuck in a repeated revision loop that needs clearer guidance

Checkpoint 5: Readiness for the next stage

Each stage should prepare the student for the next one, not only complete the current one.

Questions to answer:

• is this milestone strong enough to support later evaluation work
• is project progress healthy enough for late-stage review
• are defense readiness tasks being handled before the schedule becomes urgent

Practical handoff model

The student role moves through a series of supervision and review relationships.

Phase	Primary student job	Typical handoff
Group formation	become a group leader or join a group, then reach approved registration	coordinators review the submitted group for official approval
Proposal stage	prepare and submit the project idea correctly	coordinators and department heads review and decide
Milestone delivery	upload work, respond to feedback, and improve the project	advisors review, guide, and approve progress
Evaluation preparation	maintain project quality and readiness	evaluators take over formal scoring responsibility
Defense stage	prepare materials and appear ready for the scheduled session	staff and evaluators manage the formal session workflow

What success looks like

Students are using the platform well when the project reaches this state:

• the team is formed and officially approved before proposal work starts
• the team always knows which stage it is in and what comes next
• submissions and resubmissions reflect actual feedback, not guesswork
• milestone progression stays aligned with the department sequence
• late-stage readiness work starts before the defense window becomes rushed
• the platform feels like a guided journey instead of a confusing set of disconnected pages

Product snapshot

Onboarding note

Student onboarding only starts after the department head has invited the user and the invitation has been accepted. Unlike the department head, students do not create the environment. They enter an environment that should already be configured.

In the current platform, the student path also splits early between:

• students who apply to become approved group leaders and manage team formation
• students who browse groups, send join requests, and enter as group members

That difference should be visible in the docs because it changes what the student sees first inside the team area.

Common mistakes to avoid in the docs

• Do not describe the student role as only a file-upload role. It is the main workflow experience of the platform.
• Do not treat proposal, milestone, and defense work as unrelated pages. Students experience them as one connected journey.
• Do not start the student story at proposal upload only. Group formation and group approval happen first.
• Do not imply students control staffing, approvals, or evaluator assignment. Those remain staff-owned operations.
• Do not present revision as failure only. Revision is a normal academic loop in the platform and should be documented that way.

Best page after this one

If you want to do next...	Go here	Why
Understand the full student operating path	Project lifecycle	It shows how proposals, milestones, and evaluation connect.
Understand the real early student path before proposals	Student group formation and approval	It covers group leader approval, group creation, join requests, and official registration.
Understand the proposal phase after group approval	Proposal review and approval	It explains the upload-first proposal flow and review outcomes.
Understand milestone and submission work	Milestone delivery and advisor review	It covers the repeated submission-feedback cycle students experience.
Understand late-stage defense readiness	Evaluation and defense workflow	It shows how student readiness connects to evaluator work and the final defense.

Best next reads

• Project lifecycle
• Student group formation and approval
• Proposal review and approval
• Milestone delivery and advisor review
• Evaluation and defense workflow