Alexander Kriegisch (https://scrum-master.de) posted a version of this
over in the Maven group, in response to some folks who were nitpicking
the size of a changeset. I thought it was worth signal boosting. Yes,
it's all stuff we should already know and should already be doing, but a
periodic reminder isn't a bad thing.
------------------------------------------------------------------------
I want to drop a few general comments about contributions and reviews in
the OSS world:
If any of us ends up in the role of a reviewer:
-- Let us remember that contributors often want to solve specific
problems and have way less knowledge than we do, if we know the
project in question or the technical domain better than them.
-- Let us try to encourage, not dishearten them. Let us acknowledge
and commend their efforts.
-- Let us even accept imperfect contributions, help fix them up in a
feature branch and then merge them, if the changes look acceptable.
In some instances, we can even merge first, if the PR does the
right thing and only cosmetic things are to be improved.
-- Let us not abuse reviews as a tool to micro-manage the contributor
to change what we would have done differently, until it looks
exactly like a change we would have done ourselves. It is both
disheartening and a waste of resources on both sides.
-- Let us not force them to first and foremost cater to our needs as
reviewers, as if our own time was somehow more precious than
theirs, just because we sit in front of the merge button and can
exert power, blocking or accepting a PR.
I often sit on both sides of the table, being both the maintainer of an
OSS product and often a first-time or inexperienced contributor,
scratching my own itches by contributing, donating my time and effort to
do that, hoping to also help other users. I have experienced many
disheartening, a few condescending and even occasionally cruel
reviewers. Let us not end up being those loathsome people, just because
we switch seats.
If a change to be reviewed is complex - which can always happen, because
software development occasionally is a complex business - the GitHub
website is IMO not an adequate tool to conduct a review. In this case,
any serious reviewer should take the trouble to actually clone the
project, check out the branch in question and look at it in an IDE where
it is easier to navigate the code, slice and dice the changes and diffs,
see what was unchanged and has only been moved, added or deleted, maybe
run a build and see how the code and project structure really "feels"
before/after the change. There, the reviewer also directly has the
chance to commit on top of the contributor's changes and improve them,
guiding the reviewee by example. This kind of collaborative code review
is more welcoming and less disheartening.
Let us all remember: Today's first-time contributor might be tomorrow's
regular contributor who helps to unburden us from work we are too busy
for in the future. Win-win! Scaring off a first-time contributor is all
but a guarantee that she will never contribute again and use her time
for more rewarding efforts.
Sorry for getting this off my chest here and now, but I felt I wished to
send that message to the OSS development community (originally sent to
the Apache Maven users list).
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
