Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of north.n@gmail.com designates
 74.125.82.180 as permitted sender)
Subject: Re: Process for code submissions?
References: 
 <CAGHTdUVhaoxoHqt1UVY=+gVGzbHcr191yc9E9F-NK=assT=sfg@mail.gmail.com>
 <5799695298685609019@unknownmsgid>
From: Nick North <north.n@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <5799695298685609019@unknownmsgid>
Message-Id: <34BB1E49-CBB1-4A7D-967E-F982D38E45BA@gmail.com>
Date: Sun, 5 Aug 2012 17:48:03 +0100
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

Many thanks for the reply. I will sort those things out and resubmit.=20

Nick

On 5 Aug 2012, at 16:44, Robert Newson <robert.newson@gmail.com> wrote:

> Heh, and update the changes and news file so it mentions the new feature. :=
)
>=20
> Sent from my iPad
>=20
> On 5 Aug 2012, at 16:05, Nick North <north.n@gmail.com> wrote:
>=20
>> I'm wondering if there is any process for dealing with code submissions
>> i.e. for getting a decision that they are accepted, rejected, or ignored.=
 I
>> hope the following doesn't come across as a complaint, because I think
>> CouchDb and the community are great, but I feel in limbo on this particul=
ar
>> topic.
>>=20
>> The reason for asking is that I submitted JIRA issue
>> COUCHDB-1373<https://issues.apache.org/jira/browse/COUCHDB-1373>a
>> while back, then let it drop for some while before submitting pull
>> request 28 <https://github.com/apache/couchdb/pull/28> with proposed code=

>> for implementing the suggestion. After some initial discussion on the JIR=
A
>> issue, there was no response to the pull request, and I don't know if tha=
t
>> means I didn't follow the right process, it has been rejected, it's been
>> decided to ignore it, or it's gone into a queue to be considered eventual=
ly.
>>=20
>> There are many good reasons for not accepting submitted code: the
>> suggestion may be bad, the code may be bad, there may not be the resource=
s
>> to deal with it, it may be undesirable creeping featurism, it may come fr=
om
>> someone who hasn't demonstrated good understanding of the project etc. An=
y
>> of those verdicts might apply in this case but, whatever the reason is, i=
t
>> would be good to be told it so that I know whether it's worth expending
>> more effort to improve my chances of acceptance, or whether to spend that=

>> time on finding ways to carry on without the proposed code.
>>=20
>> If someone can help or guide me, or give an outline of how things operate=

>> in this area, I'd be really grateful. Many thanks,
>>=20
>> Nick North