> ## Documentation Index > Fetch the complete documentation index at: https://quester.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Project settings > Name and frame the project, shape its designs, tune the advisor's presence, and decide who works here. Project settings sits below the five spine items in the sidebar and separated from them, because it is configuration rather than work. It is a row of tabs covering General, Designs & references, Note sections, Advisor, Members, Workspace transfer, Project data and the Danger zone, and each one has its own address, so you can link a collaborator straight to the tab you mean rather than telling them what to scroll past. Most of it you will set once and forget. Two parts repay a proper read: the designs, which decide how your research questions get scored, and the advisor toggle, which is how you work without AI when you want to. ## General The project's name and description. The description is the same field as the one-line framing on [Overview](/manual/overview), and it is worth keeping current for the reason given there, since your advisor reads it at the start of every session and so will you, later, having forgotten what you meant. ## Designs & references The rubric your research questions get scored against. When Quester says a question *"needs sharpening"* on the Overview, it is comparing that question against four design dimensions, being research design, sampling design, measurement design and analytic design. This section sets which designs your project actually uses, drawn from your saved options, with an optional description of each approach. It matters because the scoring is only as good as the rubric behind it: score a qualitative project against a rubric that assumes randomised sampling and you get nonsense, and the fix lives here rather than in the questions. Set these once, early, to match how you actually work, and [Questions](/manual/desk-questions) covers what the scoring does with them. ## Note sections The vocabulary your notes get filed under. Quester ships the IMRaD-ish defaults (Introduction, Methods, Results and so on), but they are only a starting list. A project that does not write that way should change them rather than work around them. Add, rename and reorder them here, and the order you set is the order the picker shows everywhere in the app. Removing a section that has notes filed under it will not silently orphan them: the remove expands into a choice, either moving those notes to another section or leaving them unfiled, because the server refuses any path that would lose track of where a note belongs. ## Advisor Two controls, both scoped to this project. Project settings, Advisor section: an On/Off presence control captioned "On the days between meetings", with the notes field beside it. **Advisor presence**, On or Off, where Off keeps it out of the project completely, with no cards on Overview, no observations and no prompts, while everything else carries on working and the record stays yours. Treat this as a supported way to work rather than a degraded one, because if your supervisor is AI-sceptical, or you want a stretch of unassisted thinking, you can switch it off and the workspace is still a good workspace. **Notes for the advisor**, holding up to 4,000 characters of project-specific context such as terminology, committee preferences and what to leave alone. These are separate from the "about my work" statement in [Tuning the Advisor](/manual/advisor-preferences), which describes *you* across every project, whereas these notes describe *this project*, and both get read at the start of a session. The section is captioned *"On the days between meetings"*, which is the whole intent. ## Members Who works on this project, and what they can do. Workspace membership and project membership are two different things, since being in the workspace lets someone see that a project exists while being a member of the project is what opens its sources, notes and conversations to them. Add workspace members to the project from here, if you manage it. The workspace roster lives elsewhere, under People, as described in [Workspace settings](/manual/settings). ## Workspace transfer Moving a project to a different workspace, when you can reach more than one. There are two forms, moving it into a personal workspace of your own or into another workspace you have access to, and both ask you to confirm twice, because the consequences are real and the dialog states them: * **Existing project collaborators lose project-specific access.** They belonged to the old workspace. * **The current department link is removed.** Departments belong to a workspace. The project's own contents travel with it intact, meaning every source, note, question, model and journal entry. Use this when you leave a lab, when a project outgrows a shared workspace, or when it should have been yours from the start. ## Project data Your way out of the product, without mixing your research with the machinery Quester uses to run it. **Prepare export** creates a versioned zip of the work researchers authored, uploaded, connected, configured or deliberately saved: sources, notes and their revisions, questions, models, designs and evidence links, grants, reference sheets, journal entries, venue targets and project vocabularies. Portable tables and Markdown notes sit beside lossless JSON, and a manifest records record counts and checksums so the archive can support a future importer. Assistant conversations, advisor preferences and inferred facts are not part of the project archive. Neither are embeddings, caches, processing jobs, usage and billing events or private storage locations. Fields already saved on a real project record remain there regardless of whether a researcher or the advisor first populated them; their provenance remains visible in the exported data. Original PDFs and other uploads are optional because they can make an archive much larger. The panel shows their estimated size before you choose. A prepared archive is private to the member who requested it, remains available for 24 hours and reports any original object it could not recover without dropping that document's metadata. Run an export before anything irreversible, and run one now and then regardless, because work you cannot get out of a tool is work you have half lost already. ## Danger zone **Remove project** takes the project out of active work and asks you to click twice before it does. It is not a shredder, since the notes, sources, models and history are retained and a workspace manager can restore the project, and what changes is that it stops appearing in your workspace and in your own view of the work. Export before you remove something anyway, because a recoverable project still depends on someone with the right role being around to recover it, whereas a zip on your own disk does not. Next: [Sources](/manual/desk-sources).