How should we coordinate as contributors/maintainers?

[Michiel-VandeVelde]

Hi everyone, since more people are getting involved and the repo is moving pretty fast, should we maybe align a bit on how we want to coordinate?

Nothing overly formal, just things like where quick questions should go, when to keep discussion in PRs/issues, how to avoid duplicate work, and how to flag stuff that needs another reviewer or specific testing.

I’d assume PR/issue-specific context stays there, but for broader coordination it might be useful to agree on a dedicated channel or workflow. Since the repo is getting pretty large, having one place for maintainer/contributor coordination could help avoid confusion and keep things moving.

That could be GitHub Discussions, a dedicated chat channel like Discord/Matrix/Slack for quick coordination/problem solving, or some other lightweight collaboration workflow, whatever fits the project/maintainers best. Personally, Discord would work well for me, but I’m happy to adapt to whatever the group prefers.

One thing that might also be worth clarifying: for potential security vulnerabilities, especially anything involving serious issues, we probably shouldn’t disclose details publicly before there’s been a chance to review and fix them. Maybe those should go through a private maintainer channel or whatever security reporting flow the project/maintainers prefer.

Also, I’d avoid sharing personal emails in public threads and stick to GitHub handles or a private channel for dedicated maintainers if needed.

Curious what everyone prefers.

— Michiel

[CoolJohn-lab]

Discord is a data broker. Although you probably won't expose anything sensitive on the Oddy channel, I still think that using a known data broker as a comms channel for a tool intended to help you avoid data brokers is a bad look. Plus three people have already made discords, and they all suck. Apart from the data capture stuff, Discord as a platform actually sucks. It invites lurking and sniping since you can't ever tell who's online.

I would start an IRC channel on a privacy-focussed IRC network, or better yet start a new IRC network..

[Michiel-VandeVelde]

That’s a fair point, and I get the concern around Discord for a privacy-focused project.

My main goal is just having a clearer place for faster coordination, not Discord specifically. GitHub should stay the source of truth either way, especially for PRs/issues/decisions and anything security-sensitive.

IRC could be worth considering, but I’d mainly want us to avoid splitting across multiple unofficial channels again. Maybe we should first agree on what we need by getting the main contributors/maintainers together

[CoolJohn-lab]

Yes what is clearly lacking is an "official" place for discussion. I think Discord has made everyone so lazy and unimaginative in this regard, anything vaguely related to tech or anything online, the default approach to having any kind of community site is "oh just make a Discord". With no other options even considered. maybe a Subreddit, and then you have to deal with Reddit mods shudder. I actually hate it. I'm a member of over 100 discords, and I never even look at any of them any more, it's all just people talking the same inane crap in #general, in every single one, totally unrelated to what it was originally supposed to be about.

There's a sort of unwritten rule in a Discord that if you go on it and actually start talking about the thing the Discord is meant to be about, that's uncool, you're "glazing" and "cringe", and you should just lurk and occasionally post animated gifs...

Any official channel needs to come from Pewds, Nobody will agree on one place to use unless he approves it. But not a god damn Discord. Anything else. I'd rather use AOL Messenger.

When I started out on the internet, hackers, coders, crackers, pirates and "leet" folk of all types, all hung out together on IRC. It was the cool kids club, and we didn't let anyone in that even had a MySpace account, much less actually used it. We scoffed at people using the "World wide web", that was the internet for NOOBS. I say we bring it back. Bring back being snobbish and aloof, bring back /kick and /akick just to mess with people.... IRC!!!!!

Discord is just a skin over the top of IRC, BTW, it's all IRC underneath.

[sacb0y]

Outside of their office space blender just uses a dedicated dev forum.
https://devtalk.blender.org/

[CoolJohn-lab]

Equally fine, the venerable forum website has been around almost as long as IRC.

[tronbonjovi]

tbh - felix needs to assign an official team to help organize/structure the project.
where that communication takes place, is sort of irrelevant.

think of it like this:

Felix learned to cook up a bunch of dishes, created a menu and now opened a restaurant.
Overwhelming number of people are inspired and want to help - they have different levels of skill, some have worked in kitchens, even been head chefs themselves, but some cant explain how to make toast.

the problem is the kitchen is full.. there's too many cooks in the kitchen.
because there's so many people in the kitchen, it's hard to move around without bumping into something and potentially breaking it..

the kitchen is noisy, hard to understand whats going on:

the folks in the kitchen who have worked in kitchens before are all looking around thinking "where's the chef? what's the menu? what station am I covering? who's running the show here?" - because they know how to get involved and be helpful

the folks in the kitchen who have not worked in kitchens before, and have no idea how 'things work' in kitchens, are asking how to eat the food - because they don't understand the different between the kitchen and a dinning room, they're just excited to be here.

Nobody is wrong or bad here, it's just a lack of structure/organization. That stuff takes effort, and it's not easy to know where to start whenever you're jumping into a new industry/area without a ton of experience or guidance.

The project is incredibly interesting to follow and watch evolve. Felix just needs to take a little time to find someone he can trust to step in and help fill some of the gaps that inexperience creates, that will lead to building a team and setting some boundaries/guidance for how to contribute to the project, so the maintainers can start being productive instead of treading water with the sea of PRs and issues being added hourly.

(non of this is meant to be negative towards anyone, just constructive critism)

[CoolJohn-lab]

Ok but I think where the kitchen actually is does matter.

[tronbonjovi]

Ok but I think where the kitchen actually is does matter.

the kitchen = github

edit: I get what you mean though! and agree! :)

[alteixeira20]

great analogy, I used to be a Chef and that was trully spot on!

[Michiel-VandeVelde]

I’m responding to this after spending around 9 hours moving AI-generated content, closing duplicate issues/discussions, and trying to keep the repo somewhat manageable, so I want to clarify a few things.

First of all, the main reason I opened this discussion was because I think we need to get the core maintainers together in some kind of group, call, or meeting.

Why? Because developing good code and managing a massive project with a lot of contributors are two completely different things....There are clearly a lot of people with all kinds of domain knowledge who are willing to help, but I dont think we’ve really asked the bigger question yet of does @pewdiepie-archdaemon actually want all this extra hassle of the decision-making, managing a team, handling contributor flow, triage, onboarding, review coordination, and all the process work that comes with a project growing this fast?

He has clearly stated this is a passion project for him. I do believe he wants to see it grow, but I also believe he probably enjoys the process of coding, making cool features, experimenting, and enjoying the work more than managing a whole team around it.

so thats exactly why that kind of burden a dedicated maintainer group he can trust could and should take over, not to take anything of the project away from him, but to let him spend more time doing what he actually loves to do, while trusted maintainers handle the operational side: triage, duplicate cleanup, contributor onboarding, review routing, docs coordination, and keeping the project organized.

So to me, the first question is not really should we use discord, IRC, forum, or something else?? The main question is: what does Felix want to own/do personally, and what does he want to delegate? until we know that stick me on a hobbyhorse, give me a helmet and let me charge trough this beautifull mess

Much love,
Michiel

ps: Yeeeeehaw

[alteixeira20]

I wanted to add a bit of context from my side, since I’ve been spending a good amount of time on triage/review recently.

First and foremost, I agree with the point already made above: a lot depends on the direction @pewdiepie-archdaemon wants to take, and how he wants to handle the project moving forward. It is his project, and larger product/roadmap decisions should stay with him and the maintainer group, not happen accidentally through individual PRs.

The way I’m trying to help right now is mostly operational: doing whatever seems most useful to unblock the repo, whether that is triage, review cleanup, CI signal, duplicate/stale PR cleanup, small focused fixes, or making sure merge decisions have enough validation behind them.

Longer term, I would love to help push Odysseus toward becoming a production-ready tool: scalable, maintainable, reliable, and safe to build on. For me, that means controlled and precise refactoring, improving the test suite, reducing confusing failure modes, and making the codebase easier to review and evolve over time.

For now though, I’m happy to help wherever the pressure is highest. The repo is moving fast, so I think the most useful work right now is keeping things clean and reviewable: narrow PRs, clean diffs, focused validation, clear CI signal, and extra care around security or owner-scope changes.

That is the direction I’m trying to support: helping the project stay organized, reliable, and easier for everyone to contribute to, while keeping the bigger decisions explicit and aligned with Felix’s vision.

Best regards,
Alexandre.

[tronbonjovi]

this man has worked in a kitchen!!

[BarsatZulkarnine]

At work we have pretty strict rules around this stuff, PRs do one thing, CI has to pass, nothing merges without multiple reviewers signing off. So coming at this from that angle.

The platform question is secondary for me. What I keep noticing is AI agents scanning the codebase, opening issues they found themselves, then immediately raising a PR against it. Nobody ran the app, nobody hit an actual problem. Issues should come from people actually using the thing, real bugs, real feature requests. That's what's worth acting on, and right now it's hard to find.

I think as maintainers/contributors we should wait and see what Felix wants to do with the project before making any big structural decisions. It's his call.

What we can do in the meantime is raise the standard a bit. Not to shut people out, valid contributions are always welcome, just make it harder to contribute for the sake of it. Like we can enforce minimum 2 human reviewer approvals before anything merges, no exceptions. I think there are multiple threads regarding CI.

Also worth doing is consolidating the backlog. There are a lot of issues that are really just discussion threads in disguise, questions, ideas, back and forth conversations. Those should be moved to Discussions and closed as issues. It would make the actual issue tracker a lot more useful and easier to triage.

Having been through the early chaotic stages of startups and now working at a large company, the difference is usually just whether the basics were locked in before things got out of hand. Nothing drastic, just enough to keep things manageable while we wait for Felix to share where he wants to take this.

[lawmight]

I will follow thread closely, I was looking for guidance and indeed some kind or coordination, I wanted some confirmation for my PR (bring cursor sdk as a model provider), but I guess I will just shoot my shot and wait for 2 thing, official coordination and my pr being merged or refuted

[lawmight]

I got cautious and built a proof system, the sdk implementation was straightforward, the agent mode and others were a bit trickier but everything seems there, but well.. i'm still polishing, will do pr video and write by hand the pr message because why not!

