So much to learn,
“One of the skills of a strong engineer is thinking through who needs to be informed of a change or a new feature, and what medium or media to use for that, and how to phrase it so you concisely and effectively communicate what the other people need to know.”
Go through –
Steve: In high school I was taught to think about “who, what, why, where, when, and how.” When you do a git commit, git kind of automatically supplies the “who” and “when”, so you don’t need to worry about that too much. So then you’re down to explaining what, where, why, and how. The “what” is the most important, and that’s usually the first line of the commit. The “why” and “how” can sometimes be really important as well, and for more significant commits, you want to explain your thought process in the following paragraphs. And then the “where” would be basically what subsystem you’re touching, and this is often a prefix in your first commit line, or sometimes it’s implicit enough that you can omit it.
Sumana Harihareswara: As for Agile: for me, the heart of Agile is the recognition that it’s rare to know, at the beginning of a project, EXACTLY what the end product should achieve. Like http://agilemanifesto.org/ says, valuing “Responding to change over following a plan”
Sumana Harihareswara: Agile in a classroom setting, or in a hiring or outsourcing setting, has a fundamental conflict built into it, because Agile tries to have way more formative assessments and nearly no summative assessments, and “what grade should this person get” and “should we hire these people” and “what project should the outsourced team work on and how will we know if they’ve done a good job” assessments are super summative.
Formative assessment or evaluation is diagnostic, and you should use it iteratively to make better decisions to help people learn and improve their work with better instruction & processes.
Summative assessment is checking outcomes at the conclusion of an exercise or a course, often for accountability, and judging the worth/value of that educational intervention. In a workplace, this often means that this data is used to persuade bosses & community that someone should or should not be hired, or that we’re doing a good job or that someone else is doing a bad job.
Sumana Harihareswara: Perhaps you can see how this difficulty also raises its head when we ask interns to write Outreachy proposals! We are trying to collaboratively set expectations that can be used for summative assessment during selection, at the mid-internship evaluation, and for the final evaluation at the end of the three months. But we also really want to be open to making lots of formative assessments and changing our plans along the way. It’s contradictory. But as part of the way we evaluate applicants (along with conversation and contributions), I think it’s still worthwhile.
Ways of communication in Zulip
- the intro tutorial for the first time a new user logs in
- hover text over icons
- pop-up help on, for instance, search and markdown syntax
- the README.md file at the top level of our repository
- the https://zulip.readthedocs.io/en/latest/ docs
- code examples in
- various other README files throughout the git repository
- zulipchat.com/api and zulipchat.com/integrations
- commit messages
- code comments
- GitHub issue and pull request comments
- chat.zulip.org discussion (this realm right here)
- probably more things I am forgetting