Ok, the deal at this point is that when you have a doc patch, when you
add the ticket make sure to add the 'docs' patch. It will then show up
in the documentation report on trac
(http://dev.rubyonrails.org/report/20) and it can be reviewed and
checked in.
Go add docs!
Kev
On 4/26/06, Hampton <[EMAIL PROTECTED]> wrote:
> Hey man, I'm up for helping with the docs.
>
> My vote: RJS docs.
>
> Once you get a list up, make sure to pass the link out here.
>
> "Let's get it on!" (TM)
>
> -hampton.
>
>
> On 4/26/06, Kevin Clark <[EMAIL PROTECTED]> wrote:
> > I'll take it. I'll post on my blog about it tonight and get some sort
> > of todo list so we can track who's working on what docs/tests and try
> > to get sd.rb in on the action (best way to learn about it is to have
> > to write about it ;) ).
> > Kev
> >
> > On 4/26/06, Scott Barron <[EMAIL PROTECTED]> wrote:
> > >
> > > On Apr 26, 2006, at 9:57 AM, Tobias Lütke wrote:
> > >
> > > > I don't understand this blog post. The graph looks more then
> > > > healthy to me.
> > >
> > > The graph doesn't mean much, really. It says that as the code LOC
> > > (measured by whatever he's using to measure LOC) has increased, the
> > > test LOC has increased in roughly the same proportion, and that test
> > > LOC is some degree lower, in terms of LOC, than code LOC.
> > >
> > > I think what he's driving at is that these lines should be converging
> > > rather than increasing at the same rate. Meaning we should be
> > > refactoring (lowering the code line) and adding more tests
> > > (increasing the test line). Or that when adding features, the test
> > > line rises at a greater rate than the code line.
> > >
> > > But, test:code LOC ratio doesn't really mean anything. It indicates
> > > nothing about the coverage of the tests or the quality
> > > ("correctness") of the tests. It makes a big assumption that the
> > > writers of tests are creating perfect tests that cover all scenarios
> > > the test is intended to cover, and that's never going to be the case,
> > > whether the tests are written by humans or generated automatically.
> > >
> > > There is no one metric for "test quality", there are several
> > > measurements that can be made. In the context of those other
> > > measurements, this graph might have meaning, perhaps it would
> > > demonstrate a correlation between code:test and coverage, but on its
> > > own it's pretty pointless, and is just being used an excuse to rant
> > > about something.
> > >
> > > Of course we've got code that could use refactoring, of course there
> > > are areas that could use increased test coverage, and of course we
> > > could benefit from increased and clarified documentation. What
> > > project isn't like that?
> > >
> > > I agree with Chad and strongly encourage folks to add documentation
> > > and test coverage. Everyone would benefit. A contest could be a
> > > neat idea if you can come up with some kind of metrics to determine a
> > > "winner", and that they are fair and published.
> > >
> > > -Scott
> > >
> > >
> > > _______________________________________________
> > > Rails-core mailing list
> > > Rails-core@lists.rubyonrails.org
> > >
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
> > >
> > _______________________________________________
> > Rails-core mailing list
> > Rails-core@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-core
> >
>
>
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
