[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] "clean up" again
|
All,
I appreciate the more somewhat more balanced tone today and I
apologize for my decidedly snippy commentary yesterday.
On 03.06.2020 09:06, Mickael Istria
wrote:
Hi Jay,
If I had to chose between "a couple of
contributions that don't bring much to the
table but have the potential to break
something and make my life difficult to making
the blame annotations useless" and
"keeping the existing high-value committers in high
spirit
by not putting them through this kind
of breakages that could cost them their weekend,
discussions like these in the name of
broader mind", then I will go with the latter
every single time.
Let's try another choice (which is a corollary): if you
have to choose between "JDT becomes a more diverse project
with more contributors, but at the cost of something broken
from time to time, and useless blame annotations"
Blame annotations are very useful, in my opinion, and it's sad and
decidedly harmful when they become useless. As a contributor to
many projects, it's frustrating to me when the history of
semantically important changes are lost in a sea of reformatting and
other style changes. It makes it difficult to understand why the
code is the way it is without a lot of additional detective work.
That too is a barrier to contribution.
and "Only Jay and Stephan and a few other blessed people
work on JDT forever because apparently we assume all other
committers are not good enough for this task", which one would
you chose?
I don't believe these folks feel only they are good enough.
Speaking from my own perspective, I'm a bit of a control freak, and
I like to understand every last line of my code. It's not that I
think I'm better than other people, it's just that in the end I am
(or at leave feel that I am) personally responsible for every last
line of code. I understand that this is a bit pathological.
And even further, which one would your project manager
choose as being the most strategic in mid/long-term?
Also speaking from experience, managers like to move people from
project to project on a regular basis because it's easier to manage
"resource" in this way. So I'd not put a lot of weight in what my
manager wants; that's why I avoid having one in the first place.
Which one do you think Red Hat, which is investing in
Eclipse stack and consuming it downstream, should encourage to
make it's JDT-based offering last the longest?
I can well imagine the answer. :-)
Relying on a few non-replaceable people is a risk for the
project they support, it's management 101.
Yes, exactly. Management 101. Unfortunately most often the manager
is clueless about the nature of the "resource" they manage and about
the intricate details of technology itself. It's all just
"resource" to manage and best make all "resource" interchangeable...
So to mitigate this risk, there is no other way than trying
to get more people involved in the project to learn from the
experts, progressively taking care of some of their tasks.
Yes, certainly we all die at some point, so there does need to be
new "resource" eventually.
Of course, this is not perfect at 1st try, it requires
training, and this is sometimes extra work for the experts to
deal with this "training". But in the end, it's profitable for
everyone.
Well, that's kind of the point. Who reaps the profit? The
"resource" being managed perhaps pays a large cost for the profit of
others.
An OSS project community that is not willing to welcome and
train new contributors is IMO putting an extremely high risk
on the project of dying as soon as a few individuals reduce
their investment (for whichever reason).
Yes, this is a fact.
This risk is strategically much bigger than the risk of
something broken in the code from time to time.
I believe it comes down to who actually pays with their time and/or
money? If to a large extent that is the burden born by those
already working their assets off, then you can see why there is
resistance no matter how strong and correct your arguments are. And
your arguments are both strong and correct.
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev