PatchMetrix: Understanding and improving OSS patch contribution process capability

[Deen Sethanandha]

Hello,

  I am a Ph.D student at Portland State University.  I am going to be
working on Google Summer of Code 2010 through PSU.  My project is
PatchMetrix: Understanding and improving OSS patch contribution
process capability.
http://deen.sethanandha.com/2010/04/09/gsoc2010-proposal/

  I decided to extend the patchwork project.  I like the philosophy
that it doesn't replace existing tool or radically change existing
process but complementing it.  I plan to extend patchwork by adding
the metrics and statistics report and new views.  I am not sure yet
how I will integrate the code that I will write with the patchwork
codebase.  I plan to develop on my local repository but I will be glad
to contribute patch to the patchwork if I run in to any bugs.

   The enhancements that I plan to work on are.

1. Patch statistics

The following is the initial list of metrics and statistics that will
be collected and displayed.  More statistics will be determined during
the first milestone.  These are simple metrics that focus on project
as a whole.

·       The total number of unique reviewers

·       The total number of unique contributors

·       The average of reviews per patch

·       Patch inactivity time: Time since the last comment on patch

·       Patch response time: Time between patch submission and the first comment

2. Lean Production Metrics

Lean Metrics focus on the time-based statistics that helps OSS
projects understand the flow of contributed patches that may be
different in any given point in time.  The Lean metrics will be
collected and present as part of the project dashboard.

·       Cumulative flow chart

·       Patch arrival rate: How many patches are submitted each day,
week, or month

·       Throughput: the value delivered each month. This can be
measured by number of patch accepted or applied each month

·       Average Lead Time: The average duration from the moment
patches are submitted to the mailing list until they are committed.

·       Average Cycle Time: The average duration from the moment
patches are reviewed until they are committed.

·       Average Queue size: The average number of patch in each queue

3.    Location based filter

When there are more than one hundred incoming patches, it becomes
harder to track or browse.  A better filter capability is needed in
order to reduce the number of patches reviewer has to browse through.
I propose adding a filter by location of the code affected by the
patch.

4.    Kanban board visualization

Below is the screen mockup for the Kanban board view [5].  I will
focus on the read-only view for this project but I could be extended
in the future if more people start using Patchwork and wants to use it
to update status of patch instead of using email.

  You comments on the plan would be greatly appreciated.  I would like
to create something that would be useful to the patchwork community.
At this point I can still change the work item in #1 and #3.

Best Regards,
Deen