Keep a daily team log
In development teams there’s a practice of doing stand-up meetings in the morning. In these meetings everyone very briefly tells the rest of the team what they did the day before, what they are going to work on that day, and what issues they are facing (so others can help).
We’d therefore like you to keep a log of short, daily status updates for your team. It will not only get you familiar with a good team practice, and with the high level of transparency that is typical for Open Source development. It will also help greatly with self-reflection, and give a good overview of what each of the RGSoC teams are doing.
We recommend you write your log entries at the end of your work day. During the day it may help to keep a list of keywords about your work throughout it. This will help you remember things very quickly when you write about them in the evening. Since you keep a log as a team, this will also help you share the work between you.
What goes in a team log?
Your log updates should, at least, answer the question “What have I done?” in a brief fashion. That could just be bullet points like “Set up Homebrew on our computers so we could install Postgres”, or “Discussed the command line switch X with our mentor and agreed on a test case”.
Of course, feel free to go into more detail, or answer the questions “What are we going to do tomorrow?” and “What issues do we need help with?”, but don’t spend too much time on making things pretty. It really shouldn’t take more than 5-10 minutes to write this entry.
Please keep this log in an application that has a publicly accessible RSS or Atom feed (from which we need the URL). Typically that could be a blog. We will use the feed to aggregate updates from all teams in a central place.
Because this should be a list of short, pragmatic daily updates you might not want to use your personal blog for this. We recommend setting up a new, separate blog instead.
Why keep a team log?
First and foremost a log helps you to learn and reflect on your work and learning experience. Fewer things will slip your memory and after a month or two you’ll remember more clearly what you’ve done.
Secondly, as we will aggregate all log entries to create a stream of activity across all teams, you’ll be encouraged to explore what other teams are doing, comment or possibly even help out, and also become comfortable with the practice of sharing your work publicly: Open Source culture is a lot about public collaboration toward a collective goal.
It might feel scary to share at first, especially if you’re starting out or feel inexperienced, but you don’t need to worry: Sharing, asking for help, and helping others is part-and-parcel of Open Source development. Everyone’s activity is visible in Git commit logs on GitHub anyway, which everyone sees as a good thing because it boosts all the fantastic possibilities of collaboration that are typical to Open Source development culture. That’s why we think it’s essential to your experience being part of a public coding community :)
This resource will also help us to do some basic supervision and catch situations where teams are having issues, so we can find people to help. Obviously this won’t usually be required because each team already has a fantastic local support network. But we think it’s good to have an extra safety net. Also, quite a few sponsors have asked what we have in place for “quality management”. We’ve pointed at the different levels of support we are offering in order to make sure every team has the best chance to succeed. The daily team log updates are an important part of this.
Is the team log optional?
All that said, we feel we can not stipulate keeping this log, but we do very highly recommend it. If you have a very strong reason for why you cannot do this, please get in touch with us.
What now?
If something’s not clear, or you have any questions about what you need to do, please let us know by emailing summer-of-code@railsgirls.com