IIRC they were random letters that do not occur naturally in English words, in order to serve as easily searchable annotation/footnote identifiers. He somewhat already knew they were extra details that would not make it to the main body. Later these get changed [1], [2], etc but you don't want to use these at the outset due to possible reordering/deleting.
Source: I was one of the founders of Stypi and we asked him when porting the data from Etherpad to Stypi.
In a lot of situations, no additional time is spent (and thus wasted). This happens with advisors in the general case too: they become an advisor and never meet again.
At Slab (https://slab.com), we believe that knowledge is the foundation of any organization's success. When a team's collective knowledge is more accessible, that team's potential is limitless.
Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Each day, thousands of customers rely on Slab across their entire workforces, including Asana, Benchling, and Fivetran.
You'd be joining a team of thoughtful and experienced engineers, distributed worldwide across North America, Europe, and Asia.
At Slab (https://slab.com), we believe that knowledge is the foundation of any organization's success. When a team's collective knowledge is more accessible, that team's potential is limitless.
Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Each day, thousands of customers rely on Slab across their entire workforces, including Asana, Benchling, and Fivetran.
You'd be joining a team of thoughtful and experienced engineers, distributed worldwide across North America, Europe, and Asia.
Yes, Lyft not being YC is is mostly it but also from an early Stripe employee [1]: "Lyft was also not originally on Stripe. They were on Braintree and switched over to Stripe after both Stripe and Balanced (another YC-funded payments company) competed for their business." Balanced was definitely a payments company also backed by YC. I cannot verify the switching from Braintree as I'm mostly an observer in all this but the other details are easily verifiable.
At first https://twitter.com/theryanking/status/1485784882173255680 seemed pretty damning but if you hover over the dates of the HN posts, the title attribute shows the timestamp, and it would appear Stripe's came in a couple hours before Bolt's. Add in Lyft and the "facts" around this story really seem to fall apart.
At Slab (https://slab.com), we believe that knowledge is the foundation of any organization's success. When a team's collective knowledge is more accessible, that team's potential is limitless.
Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Each day, thousands of customers rely on Slab across their entire workforces, including Asana, Benchling, and Fivetran.
You'd be joining a team of thoughtful and experienced engineers, distributed worldwide across North America, Europe, and Asia.
At Slab (https://slab.com), we believe that knowledge is the foundation of any organization's success. When a team's collective knowledge is more accessible, that team's potential is limitless.
Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Each day, thousands of customers rely on Slab across their entire workforces, including Asana, Benchling, and Fivetran.
You'd be joining a team of thoughtful and experienced engineers, distributed worldwide across North America, Europe, and Asia.
At Slab (https://slab.com), we're making the workplace a source of learning and purpose through knowledge-sharing. Our product helps teams easily create, organize, and discover knowledge across the entire company, from non-technical to tech-savvy. Our customers include Asana, Benchling, and Fivetran, who rely on Slab daily across their entire workforces.
You'd be joining a team of thoughtful and experienced engineers, currently distributed across North America, Europe, and Asia.
This post makes some salient points about the challenges of team knowledge sharing:
- Tree structure is too strict for cross departmental content ex sales to customer success handoff - should that be under sales or customer success?
- The right answer can be found in multiple tools - companies are not going to ditch Google Sheets / Excel for Notion tables
- A common source of truth needs to take into account the variability in skill - some users are going to be heavier users or more technical than others
- Collaboration needs to be as good as Google Docs or else people will just use Google Docs
It looks like the author is envisioning a new solution with Dokkument but if you want an existing one, take a look at https://slab.com. It’s designed to focus on team knowledge sharing while recognizing that it will be part of the productivity stack. For example, there is have a Content Map feature that shows a bird’s eye view of the entire information topology (with filters and drill down possible) and even mass reorganize from there. Integrations are first class with search retrieving results from other tools and rich linking that will preview external content. Knowledge sharing used to be an afterthought for a lot of teams but with the world going remote it’s exciting to see the innovation and prioritization pick up in this space.
Normally I would not promote my own company to the HN community without contributing something of value, but from the looks of the UI decisions in the "juicy screenshots" I would venture to say we have already done so: https://share.slab.com/v1uy96K8
So if Confluence and internal knowledge sharing is problem for your team but you want to try out a ready and available product, please give https://slab.com a look.
I would add most companies do not have the product/engineering/ux talent to approach this problem. Stripe is in the unique position that its talent can execute on several internal “projects” that each individually could justify an entire company to build. Most founders / leaders care deeply about their enriching their teams’ camaraderie and collaboration -- even if only from a cynical rational perspective of onboarding, productivity and retention efficiency (though I would argue from talking to many of them there is also a benevolent side to that). It is an hard problem to get right and Home nails several important details.
Disclosure: I am a founder of https://slab.com that is also addressing this as a scalable SaaS solution.
We is much simpler and easy to use and plays well with the non-Atlasssian ecosystem (as well as with JIRA). In both these regards we like to think of ourselves to Confluence as Slack is to Hipchat.
The company is called Slab (somewhat of a double reference to a thing you can write on and slab serif fonts). It is current in private beta but if you would like to take an early look please find my email in my profile and I would be happy to share with HN.
Disclosure: I am the founder of a company that aims to solve this first documentation case you pose. But the process of validating this problem and get early feedback on our solution, I interviewed to dozens of companies to learn about their tools and processes, and hopefully some of that can be helpful here.
The information split is very much as you describe between canonical and ephemeral. For the first case, the defacto tool for medium size companies (25-1000) is Confluence (large companies lean towards a custom intranet). Confluence is accessible to the entire company, not just engineers with git and markdown knowhow, it is also well established, very reasonably priced and can be deployed on cloud or on premise. There are drawbacks such poor search and complex organization that makes it hard to find anything, but there is not a clearly better solution at the moment, though there are a few startups like mine trying to change that.
For the second case, companies have tried to deploy an internal StackOverflow / Quora, some homegrown or using open source tool but unless tied to a specific workflow (like all hands Q/A), they are eventually abandoned. The issue is a lot of duplication of content that also changes very often. So long term storage is not as valuable as just removing the initial friction and what seems to work best is an ephemeral solution like a dedicated Slack/Hipchat/Teams/Mattermost/Gitter/Zulip channel.
I’m the author of Quill and I will attribute my decision to David Greenspan of Etherpad. Not sure if they are the first but it certainly predates all the examples I know of.
Quill is now a very popular project on Github, in the top 250 of all projects. A lot of people want to add their two cents to popular project and unfortunately the volume is far too high for a) me to respond to every single attempt at adding said cents and b) Github Issues's linear commenting UI makes all attempts at adding two cents confusing and cluttering. With this I prioritize the question that was asked, and specifically the concerns the OP raises.
I have repeated many times that the removal of getHTML was because it was a passthrough function that added no additional value to Quill. You can look at the code history and the implementation of getHTML to confirm this fact. It has nothing to do with the desire to remove functionality as no functionality was removed.
I'm confused why Delta is a bad name, since the word delta means change, variation or difference and that's seems to describe what it is: a change to Quill's content. Data source on the other hand is unspecific and even misleading. Naming is hard though and other readers can find out what Deltas are here https://quilljs.com/docs/delta/ and decide for themselves.
Tables was reported as a feature request by me early in the project life because it is a known feature of Word but only years later did users indicated strong interest in it in Sept 2016. I believe in community contribution to open source so I decided to give the community a chance to build it so I wrote offered detailed implementation guidance: https://github.com/quilljs/quill/issues/117#issuecomment-244.... The fact that this user had seemingly urgent need for it and was employed by a large public company with resources also contributed to this decision. Valuable exchanges were had in the Issue and multiple users has fully implemented it for their companies to varying levels of feature richness depending on their requirements. An official canonical implementation is coming in 2.0: https://medium.com/@jhchen/the-state-of-quill-and-2-0-fb38db....
Author of Quill here. Interested in hearing Marjin’s thoughts but here are some of my main observation is at a high level Prosemirror is much more willing than Quill to sacrifice simplicity for power. This value difference manifests in the target audience, architecture and API design:
Quill can be used for the get going quickly drop in use case. Prosemirror specifically warns against this: “If you're looking for a simple drop-in rich text editor component, ProseMirror is probably not what you need. (We do hope that such components will be built on top of it.) The library is optimized for demanding, highly-integrated use cases, at the cost of simplicity.”
Prosemirror’s schema, as documented, is more flexible than Quill’s. Prosemirror appears to allow anything, whereas Quill imposes some constraints. For example Quill requires all nodes to either be a leaf and cannot have children or a container and must at least one child. There cannot be a node that can optionally have children as is allowed in Prosemirror. In my experience the constraints Quill imposes lead to a more consistent and bug free experience across browsers. I will be curious to try out the edge cases I have encountered at this new 1.0 Prosemirror to see if it handles them the way an end user typist would expect. If Quill can benefit from a shift in the flexibility in its schema, it will do so.
Quill is far more battle tested. Slack, Salesforce, LinkedIn, Intuit and many others are using Quill in their main user-facing production products, not an internal employee only tool. Prosemirror has a great start with the NY Times but there is a large difference in adoption at the moment.
Creativity and rationality are conventionally seen to be at odds than they actually are. But often something creative and innovative to one person is boring and logical to another, particularly when the former is not versed in the latter's domain.
For example, many people versed in networking were using the early internet to make voice communications circumventing long distance telecom bills. It just seems obvious to them then (and many more people now) that if you can send data through the internet, why not encode audio in that data?
To me setting up a server/installation and maintenance is in the chore category of work so 1hr setup and say 15/min/month maintenance ~= 3 hrs/yr. Good programmer contracts can command $500/hr and the work might actually be fulfilling. 4hrs*$500 = $2000 pays for years of hosting.
Also you are not going to hit the top of HN on a regular basis as a casual blogger. Look at real data like your blog's historical traffic in the last year to get an accurate picture of the costs.
Source: I was one of the founders of Stypi and we asked him when porting the data from Etherpad to Stypi.
https://techcrunch.com/2011/08/09/yc-funded-stypi-is-etherpa...