Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Email Transparency at Khan Academy (bjk5.com)
35 points by tghw on Jan 2, 2014 | hide | past | favorite | 10 comments


* Not sure if my response was posted on your site. Repeated here:

It seems like what you and your team really need is 'like' a Sharepoint / Dropbox for Emails where anyone (if permissions are set) can read through email content and project progression highlighted in email communication.

I recently put together a hack introducing Hashtags for Email. The idea is you hashtag important emails (in your case, most to all emails). Ex: "This Tuesday, I giving a #Project_A demo on #storage strategy at #Boxcon." This creates hashtag threads #Project_A, #storage, and #Boxcon. Non-storage team members can be invited to the thread read through the email discussion.

This stems from activity done personally, saving important content - Evernote for Email. In a team environment, email can be distributed - Sharepoint for Email.

Demo @ https://news.ycombinator.com/item?id=6948659

Granted, there are differences in your team's implementation vs. hashtagging contents. i.e. email client agnostic


For those who want to go super radically transparent: create one single Group everyone in the org is a member of. CC it on every non-private email.

Org members create a filter that puts the email away if they are not a direct recipient.

To follow along, search by hashtag (or anything else).


Interesting idea. May poke around w/ this.


It's transparent alright... they use Gmail!

Ok, joking aside, the article is about how they use email filters in Google Apps instead of mailing lists.


Short version: they have an extra "blackhole"/archive list for every team that every email is cc'd to. Also anyone can subscribe to anything.

The problem with this is, opacity is not the biggest problem with email. It's inbox noise. Reading through tons of emails that should have a more limited audience or have already lost their relevance.

I don't see how this approach reduces noise. If nobody is really expected to read the archive list, why bother sending something to it? If anything, transparency might actually make things worse, because they way you get it is by spending even more time digging through email archives.

To solve the Email Problem I would look to "newsfeed" style systems like Yammer or completely different models like chatrooms. Those can do a lot more to prioritize attention.


The entire thing is opt-in. Nobody is subscribed to anything by default — if you want to listen in on the mobile team's archive, you can. But you don't have to.

This reduces inbox noise because it increases the percentage of emails in my inbox that people expect me to read completely and/or do something about. No more "might as well just CC Ben for the heck of it." Those goes elsewhere, for me to quickly browse the subject line if and when I choose.


Not buying it.

A "blackhole" full of random emails to and from miscellaneous team members is not a great place to send an email that you think Ben might want to scan.

Realistically, for Ben to even see the email, he'd had to dig through tons of random crap in the hopes that there might be a subject line that catches his eye. There wouldn't even be an indication that someone thought that particular one might be up his alley (CC: Ben).. it's just a giant pool of random subjects to wade through. So that's even more noise for him to wade through.

Realistically, Ben isn't even going to do that. And the sender is going to realize that too and still CC Ben, so that he gets a chance to scan it.


I respect your skepticism, but that's not what happens in practice on our 25+ person team.


Transparency rocks, but this feels really ad hoc.

I mentioned on the Stripe thread: if you get tired of the corner cases and human nature not handled by their or this hackery, have a look at combining email aliases or filters on the front end with Best Practical's "Request Tracker" on the back end.


This feels like a hack or Domain Specific Language on top of email. It's interesting to think what the RFC for email would have been if how Enterprise uses actually uses it was baked in from the start




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: