# LECO > An academic platform where a student's question becomes a project with named roles and people who fill them. A question turns into a proposal, the proposal gathers people into declared roles, activation opens a shared workspace, and the finished work is published back as a public resource. The funnel is the product, and no stage can be skipped. LECO is in early access. It is not public yet and no launch date has been announced. This file summarises the public landing page; every statement below is taken from that page. ## Pages - [LECO (French, default)](https://learning-connection.org/): the landing page in French, the product's main language. - [LECO (English)](https://learning-connection.org/en/): the same landing page in English. - [LECO (Italian)](https://learning-connection.org/it/): the same landing page in Italian. ## The problem LECO addresses Knowledge scatters across three places that never talk to each other. The question vanishes with the conversation that answered it. The work moves to a generic tool — a board, a shared folder — cut off from the discussion that produced it. Results never come back: the project ends, the report stays on someone's drive, and the next person meets the same problem without knowing it was solved. LECO closes that loop, then turns the result into a public resource. ## The funnel: five stages, none skippable 1. **Question** — a public post tied to one to five mandatory topics and to one or more courses. Title 10–250 characters, body 30–20,000. Markdown, code blocks, mathematical formulas, mentions, six attachments. A question can quote another three levels deep, and once created the link never moves. Language is derived from the profile rather than declared. The asker picks one best answer — a switch, not a vote count. 2. **Proposal** — declares a goal, an expected result, and the open roles with how many people each needs. States: draft, gathering contributors, ready to activate, activated. Becoming ready is reversible: if someone withdraws, the proposal steps back on its own. A proposal originates from a question, from a topic, or from itself — never from two at once. 3. **Adherence** — a declared commitment to fill one specific role, accepted by someone. States: pending, then accepted, rejected or withdrawn. One live application per person per proposal; a rejection does not block a second attempt. The proposer reviews applications one by one. 4. **Activation** — when the conditions are met the proposal becomes a private Project Space for the committed group. Each accepted contributor gets the view of their role. The proposal page stays linked as the record of origin. 5. **Output** — nine kinds: report, paper draft, comparison table, dataset, prototype, bibliography, synthesis, presentation, open resource. States: draft, in review, approved, published. Internal to the group it is one step; public review is mandatory. An output attaches to an epic and nothing else. The create menu has two entries — ask a question, create a project proposal. There is no "create project" button, the column tying a project to its proposal is mandatory, and no endpoint creates a project directly. ## Project Space Work items come in six types across four states, seen through three views over the same data — list, board and timeline — never copies. The blocked state cannot be declared; it is computed from whatever blocks the item. - **Hierarchy** — task and bug sit under a story or an epic; feature and story under an epic only; a subtask requires a parent; an epic has none. An item with children can no longer change type. - **Dependencies** — two link types, "blocks" and "relates to". The graph checks for cycles on every change and refuses the one that would create one. - **Permissions** — 32 permissions across seven areas compose into reusable role templates. Requesting permission to transition an item automatically adds reading it and reaching the workspace. An incoherent role does not get built. Item numbers are never reused, not even after a deletion. ## The six surfaces a project holds - **Questions** — the public Q&A, flat: one question, one to N answers. - **Discussions** — the group's own conversations, which it can close. - **Work** — items and their states, and what blocks what. - **Updates** — status posts on the project timeline, public or internal, always approved. - **Outputs** — the deliverables and their review. - **Resources** — links, files, notes, or an answer from the public Q&A reused by the project. ## Who it is for Primary audiences: students, researchers and teachers. Secondary audiences: research groups, editorial teams and training programmes. Profiles carry first name, last name, bio, university, department and academic level, and are public on the open web. ## Deliberately absent, permanently No votes or upvotes — the asker picks one best answer instead. No nested comments: Q&A is flat and there is no comment entity. No anonymity, and no anonymous mode ever. No leaderboards, no reputation score, no badges, no levels, no streaks. ## Accounts and access No password, ever. Sign-in is by passkey or magic link sent by email. Opening the link does not consume the token — an explicit confirmation is required, which defends against mailbox security scanners that would otherwise burn the link by opening it. Links last fifteen minutes and are single use. Requesting early access takes a name and an email. ## Principles Nothing gets read outside its context. A rule counts only when breaking it is impossible — eleven rules are enforced by the database rather than by the code's good intentions. The result becomes public again, and review is mandatory before anything goes public. The asker decides, and the question's history stays public. Identity is real. Attention is asked for: notifications are batched over sixty minutes and the weekly digest is off by default. ## Languages French is the main language; English and Italian are available from day one.