I have not even looked at the changeset yet, since last time I tried to
help with the taglet problem in the javadoc plugin. I was just following
the conversation a bit and 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 than 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 them, not dishearten them. Let us
acknowledge and commend their efforts.
-- Let us even accept imperfect contrubutions, help fix them up in a
feature branch and them merge 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 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. 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 more precious than heirs, 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. I have experienced many disheartening, a few condescending and
even occasionally cruel reivewers. Let us not end up being those
loathsome people, just because we switch seats.
Disclaimer (and back on topic): I agree with most recommendations about
the advantages of small, incremental commits, removing IDE config and
generated files from projects etc. But the latter two are all
imperfections which can be cleaned up later and were not even introduced
by the change itself.
To Greg Chabala: I did not mean *you* with my comments. :-) You were
friendly and professional in your wording and did nothing to scare
anyone off. You did not say anything wrong either. The trigger for me to
write this message was the recommendation to retrofit the big change
into smaller ones post factum now. Joseph was wrestling with Maven and
some of its plugins for the first time. I think, it would be too much to
expect from him to split the commits, just to make them more palatable
for reviewers. I am sure, he could do it, but is it really worth the
time?
Back once more to us in the role of reviewers: If a change to be
reviewed is comple - which can always happen, because software
development occasionally is a complex busi8ness - the GitHub website is
IMO not an adequeste 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 help to unburden 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 Apache Maven community (and actually many
others in the OSS world), even though the message might have been better
suited for the developers list.
Respectfully yours
--
Alexander Kriegisch
https://scrum-master.de
Joseph Kessselman schrieb am 14.10.2023 23:52 (GMT +07:00):
> I've just issued a pull request proposing that the Apache Xalan-Java
> project cut over from Ant-based to Maven-based build.
>
> This is the first time I'm working with Maven, and I'm *sure* I have
> done things that are bad form. If anyone has time and energy to glance
> at it and sanity-check that I haven't made too much of a mess, that
> would be tremendously appreciated.
>
> https://github.com/apache/xalan-java/pull/101
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
