Re: Code of Conduct: Is it time? - Mailing list pgsql-general

On 1/6/16 1:36 AM, Pavel Stehule wrote:

The CoC doesn't solve it. We do on mature, stable, pretty complex
code - use C (not JavaScript or Java).  This isn't hobby project or
student project.

No, CoC by itself doesn't grow the community. That doesn't mean we
shouldn't have one.

Another weakness we have is the mentality that the only way to
contribute to the community is as a developer. There's tons of other
ways people could help, if we made an effort to engage them.
Infrastructure, website design, documentation, project management (ie:
CF manager), issue tracker wrangler (if we had one), advocacy. There's
probably some others. It wouldn't even take effort from the existing community to attract those people; all we'd need to do is decide we wanted non-developers to work on that stuff and find some volunteers to go find them. But the big thing is, the existing community would have to welcome that help. Part of that would mean some changes to how the community currently operates, and the community can be very resistant to that. (I suspect partly because it pays to be very conservative when writting database software... :) )

Taking new developers needs the hard individual work with any
potential developer/student. I see as interesting one point -
PostgreSQL extensibility - the less experienced developer can write
extension, there can be interesting experimental extensions that can
be supported without risk of unstability of core code. Can be nice to
allow to write not only C language extensions. Then the Postgres can
be used on universities and in some startup companies - and it can
increase the number of active developers. My very talented colleague
doesn't write to Postgres due C language. He like to write planner in
lisp or erlang. Or like to play in these languages. C is barrier for
younger people.

Agreed. I recently said something to that effect to a few others, using
Python as an example. If you look at the Python source, there are 380 .c
files and 2000 .py files. Postgres has 1200 .c, 2000 .h and only 652
.sql. Since there's 640 .out files most of the .sql is presumably tests.
I'm not suggesting we switch to Python; the point is we could do a
better job of "eating our own dog food". I think it would also be very
interesting if there were add-on frameworks that allowed things like a
planner written in another language (which with the planner hooks might
actually be possible).

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com