Good post. From my perspective, the size of a change set does not matter as long as it is consistent and tested. I should note that I am distinguishing change set in general from a PR from a non-committer contributor, where size can matter since someone will have to review it.
Gary On Mon, Oct 16, 2023, 4:46 PM Joseph Kessselman <kesh...@alum.mit.edu> wrote: > 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: dev-unsubscr...@xalan.apache.org > For additional commands, e-mail: dev-h...@xalan.apache.org > >
