-
-
Notifications
You must be signed in to change notification settings - Fork 63
How to Communicate with the Team
Salutations! This wiki is all about being an effective communicator with the team. As volunteers, we all lead busy lives and cannot always dedicate time to this project. Communicating effectively, allows us to keep our team updated on our work without interrupting our busy schedules.
In this wiki you will find a section about writing good weekly progress updates on your assigned issues, and frequently asked questions about communicating with the team.
- Introduction
- How to Give Weekly Progress Updates
- How to Help a Team Member with their blockers
-
Frequently Asked Questions
- 1. Who do I contact if I cannot make a meeting?
- 2. I want to chime in with something over Zoom but I am being talked over. What can I do?
- 3. How do I ask for help on my issue?
- 4. Do I need to update my issue weekly by Sunday?
- 5. How do I set up a private meeting with a team lead?
- 6. How do I let the team know I will be gone for the next X days?
- 7. I want to leave the team. What do I need to do?
- 8. My pull request has done. What do I do now?
- 9. My pull request has been sitting without a review for a couple of days. What do I do?
- 10. Why do I still need to make a progress update if I have a pull request?
A progress update is brief update on the progress of an issue. This update motivates a team member to reflect on their work on an issue for the past week, the work still remaining, and the blockers to completing the issue. It also communicate to other team members that you are actively contributing to the team even when you cannot make meetings or respond to messages. A progress report has 5 parts:
- Progress: "What is the current status of your project? What have you completed and what is left to do?"
- Blockers: "Difficulties or errors encountered."
- Availability: "How much time will you have this week to work on this issue?"
- ETA: "When do you expect this issue to be completed?"
- Pictures: "Add any pictures of the visual changes made to the site so far."
The ideal time to give a progress update would be on Friday or Saturday, ahead of the Sunday meeting. This gives you a chance to ask for help on the Sunday meeting should you realize that you need more information to complete your issue. Optionally, you can also put the the Status: Help Wanted
label on your issue. This signals to the team that you need help, and anyone from the team can come and assist you with your blockers.
To effectively communicate your blockers, be sure to supply as much information as possible when writing the progress update, such as pictures, and very specific questions. This way a team member would not need to guess what your blockers are and can provide specific help and feedback for your issue.
Note: If an update is not made over a period of 2 weeks, the issue becomes labeled 2 weeks inactive
, meaning that it has a chance of being unassigned. To prevent this, make sure to update regularly, even if a pull request is made.
At HackForLA, we encourage team members to help one another with blockers on their issues. There are several ways someone might ask for help:
- Through a Slack channel message
- During one of our scheduled meetings
- Adding the
Status: Help Wanted
label to an issue
Regardless of how you noticed someone asking for help, this is a good chance for you to nurture your ability to mentor others! If you have never mentored someone before, here are a few guidelines that can help:
- The very first step is to listen. Make sure to understand their blockers before giving a response, or assuming what the issue is about.
- Ask lots of questions! Sometimes blockers are not really blockers at all. Someone might not be asking themselves the right questions. Asking questions is how you can guide someone towards the right answer.
- Give links to documentation. Documentation is helpful, since it can be bookmarked, and referenced later.
- Offer to figure it out together. Often, we do not know how to solve a blocker ourselves, but by working on it together with someone, the task becomes much easier. Two heads are better than one!
- Schedule a time to pair program. Pair programming is a good way to provide hands-on help.
- Ask for help when needed. If an issue is way over your head, but you want to help, sometimes asking a third or fourth person, perhaps during a meeting, can get you the feedback you need.
There is no need to contact anyone at all. All of us are here on a volunteer basis. It is perfectly fine to miss a meeting. That said, notes are kept for every meeting, so be sure to ask a lead for the latest notes, and keep up with the latest news.
First of all, so sorry that you feel this way! It can be nerve-wracking to speak up in a room full of people you do not know (or even if you do know them). When you want to get a word in, the best way is to use Zoom's ability to raise hand. This will signal to the facilitator to get to you and your needs.
Raising hand in Zoom
When you need help on your issue, there are 3 things you can do:
- Move your issue to the Development meeting discussion column and bring it up during a meeting and
- Write questions with screenshots, if any, on your issue and attach the
Status: Help Wanted
label to the issue and pull request. - Write questions, with screenshots, if any, on your issue, and link your issue in our slack channel.
It is highly recommended to update your assigned issue by Sunday, because that is when we have a meeting and is most equipped to help with your issue. If your update comes after that day, it will take us until the next cycle to notice your issue, unless it is brought up in another way, such as posted on our slack channel.
Also, if you cannot make an update weekly, due to vacation or some other event, make sure to place an update ahead of your absence! In this update, be sure to note how long the absence will last and when you expect to return. This way, we understand why the updates are not made.
The best way to set up a meeting with a team lead is thorough private messaging. In you message be sure to specify:
- The nature of the meeting.
- At least 3 blocks of time that you are open to meeting.
- Links that will help the lead infer your intent, like the link of your assigned issue.
By specifying these three things, we skip a lot of the back and forth and go straight to setting up a solid meeting time.
Also, before setting up a meeting, consider whether you need to speak to a lead at all. If the nature of the inquiry is about GitHub, or your issue, searching for resources online might be more helpful. Also, asking the Slack channel might also give you a faster response.
This is usually indicated on your progress report. For the blockers or ETA section, note the time frame you will be gone. This way the team understands why your issue lacks progress while you are away. This prevents us from accidentally assuming you disappeared and removing you from your issue.
Contact a team lead and let them know about your departure. They can sort out the project board and make sure that everything is in order. Good luck in your future endeavors!
When a pull request is made, the next step is to wait for another team member to review your work. This team member can be anyone, except you (unless you are an admin lead). In the mean time, you can review other pull requests in the queue that you feel comfortable reviewing. For more about reviewing pull requests take a look at this wiki.
A pull request should not sit without a review for more than 3 days. If you are the assignee, you need to make inquiries and unblock the pull request. In this scenario, you have several options:
- Send a Slack message in the channel and request a review.
- Request a team member to review the pull request during the next meeting.
- If reviewers are already requested, message them over Slack and find out whether they can review your pull request in a timely manner. If not, it is a sign that the reviewer is busy and a new reviewer should be assigned.
The progress update represents the one source of information on the status of your issue. Although there could be a pull request related to the issue, the team is still interested to know what is happening with the pull request. Because of our "only work on 1 issue at any time" rule, it is dreadful for an issue to be stuck because it has been waiting for reviews or help is needed to resolve the requested changes. By giving a progress update, we can be alerted to what is happening to your pull request and take the steps to unblock the pull request.