Re: 3rd RFD: comp.databases.postgresql (was: comp.databases.postgresql.*) - Mailing list pgsql-general

Marc G. Fournier From: wrote:

> Mike Cox <mikecoxlinux@yahoo.com> writes:
>
>>                     REQUEST FOR DISCUSSION (RFD)
>>             unmoderated group comp.databases.postgresql
>
>>This is a formal Request For Discussion (RFD) for the creation of
>>the worldwide unmoderated Usenet newsgroup comp.databases.postgresql.
>>This is not a Call for Votes (CFV); you cannot vote at this time.
>>Procedural details are below.
>
>>CHANGES:
>
>>The changes from the previous RFD are:
>
>>1. The removal of the following groups from the RFD:
>
>>unmoderated group comp.databases.postgresql.admin
>>unmoderated group comp.databases.postgresql.hackers
>>unmoderated group comp.databases.postgresql.novice
>>unmoderated group comp.databases.postgresql.sql
>
>>2. The proposed comp.databases.postgresql.general group was renamed to
>>comp.databases.postgresql.
>
>>3. The charter has been changed to allow discussion of all topics that
>>were in the separate groups.
>
>>4. The comp.databases.postgresql.general group will not be gated to any
>>other group or mailing list.
>
>>5. The rationale was changed to reflect the removal of the "bogus"
>>PostgreSQL groups from the comp.databases.* hierarchy.
>
> Wern't these these the same changes as were between the 1st and 2nd RFDs?

No.  The 2nd RFD added 4 groups and the official charters from the
postgresql website.

>
>>To provide a Big Eight newsgroup for users of the PostgreSQL Relational
>>Database Management System.  Currently there is a mailing list gated to a
>>private hierarchy.
>
> The pgsql.* hierarchy is a not a private one, it is a public one carried
> by several of the large usenet servers.

Doesn't "private" denote a hierarchy in its own domain such as microsoft.*,
and gnu.*?  If I used an incorrect term, I'll be happy to change it.

>
>>*Announcements of new versions of PostgreSQL,  PostgreSQL related
>>software, and documentation.
>>*PostgreSQL performance, benchmarking and related topics.
>>*Discussions pertaining to the administration, compilation and
>>installation of PostgreSQL.
>>*Assisting beginners in using the PostgreSQL Relational Database
>>Management
>>system.  Help answer basic questions.
>>*SQL related matters including normalization, and theory as it applies to
>>PostgreSQL.
>>*General discussions of PostgreSQL.
>>*PostgreSQL Promotional ideas, etc.
>>*Programming using PostgreSQL.  Stored Proceedures,  Server-Side functions
>>written in C, PL/pgSQL,PL/Perl, and other languages.
>>*Discussions of PostgreSQL interfaces, including JDBC and ODBC.
>>*Discussions of the Contrib packages.
>
> Is there a reason why this is broken down into specific areas of
> discussion,
> or is this group *restricted* to just these?  If not, are  you sure you
> haven't missed anything?  Wouldn't a more general:
>
> This group is meant to discuss all aspects of the PostgreSQL RDBMS

PostgreSQL development, and bug reports must be discussed in the mailing
lists because the devopers are there.  The PostgreSQL comp. group does have
a well defined, and broad discussion scope.  That being said, maybe you
missed the line in the charter that reads:

"*General discussions of PostgreSQL."

Many informed individuals from news.groups and private emails from
PostgreSQL users told me to include a detailed charter. I followed that
advice, using the broad input for what they wanted to see in a PostgreSQL
charter.

>
> be in line with the purpose of the group?
>
>>This RFD has been posted to the following newsgroups:
>
>>news.announce.newgroups, news.groups, comp.databases,
>>comp.unix.bsd.freebsd.misc,comp.os.linux.misc
>
> Any reason not to include pgsql.general?  Or is that an audience you don't
> want included in the discussion?

Of course not.  They should participate because of the wonderful benefits
the big 8 comp group will bring to the community.  The group will enable
usenet PostgreSQL users to participate effectively in PostgreSQL
discussions.  It will bring greater exposure to the mailing lists as we
*will* post a pointer weekly about the existance of the mailing lists and
the highly specialized pgsql.* groups.

That way users will not wonder why there isn't a postgresql big 8 group.
MySQL has an RFD in news.groups, so it will be represented in usenet's big
8.  PostgreSQL needs that presence too.  There is pent up demand for it.

The pgsql.* hierarchy/mailing list is correctly focused on making the
mailing list experience wonderful.  In the same spirt, the
comp.databases.postgresql group will make the usenet experience excellent.

Those who prefer Usenet are under-served because the mailing-list/pgsql.*
gateway does not provide a seemless usenet experience.  Many feel that
getting emails in reply to a usenet post does not capture what usenet
should be like.  The issues of having to wait for their posts to make it to
the pgsql.* lists and hierarchy are also a concern.  Those interested
should visit news.groups and follow the passionate discussions on these
issues.

There is also the issue of having to ask their news providers to carry the
pgsql.* hierarchy.  With a big 8 postgreql group, users will have instant
gratification of every server carrying it.  When they see the pgsql
pointer, they will also become informed of the existance of the
mailing-lists and the pgsql.* hierarchy and can ask their providers to
carry them if that's what they want.

This is really about enhancing the popularity of PostgreSQL.  Voting YES is
like watering a plant, it helps the whole project and community of
PostgreSQL grow.  Each leg, whether it is the mailing list, the
comp.databases.postgresql group or the pgsql.* hierarchy will bring
PostgreSQL to a wider and bigger audience.

With that I hope everyone sees the great benefits of welcoming a new
comp.databases.postgresql group into the community.  Just imagine going to
comp.databases and seeing this:

comp.databases.mysql
comp.databases.postgresql
comp.databases.oracle.misc

This would be wonderful, and a great step in the advocacy and expansion of
the community of PostgreSQL users.