4 ms·

> Seriously there is nothing wrong with using e-mail (apart from the dated protocol) and for knowledge sharing your team is better of with some kind of wiki wit

> Seriously there is nothing wrong with using e-mail (apart from the dated protocol) and for knowledge sharing your team is better of with some kind of wiki with organized information. I'm the co-founder of https://www.fwdeveryone.com https://www.fwdeveryone.com, which implements the same sort of functionality on top of email. This way you can capture both the knowledge created within your organization, and also conversations between your coworkers and people outside your business. There is no new client to adopt, and your data already comes pre-exported into your gmail or google apps account. And if you have a conversation you'd like to share publicly then we provide tools, like requesting permission and redacting sensitive info, to make this easy also, e.g.: https://www.reddit.com/r/Connecticut/comments/65kbok/good_hikes_for_southern_ct/ https://www.reddit.com/r/Connecticut/comments/65kbok/good_hi... Wikis are great, but maintaining them is basically a full time job, which is why they tend to be terrible and out of date. And even in cases where you have a PM maintaining your wiki full time, the majority of organizational knowledge is still locked up in email. Given that the amount of personal non-spam email sent every day is something like 100x the total size of Wikipedia, it seems unlikely that chat programs, email replacement solutions, or wikis can ever really be a complete solution. Also, everyone already knows how to write or respond to an email, but many people within organizations don't know how to do simple things like making an account on a website. It sounds like a trivial problem, but we've found that having a system where everyone can contribute without having to learn anything new is actually a big win.

edoceo 9y ago
> Wikis are great, but maintaining them is basically a full time job, which is why they tend to be terrible and out of date Good documentation is a full time job, via Wiki or whatever. It's not the Wiki's fault it's out of date.
e12e 9y ago
Looks interesting. But from a qursory glance it appears to work with Gmail, and not with email?
- Alex3917 9y ago
  Right now the person uploading the thread needs to be using gmail or a Google Apps account. We started there because there are 1.1 billion daily active users, but in the future it will work with other email service providers. Being able to use DKIM and SPF to authenticate threads is part of our value proposition, and a key part of the value proposition of email in general. (For example, being able to prove that you agreed on X project requirements with a certain person on a certain date.) Doing this type of authentication requires every message in a thread, not just the last one, so the most pragmatic way to meet this requirement is to work with email service providers with available APIs. The alternative is storing the entire contents of your inbox, but this doesn't make sense until we're ready to roll out our enterprise offering.

edoceo 9y ago

> Wikis are great, but maintaining them is basically a full time job, which is why they tend to be terrible and out of date Good documentation is a full time job, via Wiki or whatever. It's not the Wiki's fault it's out of date.

e12e 9y ago

Looks interesting. But from a qursory glance it appears to work with Gmail, and not with email?

Alex3917 9y ago
Right now the person uploading the thread needs to be using gmail or a Google Apps account. We started there because there are 1.1 billion daily active users, but in the future it will work with other email service providers. Being able to use DKIM and SPF to authenticate threads is part of our value proposition, and a key part of the value proposition of email in general. (For example, being able to prove that you agreed on X project requirements with a certain person on a certain date.) Doing this type of authentication requires every message in a thread, not just the last one, so the most pragmatic way to meet this requirement is to work with email service providers with available APIs. The alternative is storing the entire contents of your inbox, but this doesn't make sense until we're ready to roll out our enterprise offering.