Re: No Issue Tracker - Say it Ain't So!

On Fri, Jan 8, 2016 at 3:37 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> /me waves hand....
>>
>> There are quite a few contributing companies that likely have people that
>> could help out with this in an educated fashion but aren't coders.
>
> Sort of like how they could also have helped out with cf management?

I agree with this sentiment. But let me also say this: managing a
CommitFest well is a Hard Job. It takes a very sizable amount of
time, a fair amount of technical knowledge, and an awful lot of
emotional energy. It's a completely thankless task: if you do it
well, some people are unhappy because their patches got bumped; if you
do it poorly, other people (or the same ones) are unhappy because the
CommitFest lasted too long. If you use the wrong tone in writing an
email to somebody, they will flame you as if you were trying to hurt
them rather than, as is actually the case, trying to help the
community. And you can't make anybody do anything: if not enough
reviewers turn up, or not enough committers turn up, you will fail,
even if you do everything right. Something under half of the attempts
to do this over the years have succeeded brilliantly (at least, IMHO);
many others have been indifferent successes or else failures, despite
the attempts having been made by community members of long standing.
It's just a really tough problem - you've got to be a combination
motivational speaker, technical whiz, diplomat, and organizational
guru to succeed.

It's unclear to me whether administering the bug tracker would be an
easier job or not. I think it would probably be somewhat easier.
There's probably not a lot that's real subjective about deciding which
bugs we fixed and which ones we're not gonna fix. I think the biggest
problem would likely be that we might occasionally have cases where
somebody submits something and somebody from the community replies to
say "we don't really care" and then the bug gets closed and the
submitter gets an email and goes ballistic, and unproductive arguing
ensues. It will be important to have an understanding that the person
updating the tracker is merely trying to make it reflect the expressed
will of the community, not trying to determine that will. If somebody
disagrees with the status applied to the bug, they should argue with
the community members who said "we don't care", not the person who set
the status to won't-fix.

If we had an "issue" tracker rather than a bug tracker, I'd expect a
lot more unproductive bickering. The consensus around which features
are worth having changes frequently, and a lot of features that nobody
desperately objects to are nevertheless awfully low-value and not
worth tracking until somebody comes up with a patch. Development of
feature X often changes the perceived value of feature Y, sometimes in
a positive way and sometimes in a negative way. I don't really have
any use for a system that's just a random collection of things
somebody wanted at some point, which is basically what the TODO list
is. A list of unfixed bugs, though, sounds like it might have real
utility, particularly if we got some volunteers to apply tags to them
so we could search for "multixact" or whatever.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company