Well reading this conversation. I'll just say. You are all incredible engineers and you all act and sound just like engineers lol. The subject changes. The people never do.
"Presumably we're all here because we think reticulum is a good idea and want to see it flourish. " - the best of us . . . who is not yet burnt out
Let's all work towards a pattern of eventual consistency. It never eventually gets there but it can get close and the quality and value of the result is purely dependent on the process. We all do our best to build on what those have built before us. Instead of pointing out the things that bother you and pointing them out as the failure of others try and ask what you can do to fix that problem. Large development teams are chaos and anyone who has built tooling for other teams can tell you just how hard and important it is to guide them towards intent. Abstract interface/contracts, strict custom linting, git hooks, class abstractions, packaging, documentation, and governance are things that really are only learned through anagorisis experiences for developers. It is also the type of epiphany I fear we lose in this AI world when we need it most.
@Zenith is right, but I also think they are framing the problem wrong. Guiding collaboration to an intended model is an art in itself. Leadership on clear communication are as important to these sorts of large projects as the code itself. There are no perfect system and no development team I have ever worked on contains a naturally unified view on open questions in development, instead you get a natural result of a process and that process decides the quality of the answers. It sounds to me like some action towards building tooling that assists in distributing work towards the project's true needs and guiding principles on how to best to broach these problems when they occur would be so valuable.
"This looks like it was a lot of work, but I fear it lacks validation and may be a duplicate of another project, perhaps you can help them test their solution and suggest changes"
"This project doesn't meet our minimum standards but here is where you can find tooling to improve on that"
"At the moment we are inundated with unverifiable code that is difficult to review and stands outside our more common packages, please run these validation steps and respond here"
"Our automated system has evaluated the codebase and prioritized review based on adherence to these basic principles. If you would like to raise visibility of your project you must meet the following standards"
Perhaps someone here could make this their next contribution.
I will tell you my fear and I have a regional concern, and a vision for this system that likely does not fit the framing for everyone here. This system needs adoption to fulfill that vision and would be defeated through several vectors of attack. One is the very thing @zenith is concerned about poor code quality creating security concerns in the codebase or worse malicious vulnerabilities introduced. But what I think companies and governments would do to kill this is not that at least not as a first attack. They will paint it as a channel for criminals and only criminals. They will target maintainers. They will regulate its channels through captured regulatory bodies restricting ism band utilization. They will criminalize manufacture. This system is a threat to the status quo and will in turn as it is already inevitably growing due to various global concerns become mainstream across the anglophone world. That puts this project on a clock in my opinion. It must achieve mainstream adoption prior to that inevitable escalation of force due to commercial conflict. That's why I've been building out the tooling I presented in the showcase, and I released it all at once. Sudden capabilities. (and if my analytics are accurate wow ya'll got real interested in rns-shop not worried about that at all lol). My point is that in my singular opinion we need to channel the interest this project has garnered into providing accelerated development of the system itself.