Earlier quoted context omitted.
That is correct. The backend covers enterprise features that are only source-available, whereas the rest of the application is open source. We understand that this can be quite misleading, and will refrain from saying that we are open source in the future
I also suggest you add documentation to the github repo. The first thing I did after reading the first paragraph of this announcement was checking the source code. And when I saw no documentation at all - zero - nada - niente, I completely lost interest in looking more into the project (I was quite enthusiastic, given your description, so seeing no docs was an incredible turn-off).
Launch HN: Mintlify (YC W22) – Maintainable documentation for software teams
51–59 of 59 posts
Re: Launch HN: Mintlify (YC W22) – Maintainable documentation for software teams
#52Earlier quoted context omitted.
That is correct. The backend covers enterprise features that are only source-available, whereas the rest of the application is open source. We understand that this can be quite misleading, and will refrain from saying that we are open source in the future
I also suggest you add documentation to the github repo. The first thing I did after reading the first paragraph of this announcement was checking the source code. And when I saw no documentation at all - zero - nada - niente, I completely lost interest in looking more into the project (I was quite enthusiastic, given your description, so seeing no docs was an incredible turn-off).
Re: Launch HN: Mintlify (YC W22) – Maintainable documentation for software teams
#53Earlier quoted context omitted.
Totally agreed. While the frontend and core functions are open source, the backend under the `server` folder is source available. We made the mistake of referring to the entire repo as open source, which we will refrain from in the future.
I think source available is the future!
Re: Launch HN: Mintlify (YC W22) – Maintainable documentation for software teams
#54I think this is really just level 0 of what documentation is from everything I'm seeing. That sounds harsh! But what I mean additionally is that this is laying the necessary and important groundwork to increase the legitimacy of documentation efforts. Being a backbone/level 0 I would caution you to keep in mind incentives to try and avoid perverse incentives Right now there are close to 0 incentives to either create…
Your point about incentivizing is very interesting. We mainly interviewed teams that were in our batch AKA early stage startups/small teams that didn't have much of a divide between management and developers - definitely a mistake on our part and we should definitely go back to interviewing larger teams. We knew that documentation is hard to maintain as changes are made and that a feature can be shipped without docum…
For your answer on good documentation, that's a good general answer. As you say there are lots of layers to it. Some ideas just from my current viewpoint: - From my forays into foreign language learning I picked up the linguist's Stephen Krashen's research after learning about it from my language exchange partner. One of the main themes of his research is the idea of "Comprehensible Input"(CI). CI is the idea that you acquire knowledge via exposure to new language that is at a difficulty level where you understand most of what's being said. Then you acquire these new smaller pieces of knowledge via context. I would say this is most closely related to what you mean by structure of the documentation. Obviously with some overlap with the content itself. - There's also a stronger version of CI that adds an additional piece to this, the content must be of interest to the acquirer/learner. This property is I think the closest to what I think you mean in regards to content of documentation.
In my opinion reaching the first goal, Comprehensible Input, where knowledge is able to be acquired efficiently is step 1. Resources of this type can be created much more easily as there is less subjectivity about the content's style itself rather than simply the pacing of the concepts introduced. The second part is obviously the hard part :) Maybe style text style transfer will start to get really good without the possibility of it influencing the former?
[X] - Old video of Krashen explaining his central ideas https://www.youtube.com/watch?v=fnUc_W3xE1w
P.S. I specifically mentioned text style transfer because I noticed your team had an offer of bringing in trusted technical writers. What would be a very good deal for both you, doc writers(at the client side), doc consumers, and 3rd party writers is the ability for their style to be automatically transferred into anyone's technical writing. 3rd party writers can license their fingerprinted style, Client side writers get a neat assist on quickly changing their writing style, and readers get a choice of voice they identify with.
Re: Launch HN: Mintlify (YC W22) – Maintainable documentation for software teams
#55"I looked further at the documentation solution I mentioned looked interesting. It is very nifty but it is pure SaaS, and I don't care how secure they are, having our source flow through another SaaS is not something I'm going to take on for any amount of pixy dust."
Re: Launch HN: Mintlify (YC W22) – Maintainable documentation for software teams
#56We have a highly regulated environment and supply chain and have to go through a whole lot of GRC on a regular basis, and additionally one-off audits from some customers before they'll feel ok using our solution. So I will share here what I said to my folks: "I looked further at the documentation solution I mentioned looked interesting. It is very nifty but it is pure SaaS, and I don't care how secure they are, havin…
Re: Launch HN: Mintlify (YC W22) – Maintainable documentation for software teams
#57Isn't the underlying problem that developers hate writing documentation for some reason? They will spend months writing some crazy audio framework in C++ but refuse to spend even a day writing a tutorial on how to install it.
Yeah. We started this whole endeavor because we, as developers, also hated writing documentation. We thought that if we made it easier - whether it's by automating it through AI or by bringing the documentation closer to the code - it would reduce the friction. We definitely think more can be done here to incentivize developers to update documentation.
Re: Launch HN: Mintlify (YC W22) – Maintainable documentation for software teams
#58Earlier quoted context omitted.
Fair enough (the words "notifies everyone" probably should be chanaged.) But that's not really the point - it's that I don't get what they are doing that beats me coding something in an afternoon. (Inam trying really hard not to do the famous Dropbox comment) But afaik the main feature here is you can add a piece of metadata in a comment that says "if this module is chnaged in a release branch, then some other docume…
Thank you, we really appreciate your feedback. We're both technical founders and we're very aware that we need to work on making the language clearer. Your feedback makes it crystal clear that we really need to work on this. Appreciate it.
Re: Launch HN: Mintlify (YC W22) – Maintainable documentation for software teams
#59Earlier quoted context omitted.
I also suggest you add documentation to the github repo. The first thing I did after reading the first paragraph of this announcement was checking the source code. And when I saw no documentation at all - zero - nada - niente, I completely lost interest in looking more into the project (I was quite enthusiastic, given your description, so seeing no docs was an incredible turn-off).
That's an incredibly good piece of feedback. Working on it now