see my comments inline below but in
general +1
Kind regards,
Dave Sag
Brett Porter [EMAIL PROTECTED] wrote on 07-03-2006
21:10:53:
This is not too long, and important. Please read.
I've just spent some time discussing this on users@, and felt it was
time to bring it here to look at
Thanks for taking an interest. I've got lots of replies to catch up on.
Tim O'Brien wrote:
Developers don't write great documentation. Don't raise the bar so high
that people are discouraged from submitting doco-less patches. Just create
a structure to address documentation deficiency.
I
John Casey wrote:
* Whether it works and does what is intended.
* Whether it fits the spirit of the project.
This seems like it would be hard for a user to assess. Not sure how a
patch contributor is supposed to handle it.
The first one is obvious, so I assume just just mean #2. Not for
+1
On 3/7/06, Carlos Sanchez [EMAIL PROTECTED] wrote:
I agree. Just one comment about javadocs, they are not important just
for public apis, they should be there for almost all methods so we
won't have to go into the details of the code when bug fixing or
writing new code.
On 3/7/06, Brett
+1 for everything and I hope this will be enforced (by all of us)
-Lukas
Brett Porter wrote:
This is not too long, and important. Please read.
I've just spent some time discussing this on users@, and felt it was
time to bring it here to look at the practical steps going forward.
Basically,
I think this is all pretty good in principle, but I have some concerns
about specific points, which I'll summarize below. I agree that we need
to raise our minimum quality at the release level, and even at the
individual commit level. However, I'm hesitant to add too much burden to
patch
This is not too long, and important. Please read.
I've just spent some time discussing this on users@, and felt it was
time to bring it here to look at the practical steps going forward.
Basically, I think we've all known for a long time that both need work.
There was a big push around 2.0 but
I agree. Just one comment about javadocs, they are not important just
for public apis, they should be there for almost all methods so we
won't have to go into the details of the code when bug fixing or
writing new code.
On 3/7/06, Brett Porter [EMAIL PROTECTED] wrote:
This is not too long, and
Brett Porter a écrit :
This is not too long, and important. Please read.
I've just spent some time discussing this on users@, and felt it was
time to bring it here to look at the practical steps going forward.
Basically, I think we've all known for a long time that both need work.
There was a
Developers don't write great documentation. Don't raise the bar so high
that people are discouraged from submitting doco-less patches. Just create
a structure to address documentation deficiency.
1. Create a documentation posse - identify people who will focus solely on
doco, reduce the
Hi,
My response inline...
Tim O'Brien wrote:
Developers don't write great documentation. Don't raise the bar so high
that people are discouraged from submitting doco-less patches. Just create
a structure to address documentation deficiency.
Sorry, but IMHO that's too much of a
On 3/7/06, Tim O'Brien [EMAIL PROTECTED] wrote:
Developers don't write great documentation. Don't raise the bar so high
that people are discouraged from submitting doco-less patches. Just create
a structure to address documentation deficiency.
+1
Patches should be able to be SUBMITTED
12 matches
Mail list logo
