Hi Mickael,
I have separated this thread from the previous one cause this will mixup
things...
On 24/12/18 15:40, Mickael Istria wrote:
Hi,
On Sunday, December 23, 2018, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
If we have good reliable tooling, then we hope to be able to encourage
contributions (as you don’t need a CLA for an “obvious” ~10-15 line patch -
intent to submit is sufficient) and get the code base more energised.
As a tentative new contributor, I'd like to voice that it seems to me that
the issues in getting more contributors are not first about code style or
technologies. (This is based on my experience.in the Eclipse IDE project
where some components were in a bad shape in term of community activity,
comparable to how Maven is right now, and managed to get better.)
While cleaner more modern and more «inclusive» code helps, adapting to
another code style or older code is still a simple enough exercise for
contributors to keep motivated and providing code.
What I feel missing in Maven project to make contributors feel more welcome
is reactivity and guidance of the core developers towards contributions: it
takes a lot of time to get feedback on a Jira and a PR, and I had to ping
contributors to get feedback. I still don't get why my patches are not yet
merged while feedback seems good.
> Being that insisting isn't something many
people can afford or like or dare to do. This lack of apparent interest in
external contributions is what can kill any open-source project.
I have to summarize this simply.
This is no lack of interest in any kind. It is simply a lack of time of
the committers...cause there is very limited number of committers...
It also seems like reviewing and testing PRs is not trivial, and that more
automation could help developers to trust incoming changes and deal with
reviews.
We already made a large steps into the right direction but this does not
mean to make more of them...
What kind of ideas do you have? To be honest reviewing a PR takes time
and based on my experience no (other) automation will help there..but If
you have ideas please share them...
So it you want more contributors in Maven,I think the #1 item by far is to
make sure PRs are reviewed and merged promptly and then that the «time to
market» between a patch and a release is short enough to not leave time to
contributors to consider competitve technologies or workarounds they'll
never contribute back.
This goes by having a mindset that makes core developers main task to grow
the community rather than fixing bugs or adding features.
That contradicts some of the feedback we got, cause we get feedback
saying why does it take so long to fix a bug etc...
But of course I do understand your point which is the right direction to
go...
About Maven 4.0, I don't have an opinion and am not enthusiast (that's my
natural reaction to revolutions over simple evolution). I'm curious about
what's the added value to produce and whether it's worth the risk and
effort.
But again, from my experience with Eclipse IDE,I think it's fundamental to
get a vibrant and flawless developer community before starting such a
revolution; and I don't have the impression current Maven community is big
and agile enough to sustain big changes.
The user community is very big but unfortunately the people who are
willing to help is not that big...
That said, I think Maven already enables some important success criteria,
like being on GitHub. So I'm confident things can and will improve to grow
the community.
Over the time it already evolved/grown in several aspects. Maybe not in
the speed we wish it had...
But it takes time...
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
