For those interested, I've made available a couple reports from a class assignment where we analyzed the Django codebase, bug tracker, and wiki. The motivation of these reports was to answer questions related to code size, modularity, complexity, unit test coverage, and component quality.
Instead of attaching the roughly 3.5MB worth of PDF reports in an email to the list, I've made the reports available on my website: http://thegarywilson.com/blog/2012/software-metrics-django-case-study/ For the lazy, here are several points mentioned in the papers: * Since 2005, slightly more than linear growth of source lines of code (SLOC) and number of files, with a noticeably faster SLOC growth rate in the last couple years. * Project started with 11k SLOC in July 2005 and has grown to over 70k SLOC in Nov. 2011. * Almost half of the SLOC within Django reside in the contrib package. * Growth rate of "complex" files (files with at least one function with cyclomatic complexity greater than 10) has also been nearly linear over time, but at a lesser rate than the SLOC growth rate. * Average complexity of files (weighted by SLOC) peaked in 2008 and has been in a declining trend since. * 10 files contained at least one function with cyclomatic complexity greater than 20. * Percentage of functions and classes with docstrings peaked in May 2009 near 50% and has been declining since (to near 40% in Nov. 2011). * Packages with the lowest percentage of classes/functions/methods with docstrings include: templatetags, http, template, and db. * 16000 tickets: 63% not categorized. Of the remaining, categorized tickets: 59% bug/defect, 17% new feature, 15% enhancement, 8% cleanup/optimization, 1% task. * Ticket resolution times: At one month after opening 35% of new feature tickets are closed compared to 50-80% with other ticket types. * Average defect repair time (i.e. time to ticket close) is 65 days (though varies from 127 days for tickets categorized as normal to 31 days for tickets categorized as trivial). In general, average repair time has steadily decreased over the life of the project. * The components with the most defects reported are, in order: documentation, database layer, contrib.admin, and core, which in total account for almost 60% of all reported defects. * If taken in aggregate, defects reported for apps in the contrib package account for about 25% of all defect reports. * 13% of all tickets submitted have been marked as duplicates. * When normalized by size (defects per SLOC), core had the highest defect density by far, followed by the database, forms, and templates components. * The most edited wiki page is the "DevelopersForHire" page. * The wiki consists of 600 pages with an average of 0.26 attachments, 18.4 revisions, and 32512 characters. * From 2007 to 2011, code coverage of the unit test suite more than doubled, from 39% to 90%, with a large increase seen between the 0.96 and 1.0 releases. * 59.3% of the non-zero-length modules had 95% or greater test suite line coverage, and 40.3% had 100% coverage. So, I think these reports show that there are some things Django is doing well at (e.g. test coverage, avg. defect repair time improvements, avg. complexity), and that there are some areas that could be targeted for improvement (e.g. components with high defect counts and densities, docstrings and source comments). Thanks, Gary -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
