On Tue, May 22, 2018 at 2:02 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-05-22 19:59:29 +0200, Magnus Hagander wrote:
>> So the big question is, is the data we can get out of it worth it?
>
> I can't see it being worth it personally.
I tend to agree. First, it sounds like a lot of work. If we had the
opportunity to improve our process in a way that would naturally
gather this data while providing various benefits to the project, I
could see doing it. But if you ask any group of people to do extra
work just for reporting purposes, it tends to annoy people ... and
they often don't take the trouble to make it accurate, either. Even
with best intentions, it's all pretty subjective. Look at the
arguments we have about Bruce's count of release note items -- does a
change in the number represent a change in his standards, a change in
the number of items meeting his standards, an artifact of how he
groups things together, or a real effect? And that's with all the
classification being done by one person. With ~19 active committers,
it's bound to diverge even more.
I have found counting "number of lines added" with "git log -w -M
--stat" to be a decent barometer of contribution strength for a lot of
patches, but it greatly overstates the value of mechanical change.
I'm not sure there's any automated way to take that into account, but
it would be nice if there were. Anyhow, I'm inclined to view
automatically generated metrics, even if imperfect, as a better option
than manual classification.
Also, while it's useful to know how much is getting committed, I'm not
sure how much it matters in the end. It should be clear to everyone
at this point that there is insufficient committer bandwidth to deal
with all of the good patches that get sent in. I suggest we discuss
at PGCon what we want to do about that problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
