Permissions
Our Confluence is viewable by anyone without an account.
The homepage is https://uwarg-docs.atlassian.net/wiki/home which lists out all spaces.
Edit permissions are granted to those who meet https://uwarg-docs.atlassian.net/wiki/spaces/AD/pages/2318500191/Member+Definition?search_id=259a624f-0256-4e81-8077-418636f8edb5 as per Data Handling.
Permission to grant edit permission is given to subteam leads (and some project managers) who are expected to verify member definition satisfaction when adding people to our confluence.
Some documents are not publicly viewable and some are restricted to only certain members in accordance with https://uwarg-docs.atlassian.net/wiki/spaces/AD/pages/2303033499/Private+Communications?search_id=93f43f95-c8ea-4793-9bb8-892ad5b8ae05.
Note there are very very few of these pages.
Having admin doesnt let you see all locked confluence pages; locked pages need to be manually shared with desired recipients.
Use Case
Confluence is used by WARG for all of our:
documentation
Technical Content
User Manuals
Design Decisions
Administration Content
Onboarding Procedures
knowledge base information
relevant information to our sub-teams
research processes
meeting minutes
all of our meeting minutes must go in confluence: https://uwarg-docs.atlassian.net/wiki/spaces/Meetings
timelining
in a limited capacity confluence can be used for timelines
would like to shift this to Asana over time
task delegation
in a limited capacity confluence can be used for task delegation
would like to shift this to Asana over time
What should be documented?
Of course everything that’s documentation should go into confluence but what needs to be documented? In short nothing needs to be documented until we have a problem or foresee an imminent problem if said documentation does not exist. More specifically nothing needs to be documented until:
We are unsure of a decision and would like scrutiny from others
We want to share and collaborate on our engineering process
We want people in the future to reference the material
When you arrive at a justification for any design decision please add into the confluence doc for future reference so that if anyone questions a design decision you have the answer ready to go
We don’t want to repeat ourselves over and over again saying the same information
For more details please see Approach to Documentation .
Why did someone link a confluence doc to me?
Often times we send links in response to questions or when we see conversations. This is done because we want the people to read said document as we believe it either answers the question asked or contains relevant information that will assist in the conversation. Most of our confluence docs are extremely short, if someone links you one, please please please at least give it a skim to see if it helps you out!
Should note confluence has a mobile app as well. If someone links you a doc please read it. Even if you've read it before it may have been updated recently! Most confluence docs are intended to be brief and digestible.
Linking a confluence document is not intended to be rude though can be easily perceived that way. This can be extremely discouraging, impersonal, and impolite. Please ensure when linking a confluence document maybe add some fluff as a preamble to ensure it is interpreted correctly, for example:
I believe <link> may answer this question, please have a look and let me know.
This information can be found in <link>. Please let me know if you have further questions.
I believe <link> contains relevant information to this conversation.
If you <link> doesn't make sense, please let me know and we can chat it out.
If I have a question where should I start?
If you have any question on WARG it’s recommended you start by searching Confluence to help you, if that doesn’t work be that squeaky wheel and ask for help!
Consequences of failing to handle data and documentation correctly
Not to roast other SDC teams but as of F23 WARG is up there for our documentation standards. This is a deliberate effort pushed to ensure the team can keep expanding and growing. As a student team the absolute max tenure any individual has on the team is four years and realistically the maximum we see is closer to two years because of FYDP and co-op (see Time Commitment ). This means that if we do not document we will lose knowledge and we will not progress forward. Team leads from other SDC teams have reported extreme difficulty in onboarding new members and integrating existing systems due to a lack of proper data handling and documentation. Please avoid these pitfalls in accordance with Individual Reliance .
What if I disagree with a Confluence Document?
A confluence doc, specifically the policy ones, are not intended to be a decree from directors, they are meant to be malleable and discussable! As time goes on we will gain more knowledge and therefore improve our systems. All confluence docs should have justification for the statements they pose. If such justification is not obvious please ask for clarification from others! Please ask specific questions to get specific answers/discussions; broad questions are generally addressable by confluence documentation! When new high level team policies are created they should be discussed in leads meetings to ensure the team agrees. If any major discussions need to happen for existing policies leads meeting is the place for that to occur!
Professionalism
Beware the WARG Confluence is completely public. Please do not use it (or other WARG resources) for personal (or any non-WARG) projects. Keep in mind Redistribution Policy . Further we like to send the WARG confluence to others (companies, student design teams, university, etc.) so ensure everything in confluence is professional.