|Re: [jdt-dev] "clean up" again|
I appreciate the more somewhat more balanced tone today and I
apologize for my decidedly snippy commentary yesterday.
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.Hi Jay,
On Wed, Jun 3, 2020 at 8:31 AM Jayaprakash Arthanareeswaran <jarthana@xxxxxxxxxx> wrote:
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 makingthe blame annotations useless" and "keeping the existing high-value committers in high spiritby 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 latterevery 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"
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 "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?
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.And even further, which one would your project manager choose as being the most strategic in mid/long-term?
I can well imagine the answer. :-)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?
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...Relying on a few non-replaceable people is a risk for the project they support, it's management 101.
Yes, certainly we all die at some point, so there does need to be new "resource" eventually.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.
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.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.
Yes, this is a fact.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).
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.This risk is strategically much bigger than the risk of something broken in the code from time to time.
_______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Back to the top