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 _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
