On Fri, Jan 8, 2016 at 3:37 AM, Magnus Hagander <mag...@hagander.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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers