MESSAGE
| DATE | 2020-02-18 |
| FROM | Eli Zaretskii
|
| SUBJECT | Re: [Hangout - NYLXS] State of the GNUnion 2020
|
> From: Andy Wingo
> Cc: gnu-misc-discuss-at-gnu.org
> Date: Mon, 17 Feb 2020 21:37:55 +0100
>
> I agree also! This sort of activity is natural in a project that
> engages in self-reflection. If a project has leadership, then naturally
> leadership would be conducting the exercise.
Do you actually know whether the leadership does/did such analysis? I
don't, but if you do, please share the details.
I do agree that leadership of any project should track and analyze the
long-term tendencies in the project's life cycle. However, the
methods and tools for such an analysis are not necessarily the ones
you've chosen, and in any case what tools to choose is up to the
leadership.
> > _before_ showing us a bunch of naïve graphs and drawing conclusions
> > from them (which unsurprisingly coincide with the opinions the author
> > expressed long before showing those graphs).
>
> I know that we may disagree on interpretation of the data, and that
> neither you nor I can avoid starting this kind of investigation with
> preconceptions, but please believe that I did the analysis in good
> faith.
I didn't say and didn't mean that you did what you did in bad faith.
I said the tools and methods chosen were naïve, which is something
very different. The tendency to interpret complex data in naïve ways
is a frequent human error, I see it every day on my daytime job. That
we all tend to interpret the data in ways that are consistent with our
prior beliefs is also a common cause of incorrect and biased
conclusions, not at all a sign of foul play.
I think your conclusions are naïve because they take all of the
hundreds of GNU projects and apply simple statistics to all of them
together, as if they were a homogeneous population. My point is that
they aren't homogeneous, and any serious attempt to analyze the data
you used to reflect on the health of the GNU Project as a whole must
subdivide the projects into several groups and deal with each group
separately, according to that group's traits.
We all do this kind of selective analysis in each of our specific
projects: we distinguish between major and minor aspects of our
projects, between problems that affect the main functionalities and
those which affect marginal ones, or happen on platforms about which
we care less or not at all. We then consider only the important parts
when assessing the health of our projects, or at least assign very low
weight to the unimportant parts. Giving everything the same weight
will more often than not produce absurd or nonsensical results.
> or fork the repo and do your own analysis... seriously.
Sorry, no. Criticism of the methodology and tools is (or at least
should be) a legitimate response to a published analysis; saying "do
it yourself or forever hold your peace" is not a valid
counter-argument. If you are serious about your research, you should
hear the criticism, refine your methodology, improve your tools, and
publish corrected results. Or you can say "sorry, feel free to
disregard my conclusions, they are not necessarily valid".
> I have my conclusions which I stand by but which are certainly not
> set in stone.
I'm saying, quite simply, that the data and its analysis you provided
don't support your conclusions. First and foremost, the criteria
you've chosen as "health indicators" must be analyzed and validated,
_before_ they are used to draw such conclusions. I've seen no such
validation in your presentation. You seem to have accepted their
validity as an axiom.
> > Why wasn't such (or similar) analysis done before coming up with this
> > "state of GNUnion"? I think such anecdotal studies can speak volumes
> > more than those graphs.
>
> This could be! Please do go out and ask.
Again, that was a suggestion to _you_ to try and validate your
criteria. Don't turn the table and make it _my_ problem, because
doing so doesn't make your conclusions any more valid than they were
originally. The analysis you did was _your_ itch to scratch, not
mine. If you want to convince me that your conclusions are valid, you
will have to go the extra mile.
> > And then we have Guile, whose development pace leaves a lot to be
> > desired, if we really want it to become the GNU standard extension
> > languages. Strangely, the Guile developers, including Andy Wingo,
> > don't seem to do anything about that. There are no discussions about
> > making the project more active, none at all. Does that mean the Guile
> > level of activity is OK with Andy? If so, how does that live in peace
> > with the seemingly grave outlook for the rest of GNU?
>
> Honestly this argument is beneath you. You do not believe my
> conclusions about GNU -- which is fine -- but instead you try to shift
> the focus to the project I maintain, claiming that it is in poor health
> -- something that which would not invalidate the argument -- but, with
> no data or analysis to back it up, which is the aspect that you
> criticise about my conclusion. WTF.
This argument is a simple application of the health criteria you
consider significant to your own work as a project manager.
Presumably, if you consider the GNU Project to be in bad shape based
on the criteria you proposed, and since elsewhere you clearly see
yourself as a good candidate for making decisions for the whole GNU
Project, then examining how you apply those same criteria to your own
project is entirely reasonable. It is reasonable to expect that,
given the slow pace of Guile's development, you'd do something to try
to improve that by some changes in how your project is managed, how
you attract new contributors, etc.
> We can never know what might have been, but I believe that without my
> work on Guile, it would certainly be dead now.
I acknowledge and greatly appreciate your personal contribution to
Guile development. I'm sure many others agree with me. But this is
not what this discussion is about, it isn't about personal
contributions and efforts of the leaders. Rather, it is about how
those leaders manage their project, and what are the end results of
that management, the bottom line. That is, after all, the basis of
your call for changes in the GNU leadership, is it not?
Suppose the current leadership of GNU would respond to your criticism
by showing a schedule full of personal activities for advancement of
GNU, like criss-crossing the world, giving talks, writing essays --
would that convince you that the leadership does a good job? It
wouldn't convince me, FWIW. Because personal involvement and efforts
are not the issue here.
> > Last, but not least: I'm not at all sure that statistics of the kind
> > we were presented, which is based on various measures of package
> > activity, tells anything about "the health of GNU", because GNU, at
> > least as I understand that term, has almost nothing to do with
> > development activity of GNU packages. The development activity is
> > determined solely by the project's development team and its abilities
> > to draw contributions and find worthy development goals. GNU as an
> > organization doesn't have any impact on that, because they almost
> > never interfere into these matters (unless there's some sort of
> > scandal, which happens only very rarely).
>
> Thought experiment: what would GNU be if all of its packages stopped
> developing? Dead, right?
Of course. But my point above is that IMO such total death can only
happen if all the development teams of all those projects stop
developing them. It _cannot_ happen due to some actions (or lack
thereof) of the GNU leadership. And that, in my eyes, is one more
serious deficiency in the criteria you've chosen as indicators of "the
health of GNU" -- you think those indicators say something about the
GNU leadership, whereas I think that if they say something, it's about
the respective development teams of each project, i.e. about me and
you.
> I understand that some GNU developers feel that things are fine.
I, for one, don't know for sure "things are fine". I proposed one way
of looking at the health and the outlook for GNU -- consider the
release data of the projects that are central to any OS. But this is
a somewhat myopic view, and it cannot be used for any serious
conclusions without considering other aspects. For example, what
areas usually covered by any complete OS are currently absent in GNU,
and why? And there are probably other aspects to consider.
But the main point of this my criticism is that the criteria and
methodology of analyzing relevant data shall be validated before the
analysis is performed. As no such validation was done, and, moreover,
there's at least some evidence that the criteria are invalid, I don't
think the conclusions you've drawn are backed up by data, with all due
respect.
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
