What Is a Shared Presence?¶
Purpose, Principles, and What Makes One Worth Building¶
The Problem This Solves¶
Most group project websites look the same.
A title. A short description. A list of names and student numbers. A YouTube link added in the final week. Sometimes a repository link, if the group remembered.
These sites exist because someone asked for them. They were built quickly, updated once, and abandoned. They communicate almost nothing about the quality of thought behind the project — and they do nothing for the group beyond satisfying a requirement.
This is not what a shared presence is for.
A shared presence built with intention does something different. It makes a project visible while it is still happening. It communicates progress, not just outcomes. It gives clients, supervisors, and external readers something real to engage with — and it gives each team member a shared context to point to from their individual work.
The difference between the two is not technical skill. It is purpose.
What a Shared Presence Actually Does¶
A well-built shared presence serves four distinct audiences simultaneously.
For the group itself, it creates a shared reference point. When decisions are documented and progress is visible, team members stay aligned. New directions are easier to communicate. The project develops a coherent identity that holds across the semester, rather than drifting differently in each member's head.
For the client or partner — in projects with a real external stakeholder — it provides visibility without requiring constant meetings. A client who can see that the project is progressing, that decisions are being made, and that their brief is being taken seriously, is a client who trusts the team. Trust reduces the kind of anxiety that generates unnecessary check-ins and scope changes.
For supervisors and lecturers, it provides context for supervision conversations. A supervisor who can see the timeline of decisions and progress arrives at meetings already oriented. The conversation becomes about the work, not a summary of it.
For external readers — potential employers, professional contacts, other students — it demonstrates professional practice. Not just what was built, but that a team worked on something real, with real people, over a real period of time. That distinction matters to anyone evaluating a graduate's readiness for professional work.
What Distinguishes a Meaningful Shared Presence¶
The difference between a directory entry and a genuine shared presence comes down to three qualities.
It shows progression, not just completion¶
A shared presence built at the end of a project is a record of outcomes. A shared presence built across the project is a record of work.
Readers — especially employers — are more interested in how a team worked than in the polished result alone. A timeline that shows decisions, pivots, problems, and milestones is more convincing than a final demo video, because it cannot be faked. It was either updated across the semester or it was not. That honesty is visible, and it is valued.
It explains, not just lists¶
A project name and description is a label. An explanation of what problem the project solves, for whom, and why the team approached it the way they did is a story.
Stories are what people remember and engage with. Every element of a shared presence should earn its place by explaining something — not just naming it. A technology stack listed without context tells a reader nothing. The same stack described with a sentence about why those choices were made tells them something about how the team thinks.
It connects to individual work¶
A shared presence that exists in isolation — with no link to the individual people behind it — misses the most important function it can serve.
Each team member should be represented individually: their role, their area of contribution, and ideally a link to their own Guide B showcase. This transforms a group page into a professional anchor — the shared context from which each individual story becomes intelligible to an external reader. Without it, the site describes a project. With it, the site introduces a team.
What a Shared Presence Does Not Replace¶
It is worth being specific.
A shared presence does not replace Guide A individual records. Those remain private, personal, and the foundation of each individual's showcase. Nothing from a personal Vestigia record should be published to a shared presence without deliberate, individual choice.
A shared presence does not replace Guide B individual showcases. Each team member still develops their own narrative, their own extraction, their own professional artefact. The shared presence provides context — it does not do that work for them.
A shared presence does not replace subject deliverables — reports, proposals, sprint documentation, WIL artefacts. Those requirements exist independently. A shared presence is additional and optional.
The relationship is additive, not substitutive.
The Question of Platform¶
Different groups will use different platforms. That is expected and appropriate.
CS, IT, and Engineering groups with development capability can build and publish a live website using GitHub Pages. This is the most professionally resonant option for technical groups — it demonstrates exactly the kind of skill these students are developing, and it integrates naturally with an existing project repository.
Groups in other disciplines — or technical groups who prefer not to build from scratch — have other options: Notion, Google Sites, WordPress, Behance, and others. The choice of platform matters less than the choice of content and the discipline of maintaining it.
A thoughtful Notion page updated regularly throughout the project is more valuable than a polished website touched once.
Specific platform guidance is available in the documents that follow this one.
Liveness — The Most Important Quality¶
Of all the qualities that distinguish a meaningful shared presence from an empty one, liveness matters most.
A shared presence last updated in week three of a six-month project tells a reader something — and it is not something the group wants communicated.
Liveness does not mean daily updates. It means:
◆ regular, brief additions when something meaningful happens
◇ dated entries so progression is visible over time
◆ honest notes on where the project is, not just where it should be
◇ a sense that real people are working on a real thing in real time
The easiest way to maintain liveness is to treat shared presence updates as a natural part of sprint reviews, milestone completions, or supervision meetings. When the group discusses progress, someone notes it. Brief, dated, honest. That habit — small, consistent, real — is what makes a shared presence worth having.
Assign ownership early
Shared presence updates tend to fall through the cracks when no one owns them. Early in the project, decide which team member is responsible for posting updates — and agree on what triggers an update: sprint reviews, client meetings, major decisions, completed milestones. The content should come from the whole group; the act of posting it should belong to someone specific.
When to Start¶
The answer is earlier than you think.
A shared presence started in the first or second week of the project captures the full story — from the initial problem definition through to the final demonstration. A shared presence started in the final month captures only outcomes.
Starting early does not mean publishing a finished site. It means establishing the presence, adding what you know at that point, and committing to updating it as the project develops. A simple page with a clear problem statement, a first timeline entry, and a team section — published in week two — is worth more than a comprehensive site published the week before submission.
The project timeline is the most valuable element of any shared presence. It can only be built if you start building it when the project does.
In Summary¶
A shared presence is not a website requirement. It is a deliberate choice to make your project visible — to clients, supervisors, and the professional world — in a way that reflects the quality of work behind it.
Done well, it:
◆ communicates progress rather than just outcomes
◇ connects individual contributions to collective context
◆ demonstrates professional habits to external readers
◇ gives each team member a shared anchor for their individual showcase
Done poorly, it is a form filled in and forgotten.
The difference is intention — and timing.
If your group is building a project website, continue to Building a Project Website.
If your group is in a non-technical discipline or exploring other platforms, continue to Shared Presence for Other Disciplines.