In reply to @samantazfox:pussthecat.org
After that, it's a game of trying and guessing, until we find the right one. Maybe it's a debug parameter left here by Google employees? Who know. But all in all, that small number is currently the password to bypass other complicated client checks.

In reply to @samantazfox:pussthecat.org
TheFrenchGhosty It's not acceptable either, imho. If one day we move to stable releases, each release should be stable, as the name implies. Now that's kinda the same way with the merge batches I do. If you take the latest commit on master, it should always be stable.

Samantaz Fox I love what you're doing with Invidious, and I appreciate you as person, just like everyone else in the room. My perception as an outsider is that the development process on Invidious feels like a 32 core CPU running a single threaded process. One Samantaz to hold the fort. But it does not have to be this way. I think your efforts would be more valuable if you were to figure out how to orchestrate and lead the other cores of the CPU, instead of trying to do all the work yourself. I know this is easier said than done, but I believe your time can bring even more value that way.
Also from the perspective of an outsider, my ask of the core team would be

1. What problems do you want to solve next for Invidious? Is it velocity issue, as in making Invidious evolve faster? Is it a stability issue, as in Invidious breaks too often? Is it an organization issue? You need to decide what you want to solve for.
2. Quality is obviously of upmost importance to Invidious, but are you able to articulate what that means? Quality can be many things:
   • Quality is whatever devs deem "good" by just looking at code a "feel" it is good
   • Quality is when there are no major incidents ever happening on public instances, or reducing the number of incidents overall
   • Quality is reducing the average time to resolve an incident
   • Quality is when bug issues are fixed and closed on a timely manner
   • Quality is when there's good testing coverage that gives devs confidence in making changes without breaking things
   • Quality is when users complain the least, and are happy with using the software
     Quality can mean so many things, and unless you can define it, you can't measure it. And if you can't measure it, you can't tell if you're doing a good job.
3. Where do you want the community to help?
   Do you want more volunteers testing PRs ready for testing? Do you want more people validating issues and reproduction steps, and closing non-issues so you can focus on important stuff? There's man power, and you need to decide how to use it. Start by creating a CONTRIBUTING.md file where you articulate how to effectively contribute in the areas where you need the help. Start writing down a vision (after answering 1.) so that people can push with you towards where you want Invidious to be. I don't have examples in mind of what a good CONTRIBUTING.md looks like, but even saying what you want (and what you don't want) from contributors would be an improvement.

Finally, I think the conversation was somehow implying that we need to compromise on quality to move faster. This is absolutely not true, and there's a world where both velocity and quality (as we define it) improve simultaneously with a set of disciplines and processes, and building a community who cares about your standards of quality as you define it.

I apologize if I'm making all of these long messages, I hope I'm not intruding too much.