Project Management Setup

Before coding starts, your team needs shared order — where things live and how work moves forward.
In a software project, structure and process act like a city map: streets (folders) organize space, and traffic lights (issues) control movement. Without both, you get chaos even if everyone has good intentions.

Glossary

Repository – Your project’s official home on GitLab, containing code, docs, and issue tracking.
Folder Structure – The arrangement of files and directories in the repo.
Placeholder File – A dummy file (like .gitkeep) to keep empty folders under version control.
README – The first file visitors see; explains what’s inside and how to use it.
Issue – A tracked piece of work: a bug, task, feature, or note.
Label – A colored tag that classifies issues (e.g. bug, enhancement, blocked).
Assignee – The team member responsible for an issue’s next step.
Board – A visual view of issues (columns like “To Do → In Progress → Review → Done”).
Definition of Done (DoD) – The team’s checklist for when a task is truly finished.
Workflow – The steps issues move through, defining who does what and when.

Designing a Folder Structure

A good folder layout saves time and arguments.
Think of it like organizing a shared kitchen: if everyone keeps tools where they want, no one can find the salt.

Start simple:

/src/        → source code
/tests/      → automated tests
/docs/       → documentation and setup guides
/resources/  → static assets (images, data, configs)

Add README.md or .gitkeep files so empty folders appear in Git.
Git ignores empty directories by default, so placeholders are your way of saying, “This space is reserved.”

Tip

Explain why your structure looks the way it does.
Future teammates (or your tutor) should understand your logic in seconds.

Example

In your main README:
“We separated /frontend and /backend so both can be built and tested independently.”

Ask a new teammate to find a file using only your README — if they need to ask for help, improve the layout or documentation.

Danger

Over-organizing early is a trap.
Start minimal and extend only when real needs appear.

Finally, create and commit a .gitignore that excludes caches, build outputs, and IDE configs.
A clean repo is easier to share and less likely to break on another machine.

Managing Issues and Workflows

Issues are the heartbeat of your project — each one represents a concrete piece of progress.
Without them, work disappears into chat messages and memory.

Define your issue lifecycle before adding tasks.
Example flow:

To Do → In Progress → Review → Done

Info

These columns are more than decoration.
They describe the states your work passes through, and who moves it along.

Decide:

• Who moves issues between states? (usually the assignee)
• When can an issue be marked “Done”?
• What labels mark blockers, bugs, or documentation tasks?

Tip

Write a clear Definition of Done (DoD) — for example:
“Code reviewed, tested, merged, and documented.”
If any part is missing, it’s not done yet.

Create at least one example issue of each kind (feature, bug, documentation).
This teaches your team what “good” looks like and gives you templates for future work.

Example

A strong issue title:
“Add search field to product list page” — short, specific, and action-oriented.
A weak one:
“Search thing maybe?”

Use labels and milestones consistently. Visual clarity on the board speeds up coordination and review.

Linking Issues to Git and Commits

Every piece of code should trace back to a purpose — that’s what issue linking provides.
When you include a reference like Fixes #12 in a commit or merge request, GitLab automatically closes the issue once merged.

Tip

This simple habit keeps your board current without manual cleanup.
Try it early and verify it works in your project.

Linking also makes your project transparent: anyone can follow a change from problem to solution without guessing.

Reviewing and Evolving Your Process

Once your structure and workflow are in place, walk through one complete example as a team:
Create an issue → Assign → Work → Commit → Merge → Close.
If something feels clunky, open an issue labeled workflow-improvement and refine it.

Quote

“A process is good when it’s invisible — it helps without getting in the way.”

Your folder structure and issue lifecycle will evolve, but the key principle stays:
make the invisible visible — structure and workflow are shared agreements, not personal habits.