Re: Code of Conduct: Is it time?

2016-01-06 17:04 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> 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... :) )
>

it's true

>
> 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
>