To answer your message... your totally right haha.. tho I know some people at cursor (me included), who could be really hyped about this project! either it is accepted or not (I mean, it's just a line more into the provider), I will maintain my pr so if people want to have it, they can just download it!

[CoolJohn-lab]

That's the right approach. And if it gets rejected just make your own fork and add it anyway 😉

[RaresKeY]

I took a quick look at your Cursor fork work and I think it ties directly into #2739.

Cursor is not just another OpenAI-compatible endpoint. It has its own shape: cursor://local, Cursor SDK bridge, /v1/models, SDK event streams, Agent mode, tool events, workspace config, and optional MCP bridge. That is exactly the kind of provider shape I am trying to normalize cleanly.

My main concern in #2739 is separating model identity, capability evidence, provider/endpoint capability, and vendor response shape so we do not end up with Cursor-specific logic scattered everywhere.

I am not trying to pre-empt your branch. I think your Cursor work is a good real provider case to prove the shape. If you are up for it, you can open a PR against my #2739 branch, or I can add you to my fork/PR branch for coordination. Nothing official upstream, just a way to line up Cursor with the capability/provider mapping work.

I’d keep it scoped to provider/capability shape first, then Cursor-specific integration can stay focused and easier to review.

[lawmight]

hey @RaresKeY haha no worries! I was checking if someone was implemeting that, since I had so no one, (surely missed your pr), I started building it from scratch, man like you can take it haha, if you somehow manage to normalize it, it's only beneficial for everyone! do tell me what you need from me

[RaresKeY]

hey @RaresKeY haha no worries! I was checking if someone was implemeting that, since I had so no one, (surely missed your pr), I started building it from scratch, man like you can take it haha, if you somehow manage to normalize it, it's only beneficial for everyone! do tell me what you need from me

Hey @lawmight, thanks for being open to this.

I think the best next step is a small PR against my #2739 branch, scoped to Cursor provider/capability shape only.

Base:
RaresKeY/odysseus:feature/model-capability-schema

Direct push would require write access to my fork, and I’d rather keep this first schema PR reviewable and scoped.

What would be useful for #2739:

• a scoped Cursor provider/capability reader/file
• cursor provider identity
• cursor://local endpoint shape
• Cursor /v1/models shape, including {id, displayName}
• provider config shape like SDK bridge / workspace cwd
• capability/control evidence from Cursor SDK behavior
• any general schema additions/corrections needed for Cursor
• stable identity note: don’t key only by URL, because cursor://local can mean different endpoint rows, keys, owners, and workspaces

The full Cursor SDK adapter, UI wiring, Agent mode, MCP bridge, etc. can stay for follow-up PRs. For #2739 I want the first clean mapping slice:

vendor-specific shape -> general normalized evidence -> canonical capability/control metadata

This is also the evidence layer that #3031 can later consume for reasoning/thinking runtime controls.

I also have local notes on the #2737/#2739 shape and can turn the relevant parts into a public issue/PR note if useful.

P.S. Also fine if you prefer me to extract the scoped shape pieces from your branch and credit you. I mainly want to avoid pulling the full runtime integration into #2739.

[vdmkenny]

I agree, we're really running around like chickens at the moment.
I've been going best-effort by doing triage, consolidating issues, merging in what I think is good quality code and a useful contribution.
Really, we need more of a roadmap, and some enforcement rules, like needing 2 collaborator reviews on a PR to merge.

I'd be happy to connect with some of you and of course Felix to work on this a bit more structured.

[Michiel-VandeVelde]

we should just start a chat somewhere, doesn't really matter where i guess, just where we can coordinate more thoroughly

[vdmkenny]

we should just start a chat somewhere, doesn't really matter where i guess, just where we can coordinate more thoroughly

Yes! I don't use discord and am not a fan of that platform (as are others I see), but I'm open to connect wherever mostly.

[alteixeira20]

What do you all think about using a pinned GitHub Discussion as a lightweight coordination hub?

Not to replace issues or PRs, but to make the current direction easier to follow. The pinned discussion could act as an index/roadmap, while the actual implementation details stay in focused issues and PRs.

For example:

• Current priorities — what needs attention now.
• Active roadmap trackers — links to parent issues like prompt/context work, CI/review-signal work, test-suite cleanup, etc.
• Review process — what ready for review, needs work, needs-validation, blocked, and stale pr mean.
• PR expectations — clean diff, focused scope, validation output, screenshots for UI, security/owner-scope care.
• Coordination notes — who is looking at what, where help is needed, and which proposals are waiting for Felix/maintainer direction.
• Security-sensitive work — reminder to keep serious vulnerability details out of public threads and use the proper private flow.

Then each roadmap item can link to a proper issue with the deeper technical detail. Something like #2750 is a good example of the shape I mean: a parent roadmap/tracking issue, split into small follow-up PRs instead of one giant implementation.

This would keep GitHub as the source of truth, avoid scattering decisions across random comments, and give contributors a clearer place to check before opening duplicate issues or PRs.

Of course, this should only become “official” if @pewdiepie-archdaemon and the active maintainers are happy with that structure. But I think it could be a low-friction first step while everyone figures out the longer-term coordination model.

[vdmkenny]

I think github discussions are a bit clunky, I keep forgetting this feature exists. It's a good first try, though.

[alteixeira20]

Yeah, I agree it is particularly clunky. I was thinking of it more as the bare minimum source-of-truth/index: pinned, visible, and mostly just linking to the proper issues/roadmaps/PRs so people can navigate without hunting through random threads.

Would others find that useful as a first step, or do you think a different format would work better?

[RaresKeY]

This is very close to what I am trying to implement with #2538

[RaresKeY]

I agree with the direction here. The repo feels like it needs a short step back to organize the scaffolding around the work, not just keep chasing individual bugs. The official direction should still come from Felix and the trusted core maintainer group; I am not trying to decide the coordination model from one PR.

What I can offer is one supporting layer for that: clearer PR intent, compact specs for people making PRs, and a structured agent-assisted pre-review flow.

That is where #2538 fits for me. The specs are meant to be a compact implementation-truth map for people writing code changes. If a subsystem rule can be explained in two precise sentences with links to the related files, contributors should not have to chase forty scattered files just to understand how the system currently works. Reviewers benefit for the same reason: the intent and current behavior are easier to check, and it becomes clearer what actually needs deduping, scaffolding cleanup, or framework-level work.

I also think meaningful PR bodies should move a bit closer to mini-ADRs. Not huge formal docs, just enough to say what contract is changing, why this shape was chosen, what tradeoff is being made, and what future contributors should not accidentally undo. PRs would capture intent; specs would map the current system for the next person making a change.

The other piece I am working on is a parallel code review flow for agent-assisted review. The idea is not to let agents approve or merge anything. The idea is a coordinator-led pre-review where agents catch easy issues before maintainers spend human review time on the PR.

The shape is:

• coordinator sweep first: specs, PR body, changed files, diff, checks, review state, base/head;
• review ledger for scope, evidence, validation, CI classification, and what was or was not checked;
• read-only parallel lanes only when the PR is broad enough: correctness, security/trust boundaries, architecture/contracts, tests, docs/spec alignment, CI, visual QA;
• coordinator verifies and dedupes findings into one final review draft for humans to approve before anything is posted.

I used a similar flow in a previous private project with around 30 contributors who were new to coding and using AI agents. The biggest problems were weaker models and not enough human supervision, which produced a lot of plausible output that still needed cleanup. So I think agent-assisted contributions should use capable models where available, for example GPT-5.5 on high/x-high effort, and still have clear human supervision.

In short: I think I can help with the implementation-truth/specs layer and the agent pre-review flow. The goal is higher-quality PRs and more focused maintainer review, not replacing maintainer judgment.

[RaresKeY]

Quick follow-up on the agent-assisted review idea I mentioned above.

I’m experimenting with a Codex-specific review skill for Odysseus. It can do dry-run PR range sweeps in chunks of up to 12 parallel subagent checks, surface only high/critical findings for possible posting, and also produce compact review reports for human reviewers before they spend time on a PR.

I tested it on range #2991-#3006. It flagged #2994 and #2995 for posting; I posted those manually after approval, and the findings looked useful.

Open question: should this even be a thing here? If yes, I’d like help shaping the rules, especially what should be posted automatically vs. what should stay as reviewer-only notes.

[AlanMet]

I'm not a fan of discord either for a project like this considering the goal. I'd personally prefer an open source alternative which would give more flexibility.

Additionally if Felix were to join the discord he'd immediately get spammed which is not the point. At the same time though I'm not a big fan of GitHub discussions either for this sort of thing though this has been alright as a substitute for the moment.

overall though I think I just want a clear way to see where things are headed, organized and how I can contribute effectively.

[RaresKeY]

I think using Linear to coordinate would help, but for open discussion I also don't like Discord, but something similar could be useful

[undergroundrap]

I’ve been looking into alternatives to Discord that fit the privacy and open-source goals of Odysseus, and I think Element/Matrix (https://github.com/element-hq/element-web) might actually be the exact solution we’re looking for.

Instead of a public Discord (which, as pointed out, is a data broker and a recipe for Felix to get instantly spammed), Felix could host a private Matrix homeserver. By turning off public registration in the configuration, he can completely control who gets in. It keeps a dedicated, quiet "kitchen" strictly for the core maintainers to coordinate, while GitHub stays the public source of truth.

If we went this route, there are a few practical edge cases and implementation details worth flagging:

• Hosting Overhead vs. Low Maintenance: Felix wouldn't necessarily have to manage bare-metal infrastructure. He could use Element Cloud (EMS) to spin up a managed homeserver in a few clicks, or run an incredibly lightweight implementation like Conduit (written in Rust) on a cheap VPS.
• The "Bus Factor" & Server Admin: If Felix is the sole owner of the homeserver and goes AFK, onboarding new maintainers or updating config files could stall. He would likely want to appoint one or two trusted core maintainers as server co-admins to help handle account provisioning.
• Notification Reliability: Mobile push notifications (especially for iOS) can sometimes be tricky on entirely custom/self-hosted setups. Relying on the standard Element apps (which leverage their default push gateways) or keeping desktop/web clients active would be key to ensuring critical coordination isn't missed.
• Bridges & Public Logs: If the team ever wants to bridge a channel to IRC or log discussions publicly for transparency down the line, Matrix handles that natively, whereas Discord forces you to jump through hoops.

Curious what everyone thinks, but it seems like a highly sovereign way to solve the coordination problem without compromising on the project's philosophy.

[undergroundrap]

To keep things low-risk, we could start with a free/cheap EMS instance just for the 4-5 core maintainers currently doing triage here. If it successfully clears the noise and helps structure the roadmap, we can worry about long-term hosting later.

[RaresKeY]

Another coordination idea: I opened #3051 for a PR-level related-work coordinator bot.

Idea is simple: when a PR opens/updates/merges, surface likely related issues/PRs in one advisory comment so contributors can quickly see “should we coordinate here?” or “is there shared scaffolding/framework needed?”

Ideally it would also update older PR comments when a newer PR becomes related, so the signal works both ways without comment spam.

Not meant as review/blocking/duplicate enforcement, just coordination hints where people already are looking.

[RaresKeY]

Small follow-up now that I’ve tested the structured pre-review shape on a few PRs.

I think this can help maintainers by turning broad PRs into a smaller set of verified, actionable findings before a maintainer has to spend time on the whole diff.

The newer shape I’m trying to use is:

• identify the concrete risk;
• explain why it matters to users, maintainers, or future contributors;
• point to the file/location;
• make a narrow ask;
• say what was validated and what was not;
• avoid posting unverified agent output as if it were final judgment.

Recent examples:

• [codex] Parse command-style web tool calls #2448: parser review caught malformed tool-call text crashing agent parsing, and non-tool prose being stripped from assistant output.
  [codex] Parse command-style web tool calls #2448 (comment)

• feat: WebSocket push notifications (replaces 30s HTTP poll) #2460: WebSocket auth review caught the route checking the wrong session cookie, meaning normal logged-in browser users would hit the close path instead of the new push path.
  feat: WebSocket push notifications (replaces 30s HTTP poll) #2460 (comment)

• fix: odysseus-research --status complete never matches (writer stores done) #1931: CLI compatibility review caught that the PR would drop the existing --status complete user-facing alias even though current dev already maps it to stored done.
  fix: odysseus-research --status complete never matches (writer stores done) #1931 (comment)

• docs: add agent migration manifest helper #3028: review found a lower-priority metadata scan issue, then a deeper symlink/security issue in the migration manifest helper, and followed up with approval after the fixes landed.
  Finding: docs: add agent migration manifest helper #3028 (review)
  Follow-up approval: docs: add agent migration manifest helper #3028 (review)

That last one is important to me: this should not just be “automation posts comments.” The useful version is coordinator-led review. Automation can help gather evidence and inspect broad diffs, but a human still verifies the finding, dedupes it, decides whether it is actually worth posting, and follows through when the author fixes it.

Older examples in a less standardized shape are #2588, #2579, #2994, and #2995. Those were useful too, but the newer shape above is closer to what I think would scale: clear findings, explicit validation, and a narrow maintainer-actionable ask.

[alteixeira20]

I think there are a few useful ideas converging here, and they might be easier to move forward if we split them into small pieces instead of trying to solve the whole coordination model at once.

A practical first step could be a small linked issue or pinned checklist for the basics:

• where coordination should happen;
• where roadmap/current-priority links live;
• what the review labels mean;
• what a good PR should include;
• what kinds of changes need extra review or validation;
• how to flag related/overlapping PRs before people duplicate work;
• how to keep security-sensitive details out of public threads.

Then the more advanced ideas can build on top of that: specs, related-work hints, agent-assisted pre-review, CI summaries, etc.

I can help draft that baseline if people think it would be useful. I’d keep it small, editable, and focused on making contribution/review flow clearer, not turning it into a full governance document.

[RaresKeY]

Agreed. A coordinating issue for the broader contribution/review workflow would give us a stable place to track the meta-work without turning this discussion into the whole roadmap.

Then each concrete piece can live in its own focused issue: review-label semantics, PR expectations, related-work hints, security-sensitive reporting, specs/pre-review flow, CI summaries, etc. The coordinating issue can link those child issues and keep status/current owner visible, while each person contributes the part they have researched most deeply and refines it with feedback.

That seems like a practical shape: one lightweight hub for work coordination around the project itself, with detailed issues for each part instead of one giant governance thread.

[RaresKeY]

Here is a concrete issue/PR pair for the detailed review template:

• Issue: Add a pull request review template #3126
• PR: docs: add pull request review template #3128
• Template path: .github/pull_request_review_template.md

For now, I think this is the simplest shape for a PR review template. Specs, code-review skills, automation, and broader coordination can stay as separate concerns.

I’m open to @alteixeira20 creating the coordinating issue and linking this under it. I’m also open to feedback and changes on the PR review template itself.

[sacb0y]

IMO the biggest issue I see here is contributions are broad.

It's disappointing to me that something so well structured like this #2893

Might be rejected cause there's no single person to maintain it's area, and the one person handling ALL of this at one time is focused on other areas like general bugs.

And then a litany of bugs related mostly to one feature area can spend days unaddressed cause no one with authority cares about that right now. Making the fixes and PR's feel kinda pointless as they sit for days while other things newer seemingly get pushed through quickly.

Thats not to say people can't reach over and submit a PR outside their purview, or that other things aren't justified as priority. But it needs to be one person's job to say "I handle issues related to documents: this issue has already been addressed/This looks good/This doesn't fit our goals". And refer to @pewdiepie-archdaemon for general guidance otherwise.

This would also reduce the repetition and redundancy you can see everywhere where multiple people tackle the same issue multiple times. One person looking at these similar issues could more quickly point out the duplicates hopefully before someone does a lot of work and gets frustrated.

[elpideus]

I found this project, loved the idea, and wanted to jump in and contribute some code. That's it. But right now I can't figure out what's actually approved to work on, and I don't want to repeat what happened to #987, #1013, and #1023, nor do I wanna add more patches to a broken ship.

I'll also say I'd want to contribute toward something going in a solid direction. What @PovilasKirna laid out in #605 is pretty much what any serious project ends up adopting anyway, for good reasons. A standardized stack doesn't just make the codebase cleaner, it makes adding features and fixing bugs extremely easier down the line, and a big chunk of PR verification could be automated because you're working with known, well-supported tooling rather than a mess of custom patchworks.

I don't have strong feelings about the coordination platform, that's out of my skillset range.

TL;DR: What would actually help me and others like me is a clear signal somewhere on what's greenlit to implement. Even a pinned post saying "these things are approved, these aren't" would be enough to get started.

[RaresKeY]

@elpideus I think everyone is circling the same core question: how do contributors know what is actually safe/useful to work on without adding more churn?

My current answer is: we should organize what already exists before greenlighting broad new implementation work.

I’d start with #3163. It is not an official “approved roadmap,” but it is meant to be a practical intake lane for Stabilization v1: security/trust boundaries, CI/test reliability, runtime/platform bugs, review/process cleanup, duplicate reduction, and small validated fixes. Those are the areas most likely to help the project right now without depending on a large architecture decision first.

For the bigger direction in #605, I agree there are serious ideas there, but I’d be careful treating that as implementation-approved until maintainers explicitly accept a plan. In the meantime, a curated stabilization bucket gives people a clearer place to contribute without guessing.

[CoolJohn-lab]

I would say keep the enthusiasm but chill at the moment. There are still hundreds of pull requests to go through, and the focus is on getting a stable base to work from right now and fixing errors in the existing design.

There is a big appetite to change the overall design and make it better and those bigger scope PRs that you see were rejected are a sign that we aren't ready to consider that sort of redesign only a week after public release.

The focus at the moment is getting some sort of consistency to issues and PRs, and keeping changes to minimum scope. Again, it is one week since this project launched, so just curb your enthusiasm a teeny, tiny smidgen.

[sacb0y]

@RaresKeY Well when someone sets up the tools to organize i'll gladly help.

[sacb0y]

Which I hope happens soon as the issues and PR's keep growing XD

[WGlynn]

One thing the platform-debate framing tends to bury: the coordination substrate is a different question from the coordination channel. Discord vs IRC vs Matrix changes where conversation lives, but doesn't change the mechanism by which contribution-impact gets recognized or distributed.

For a fast-growing repo with scaling-contributor strain, the deeper question is whether coordination is mechanically-surfaced (the substrate makes it visible who's load-bearing without anyone having to decide) or politically-allocated (a human or group decides who gets review-priority, decision-authority, milestone-influence). Most platform choices collapse to the latter eventually. The former is harder to build but scales without burnout.

A concrete starting move: a lightweight contribution-impact log surfaced in the repo itself, alongside ACKNOWLEDGMENTS.md but at the runtime/work layer rather than the codebase layer. Track who's reviewed what, who's followed up on what, who's unblocked whom. Make it visible mechanically. That alone gives Felix the delegation-shape question some structural answer instead of having to allocate trust by intuition.

Started a separate Discussion (#3178) on the more formal version of this. Attribution graphs over the persistent-skills system using Shapley decomposition. The thinking generalizes from skills-evolution to contributor-coordination naturally: same DAG shape, different value-function. Probably overkill for what this thread is asking, but worth noting the substrate question keeps reappearing in different forms across the repo's discussions.

On the immediate platform-pick question: the security-disclosure point at the end of the original post is actually the most binding constraint. Whatever channel gets picked needs an out-of-band private-disclosure path for serious vulnerabilities. That probably rules out fully-public-only forums. Matrix or any platform with a clean public/private split handles both better than pure-public Discord, which also has the privacy concerns others raised.

[crazyjackel]

I am the author of #593 (Proposal: Code Owners). It is my view that a teams-like structure is necessary for coordination as people can't own the entire project and make sure that everything works; Not with >400 issues and >550 PRs in under a week. It is impossible to figure out who to contact to advance your PR or Issue to further stages, nor entertain specific agreements/ADRs (#1998) that have lasting influence. It is very difficult to even monitor all the related issue numbers to figure out what is duplicated or what conversations are worth having for the health of the project. It is particularly difficult if you decide to take a break for a bit.

I think that proper labelling of discussions, issues, and PRs around the idea of Teams, whether is Frontend, Backend, DevOps, Documentation, or AI/ML IT/Platform Ops, would go a long way. Just by triaging problems to one of the suggested teams and having specific maintainers be coordinated for that with CODE OWNERS providing the names or references to contact those people, makes it much easier to keep track of everything that is going on within a specific sub-universe.

These larger threads, discussions, and wide-scale issues can continue for the whole project--I have suggested adopting an ADR framework starting with an ADR on how to do ADRs--but first divide the work and let people know how you divide it. If it is a bad structure or the teams are poorly considered, that can be changed later, once things are stable.

[WGlynn]

The thread has converged on a real question that the platform debate was downstream of: how do contributors and Felix know who should own which area? @sacb0y's DRI-per-area, @crazyjackel's Code Owners + ADR framework (#593, #1998), @RaresKeY's Stabilization v1 (#3163), @alteixeira20's coordinating issue, and @NoodleLDS's volunteer for Projects all converge on this shape.

Worth naming: every one of these proposals shares an implicit assumption that Felix manually allocates the ownership. "Felix needs to assign DRIs." "Felix needs to approve the milestone." "Felix needs to greenlight what's worth working on." That puts the coordination load back on the person who started this thread by saying he wants to keep the project moving without owning every operational decision.

There's a mechanism-design alternative that composes with the existing proposals rather than replacing them: contribution-history in an area IS the DRI signal. Anyone who has demonstrably reviewed, fixed, or shipped in frontend/ over the last N weeks earns first-look review rights on frontend/ PRs. Mechanically allocated, no Felix-decision required for the routine case. Felix only steps in on tie-breaks, scope conflicts, or genuinely new areas without history yet.

Concretely it could look like:

• A CODEOWNERS file (per @crazyjackel [Proposal]: CODEOWNERS 🗳️ #593) gets generated from commit and review history on a rolling window
• Path-based mapping: who has touched frontend/, cookbook/, docs/, and the rest in the last N PRs
• Threshold for inclusion is low to start (any contribution above noise gets you flagged as area-aware) and tightens as the area gets crowded
• Github already provides CODEOWNERS as a first-class concept; the missing layer is the script that generates it from contribution history rather than from manual assignment

This composes with all existing proposals:

• @crazyjackel's Code Owners proposal becomes the artifact format
• @RaresKeY's Stabilization v1 (Stabilization v1: candidate intake #3163) becomes the curated milestone the mechanism populates
• @alteixeira20's coordinating issue/pinned checklist becomes the visible roadmap
• @sacb0y's DRI-per-area gets a structural answer to "who" instead of waiting for Felix to allocate
• The ADR framework (Feature: ADR Framework #1998) handles the larger directional questions where contribution-history alone isn't enough

It also solves the burnout-resentment cycle the manually-allocated model creates. Nobody can argue with "you have reviewed 40 PRs touching this subsystem in the last month, you have first-look rights here" the way they can argue with "Felix decided you should own this." It removes the politics from the routine case and reserves Felix's attention for the cases where politics actually need adjudication.

Worth flagging: this isn't blocking any of the existing proposals. They all still ship. This is the rule that populates CODEOWNERS automatically so it doesn't need Felix's decision on every line.

[vdmkenny]

There are definitely already some guidelines in place for basic first triage. Large PRs with multiple features are a no-no, I've also been closing a ton of duplicate issues by kids using AI but not understanding github, they're racing people on newly created issues to crap out a PR, sometimes leading to 3 ~identical PRs by different people. Today alone I might have close 20 duplicates like that.

Visual redesigns are no, as well. People adding a ton of extra CSS instead using what's there too.

[vdmkenny]

But yes, all of this needs to be formalized.

[sacb0y]

@vdmkenny or @alteixeira20 Mind taking a look at these? They've been sitting around for a few days and the combination of them makes testing other document related stuff difficult.

#2259
#2439
#2484
#2483

And while noodle did do the big project thing, the tagging feature is much smaller and also helps:
#2774

There was also this issue which I imagine might have been fixed by someone else by now cause the fix someone tried doesn't seem related to my issue.
#2179

On that CSS issue i've been meaning to make a feature request of a custom CSS box, thats how a lot of these projects get around visual nit picking.

[vdmkenny]

@sacb0y #2259, #2484, #2439 merged

[sacb0y]

Wahoo!

Time to pull dev...

[vdmkenny]

Just a small thing, can we refrain from using LLM for posting comments and discussions as much as possible, or at least instruct it to be very concise instead of being so chatty? It's honestly exhausting to read dozens of these daily.

[alteixeira20]

Agreed, it's perfectly fine to use it to describe technical and complex problems, but try to keep the language approachable and dense instead of over polished responses, and of course read it fully before actually posting, if you can't understand it you shouldn't probably post it!

[RaresKeY]

Agreed. For coordination threads especially, concise and human-edited should be the norm.

Structured formats still make sense for PR reviews/templates when they make findings easier to scan, but they should stay dense and to the point.

[undergroundrap]

We should consider establishing guidelines for LLM usage based on the complexity of the task. While experienced developers can successfully guide smaller models, contributors with less engineering background often rely heavily on lower-tier models for complex architecture changes, which tends to introduce a lot of code churn ("slop"). For high-impact or structural changes, we should require or strongly encourage the use of state-of-the-art models (like GPT-5.5 Extra High or Opus 4.8 High Effort) paired with thorough human validation.

[joebog1]

We should consider establishing guidelines for LLM usage based on the complexity of the task. While experienced developers can successfully guide smaller models, contributors with less engineering background often rely heavily on lower-tier models for complex architecture changes, which tends to introduce a lot of code churn ("slop"). For high-impact or structural changes, we should require or strongly encourage the use of state-of-the-art models (like GPT-5.5 Extra High or Opus 4.8 High Effort) paired with thorough human validation.

That sounds good but we should note that it's not something anyone can enforce. Since there can't be any oversight before a PR is made, junior devs are still going to push slop though at alarming rates. Even bigger models tend to use subpar architecture when given freedom in my experience.

That being said, a simple document that outlines how to not misuse an LLM could be beneficial to devs and those inexperienced with using AI for generating code. The rules should be simple and easy to understand and point the developer in the direction of understanding the task well before code is generated, as well as reviewing the code after to ensure it actually does what they asked for.

Some obvious rules to start with:

• Never copy an issue into an agent and expect it to solve it properly.
• If you don't understand the code generated (or the existing code), don't create a PR
• Understand the code, write a plan manually (with feedback from the agent if needed or an initial draft if you prefer) before writing any code.
• Once a plan is made, you can use the agent to execute it 1 step at a time, verify each step before continuing with a lot of scrutiny.
• Any tests generated, either before (TDD) or after code generation, must be manually checked by a human. A test ensures a specific behaviour occurs, unless a human checks it, it may ensure incorrect behaviour, or be oddly brittle.
• TDD with human written tests is encouraged but not required when generating code.

How does that sound? As I mentioned before, we can't stop malicious use of AI to flood PR's with poorly thought-out code, but for the inexperienced it's probably good for them to not be reliant on an LLM to code.

[pewdiepie-archdaemon]

Thanks everyone. Here is the direction from me for now.

1. Keep GitHub as the source of truth. PR-specific and issue-specific decisions should stay on the relevant PR/issue.

2. Let’s use a pinned GitHub Discussion as the lightweight coordination hub for maintainers/contributors: current priorities, roadmap trackers, review expectations, labels/process notes, and which proposals are waiting on my/maintainer direction.

3. I am open to a dedicated private maintainer coordination channel for trusted maintainers, but I do not want project decisions scattered across random chat. Anything important should be summarized back to GitHub.

4. Security reports should go through private disclosure first. Please do not post serious vulnerability details publicly until they have been triaged and we agree on disclosure timing.

5. I am going to slow down big/risky merges and keep large AI-generated PRs to a higher review bar. Smaller focused PRs with clear validation are the direction I want.

6. Operational triage help is welcome: duplicate cleanup, stale/conflict labels, focused review, CI signal, docs, and security-sensitive review. Bigger roadmap/product decisions should remain explicit and not happen accidentally through drive-by PRs.

[alteixeira20]

Thanks for the clear direction.

I created the Stabilization milestone as a small maintainer-curated bucket, with #3163 staying as the wider intake/candidate discussion. If you or the maintainers want it adjusted or removed, no problem.

I’ll treat it conservatively: only items with enough context to review properly, focused on test/CI signal, runtime reliability, degraded-state behavior, security/trust boundaries, and backlog hygiene. Anything broad or product-directional should stay in discussion or be deferred to you/maintainer direction.

I can also help draft the pinned coordination hub next if useful, keeping it lightweight and linking back to the relevant issues/PRs instead of duplicating decisions there.

[pewdiepie-archdaemon]

I want to add a bit more context from my side.

I’m not a developer (duh), and this is my first time coordinating anything GitHub-related at this scale, so it has been a lot to learn quickly.
I really appreciate that people are already helping and handling so much of the work!

At the start, we moved pretty aggressively to fix obvious bugs and issues. That was useful, but I think this is a good point to slow down.

From what I can tell, some things are being merged without enough testing, and in some cases without a clear reason for existing in the first place. The goal right now should be to harden and improve what Odysseus already has, not keep adding more features unless they are well thought out, cleanly integrated, and properly tested.

So my preference going forward is:

• prioritize security, stability, and review quality
• avoid large AI-generated PRs that are hard to reason about
• ask for clearer motivation before adding new UI/features
• test changes more carefully before merge
• keep experimental agent work separate until it is actually ready.

Hope that makes it more clear trying my best to keep up honestly lol.

[crazyjackel]

That is all reasonable. The goal of a lot of would-be contributors is to help get the project verifiably hardened such that adding features and fixes isn’t scary. By building up trust mechanisms, it becomes easy to sign off on good changes.

[vdmkenny]

Totally fair, and the right call. I think all of us were eager to get it working for our own usecases and workflows. (hence some features landing a bit prematurely).
I've been doing my best to quality-gate PRs, triaging, duplicate-hunting etc to try and keep the open PRs from spiralling fully out of control. While doing so, I've also discovered some duplicate code and other inconsistencies and handed those issues off to eager contributors, while following up their quality. Any direction is welcome, and we'll do our best to keep following your intentions for the project in good faith.

[vdmkenny]

self-merging wise, I think github has some rules that can be enabled so there needs to be an approval by a maintainer that's not the last committer on a PR before it can be merged. I think it would be a good idea to enable this, so we can get used to this way of working quickly.

[sacb0y]

@vdmkenny IMO the only way the properly sniff out duplicates is proper grouping. Whats there is simply too broad, and trying to hunt down key words doesn't really do the job.

There really needs to be better more specific grouping of Issues and PR's so duplicates are more easily found. Someone looking at the full picture may struggle to sniff out a duplicate, while someone looking at just "Email" can find things much easier.

There's already the "Area" selection when making an issue, why isn't that an actual label or something?

[RaresKeY]

Hey @pewdiepie-archdaemon, when you have time, could you take a look at my maintainer-help note from #551?
I posted it a few days ago and that thread has grown a lot, so I’m linking it once here for visibility:
#551 (comment)

The review/triage/security-sensitive work you described is where I think I can help most. Whatever the decision, I’ll keep contributing as a regular contributor too. I care about Odysseus because I also want a controllable, local-first AI agent hub.

[mahdi-salmanzade]

Thanks for kicking this off, Michiel — agree a single place for this helps.

Quick apology for going quiet for a bit — my GitHub account got randomly restricted for no real reason; I appealed and just got it back, so I'm caught up again.

On the "who owns what" angle: I've been working on the mobile side of Odysseus and would be glad to take that on as a dedicated area if the group's open to it. So far that's the companion bridge plus a native iOS/Android client (Expo SDK 56) that pairs to a server over the LAN and uses the existing chat/session API — local-first, nothing leaves the network. It runs natively on both iPhone and iPad from one universal build.

• App repo: https://github.com/mahdi-salmanzade/odysseus-mobile
• TestFlight: https://testflight.apple.com/join/qWq1A51n

The bridge work is already landing (mobile CSS fix #1612 merged; companion/mobile-route PRs #2585, #881, #1094, #2668 open against dev, owner-scoped + CI-green). If it's useful to the project, I'm happy to maintain mobile — keep it in step with Odysseus and handle the TestFlight / App Store release cadence — so it stays a one-tap install rather than a dev build. Happy to fit whatever review/coordination flow the maintainers settle on here.

[WGlynn]

GitHub as the source of truth works for me. One add that has saved me elsewhere: claim an issue with a quick comment before you start, and open one for anything past a small fix, so two people don't build the same thing.

[WGlynn]

For now GitHub is the right call, but longer term this probably has to live somewhere more decentralized, tamper-proof, and permissionless.

[RaresKeY]

Small follow-up on @pewdiepie-archdaemon's direction here.

I may be missing it, but I do not currently see a pinned general coordination Discussion for current priorities, roadmap trackers, review expectations, labels/process notes, and proposals waiting on maintainer direction. The pinned Discussions I see right now are #225 and #551. Please correct me if I am looking in the wrong place.

I also think the private maintainer channel part still matters. GitHub should stay the public source of truth, but sensitive concerns such as security reports, trust-boundary concerns, or contributor moderation probably need a private path before details are posted publicly.

While thinking through how to organize work with GitHub's existing surfaces, I split out one narrower issue-bucket workflow proposal here:

• Issue buckets: parent trackers, child issues, and PR candidates #4415

The shape came from looking at tracker issues like #2523 and expanding the idea: classify issues first, let parent/sub-tracker buckets emerge from the real issue queue, and treat linked PRs as candidate implementations instead of letting PRs own the problem.

The practical start would be classifying open issues without parent links. Valid issues attach under the smallest fitting tracker bucket, or create the missing bucket structure upward. Malformed, duplicate, unclear, or non-actionable issues route through issue cleanup before review time goes into linked PRs.

This is not meant to replace the broader pinned coordination hub. I see it as one organizing layer that could feed into it. I would appreciate maintainer/contributor opinions or corrections before trying to apply the shape more broadly.