# Setting Expectations Speaking with the public in an official capacity can be a bit risky because people have a tendency to hear what they want rather than what is truly said. These are the techniques I've collected for dealing with common situations. ## Never Communicate Dates ... or ETAs. ... or work estimates. ... or anything relating to time, really :laughing: If you give a date or time, [people will not read anything else other than the date or time and assume it to be a hard commitment.](#example-of-irrationality) People don't even know they're doing it a lot of the time. They're busy and they read everything you said but all that is important to them is the date, so that's all they remember. [Apple](http://www.apple.com) does this with virtually all product launches. They announce a product only when it can be pre-ordered or purchased almost immediately. It is essentially an extension of the old adage "underpromise and overdeliver". People are tempted to give dates when they believe them to be solid. The problem is that these beliefs are based on the best of intentions, they're the dates that you will hit only if everything goes according to plan. So then people are tempted to give a date with some extra padding. No matter what date you give, it is possible to miss it. A manager I once had was concerned because I occasionally missed dates I had committed to when estimating projects. This was a problem for him, so we had a talk and he told me he only wanted dates that I could "100% guarantee". I told him that I couldn't do that because I can't predict the future. He wouldn't relent, so I told him "10 years. I can guarantee that, unless I die, I can deliver this functionality in 10 years or less." He was less than enthused :trollface: The only date you can't miss is one you don't commit to, so just don't communicate dates ... ever. ### Example of Irrationality 1. [Volunteer maintainer provides a "very optimistic ... guess"](https://github.com/atom/atom/issues/15737#issuecomment-339586666) > We have no roadmap to my knowledge, but even if I'm being very optimistic (and assuming a backport is not going to happen), this is unlikely to happen any time soon. I'd guess maybe January. 1. [Community member takes it as a promise](https://discuss.atom.io/t/bad-text-rendering-in-atom-because-of-freetype-library/49311/4?u=leedohm) > According to the same topic, this issue will be fixed on the January’s release of Atom. 1. [Another volunteer maintainer reiterates that it was a guess](https://discuss.atom.io/t/bad-text-rendering-in-atom-because-of-freetype-library/49311/5?u=leedohm) > This is a very optimistic guess. The reality is that we can not know when we will release a version of Atom based on Chromium 62. It’s our policy to never promise dates on when things will be fixed, merged, or shipped until it _is_ fixed, merged, or shipped, respectively. 1. [Community member confirms they read only the date and assumed the rest](https://discuss.atom.io/t/bad-text-rendering-in-atom-because-of-freetype-library/49311/6?u=leedohm) > OK, I didn’t know about the project’s policy; this release date is just something I quickly saw while looking for my problem’s solution 🙂 ### Reactions #### Reactions to the slip of a promised release date for a free game update * https://www.epicgames.com/fortnite/forums/fortnite-discussion/general-discussion/53232-survive-the-storm-update-delay > Its amazing you detect the stab probs 1 day before the release > Why delay the notes if you have them ready? You told the community today for patch notes and the patch notes don't have any stability issues > Men with no trustable words ... Yeah this game is dead before he officially launch; The community will die so hard now You played with our hopes and trust and you EPIC failed > its just dumb just because you got a bug in the game you didnt show us the balance and fixing patchnotes.....-.- > Give us the notes. You made this event so vague enough as it is. I push this game like its the last game on earth. For the love of all the old gods and the new give us the broad strokes at LEAST! There is no stability issue with the notes themselves. I want to know if im playing hooky or not from work for this patch dangit! ### You Can Tie Features to Versions Rather Than Dates One technique I commonly use with Atom is I will say that "X is currently scheduled to go out with version Y", where X is a change, feature or bug fix. Of course, since I never give a date when version Y will be available, it gives people an idea of how long they will have to wait without ever committing to a specific date. But I will _only_ say this when the change, feature or bug fix is already committed to `master`. This is a much more realistic commitment and it gets around people's irrationality associated with dates. ### How Atom Communicated Release Dates When I was [Atom's](https://atom.io) Community Manager, we didn't have a set release schedule. We did our best to release on the second Tuesday of every month, but if we were unable to for whatever reason, we would wait until the next month. We never told anyone that wasn't a maintainer that this was our system, the only thing we communicated outwardly is that we would release new versions of Atom when they were ready. This system had several positive effects: * People active in the community over a period of time would get used to the system and know when to look forward to the next release * People who weren't regularly active in the community would still get pleasantly surprised periodically with new releases * Because there was no promised release schedule, people wouldn't feel entitled to a release every month and wouldn't complain if one didn't arrive * If people opened an issue asking when the next release would be or for us to post a schedule, we could easily close it stating that we only publish new releases when they're ready and, as a policy, we don't pre-announce releases Additionally, we never released outside of that cadence because if we did, even only once or twice a year, that would subtly train the community to expect that we could release any time and then they would start pestering us for when the next release would be. ## Be Clear When Speaking Only for Yourself When I was still only a volunteer on the Atom project, [I had a canned disclaimer](https://discuss.atom.io/t/why-is-atom-so-slow/11376/13?u=leedohm) that I would insert in some messages or posts: > _Disclaimer:_ I am not an employee of GitHub nor a member of the Atom Core team. I am just an enthusiastic volunteer :grinning: I used this liberally when speaking unofficially in official locations. Which, technically, was everywhere that I tended to talk about Atom. I would use this to separate my personal opinions or thoughts from official statements or commitments. And it was good that I did it too, because I would often get people replying that [they had assumed I was a GitHub employee.](https://discuss.atom.io/t/tabulators-are-not-aligned-correctly/6182/8?u=leedohm) Now that I am a GitHub employee and we have done away with the distinction between Atom Core developers and volunteer maintainers, it is still helpful to be very clear about: * When I am speaking for myself rather than the project or company * "It is my personal belief ..." * "On a personal level ..." * When I am communicating opinions rather than facts * "I believe ..." * "I feel ..." * "I think ..." * When I am communicating hopes or desires rather than plans * "I, personally, would love to see ..." * "My hope is that as a team we can ..." It is important to note that I never will speak of the beliefs, opinions, hopes or desires of any specific individual, my team or my company. If people want to hear such things, they will have to go to the source. But I will speak of my own beliefs, hopes or desires ... I'm just very clear about it.