peter_l_downs

Separately, there seems to be a ton of unused or broken or dead code sprinkled throughout — for instance, in the auth code, I can't tell if you're doing basic email/password auth or using Supertokens and a third-party login via Google. You have code for both and some routes seem dead or missing.

https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...

Also, I mentioned the lack of documentation for how to run Tegon locally because your docs are entirely insufficient. The main docs page is just a README template. https://github.com/tegonhq/tegon/tree/main/docs

The quickstart guide has a broken link to instructions on how to self-host https://github.com/tegonhq/tegon/blob/main/docs/quickstart.m...

The oss/local-setup guide is entirely empty https://github.com/tegonhq/tegon/blob/main/docs/oss/local-se...

The oss/deploy-tegon guide does not explain anything and the script it references seems out of date https://github.com/tegonhq/tegon/blob/main/docs/oss/deploy-t...

I'm done looking at this project. I strongly recommend hiring the best engineer you can find as quickly as you can.

Comment · 2 years ago

First, congratulations on launching. I think people are so used to seeing beautiful products these days that it can be hard to remember how hard it is to make anything. Nice work! With that out of the way, here is some critical feedback:

- What is the pitch that you made to YC that convinced them to back you? The market size just doesn't seem that large and I don't understand what will differentiate you from Linear (whose design language you seem to have ripped off, somewhat poorly.) This post and the current featureset is vague and does not seem like a significant improvement. What is the core problem you're solving and why is that valuable? Your launch post above describes a lot of "how" but not a lot of "why".

- Why are you bothering to pretend to be "open source"? You're backed by YC and you'll make money selling access to the product on your "Tegon Cloud". If you're really going to be open-source, you need to make some significant improvements before anyone would consider contributing. Some documentation on how to self-host would be a good start. Look at all the environment variables in this dockerfile — which ones are necessary to run this service myself? https://github.com/tegonhq/tegon/blob/main/docker-compose.ya...

- If you're going to be "open source", the quality of your codebase and engineering skills is going to be a deciding factor in whether or not you get outside contributors. Consider writing actual descriptions in your pull requests, describing what you've done and why. Here's a PR picked at random — this is bad engineering work and does not encourage others to contribute. https://github.com/tegonhq/tegon/pull/114

My advice is that you drop the facade of being "open source", hire a designer, and do some actual user research to figure out where people are actually struggling with their ticketing systems. The features you're building (automatic title suggestion, thread summarization, and "find similar tickets") do not solve the problems that I have had with ticketing systems. They're small, potentially nice-to-have features that absolutely do not help me understand the core question for all engineering teams: who is doing what, how will they do it, why, and when will it be done.

Comment · 2 years ago

Extremely anodyne — given that the author has maintained FreeDOS for longer than I've been alive, I was hoping for slightly more interesting ideas than "have a website and be nice to people." Not that I disagree with his advice!

Comment · 2 years ago

Looks totally fine at first glance. I'm happily using https://github.com/gorilla/sessions to handle cookies right now — OP, is there any reason I should want to switch to your library instead?

Comment · 2 years ago

Makes sense, thanks for answering.

Aside — the architecture diagrams on https://xeiaso.net/blog/xesite-v4/ are not displaying in-browser for me, but do transfer correctly and are viewable on my computer. Maybe another mime issue, as the network inspector shows them being transferred with type "octet-stream"?

Repro by visiting the URL in latest Firefox, Safari, or Chrome.

Comment · 2 years ago

Maybe I missed it, but why are you embedding a zipfile of gzip streams rather than just embedding the static site's files with an `embed.FS` and serving from that?

Comment · 2 years ago

What are the downsides of enforcing squash-merge to main?

Comment · 2 years ago

I think a lot of new entrants to previously-well-explored spaces tend to label themselves as "modern" in order to signify that there is something new about their approach.

For instance, I have a migrations library that I descibre as "modern" because it is designed for a continuous deployment environment where you're automatically running migrations on container startup — there are tons of existing popular migrations libraries, but none of them work this way because they were written in the era that you'd manually run sql commands in prod. I say "modern" so that if anyone finds my library, they realize that it was created recently based on more recent dev/ops trends.

Maybe I should drop the "modern"? I do see a lot of people describe their code as "minimal" or "clean", which is pretty meaningless to me, so I get that "modern" could come across that way as well.

Comment · 2 years ago

Maybe. Frankly this is a very impressive outcome that is attributable both to the Father's business and management practices, as well as the Son's business and management practices. No matter how good you are at running a web business, if you inherit a totally fucked business with poor practices, very unlikely you could engineer this outcome.

My condolences to the OP and I was happy to read such a well-written article describing a fantastic outcome for his father's company.

Comment · 2 years ago

Enforce squash merging to main and move on with your life. Linear history on main, individual contributors can rebase and merge or format-patch or do whatever they want on their PR branches and it doesn’t matter. There are zero downsides to this approach.

Comment · 2 years ago

One more thing you could do is put the real name of any human being with any track record of professionalism, anywhere on the website. Currently you're:

- commenting under a pseudonymous profile

- asking for emails by saying "please email me. contact at cyberscarecrow.com"

- describing yourself in your FAQ entry for "Who are you?" by writing "We are cyber security researchers, living in the UK. We built cyber scarecrow to run on our own computers and decided to share it for others to use it too."

I frequently use pseudonymous profiles for various things but they are NOT a good way to establish trust.