Re: Code of Conduct: Is it time?

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