This document is a collection of tips to make communication at Sunrise better. Over time, we will change the tips, adapt them, add or remove some tips to keep this collection alive.
Please suggest additions and changes by doing a Pull Request. video on how to do a new Pull Request.
how to do that:
- instead of writing
I'll update the team once it's ready., writeI'll update the team once this document is finalized and ready to be shared. - this is another example of rewriting a sentence to make things easier to understand: http://recordit.co/3Cucebp0qE
Put yourself in the shoes of the user. How does your work looks like for the user?
how to do that:
- instead of writing
this feature is done, post screenshots of the app with the working UX - add videos of what the user will see and experience (and get bonus point!)
- put a mock instead of describing something with words only. a picture is worth a thousand words (or so they said).
Someone reading your last post should understand what are the next steps, especially for active issues.
how to do that:
- write
This issue is important and I'm currently working on it. - write
The next step is to review this code, and merge in the next beta, which is Monday
It's more convenient, when you write, to use adjectives to describe something. We are all lazy after all. For example, This solution is better is faster to type than explaining why this solution is actually better. But this makes it harder for your team to understand what you mean.
Explain why, instead of giving a vague adjective. Make the life of the people reading you easier, not the other way around.
It happens that sentences are incomplete by having words missing or incorrect words and it can sometimes make it harder to understand what you're saying. (this one is for you @pierrevalade)
If you don't know who should work next on an issue, assign to to yourself, and ask the team who should take it over. you're responsible for that issue until someone else is assigned. If you want to get someone's attention (for feedback, for instance) try to mention them before assigning.
This is important for your team members to know when you're working to work on something, and important for the rest of the team too.
Want to report a bug? Great! Try to reproduce it first. If you can reproduce it, give the steps to reproduce. If you can't reproduce it, say that you can't reproduce it. But don't assign the issue to someone else before you are being able to reproduce. Don't forget to specify the version (and the build number for our mobile apps) on which the bug occurred.
Before you close an issue, give as much information as possible. If the code related to that issue was deployed, say that is was deployed. If the issue is a duplicate, include the link to the other issue that is going to stay opened, etc...
As we're growing the team, writing a new message in the General channel will ping everyone. This can be annoying, especially if your message is only relevant to a few people. We now have a channel for our main offices (New York, Paris, etc.), and for each team (Web, Backend, Desktop...) that you can use to make sure we're keeping General for stuff that really needs everyone's attention, or very urgent matters. Jokes and GIFs are always welcome.
Since many of us work asynchronously across multiple time zones, we can easily lose track of who is working what and at what time. We have a channel called Now where we periodically post what we're working on. By appending #past or #now to the beginning of your status we can all keep in touch with what everyone is working on.