{"thread":{"id":"13436","subject":"[RFC] Use cases for 'git statistics'","startedAt":"2008-05-08T15:51:35Z","lastAt":"2008-05-21T20:52:16Z","messageCount":16,"participants":["Sverre Rabbelier","Jakub Narebski","Andreas Ericsson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"76377","messageId":"bd6139dc0805080851y2065bedfsf0f388cfd6d85929@mail.gmail.com","threadId":"13436","inReplyTo":null,"subject":"[RFC] Use cases for 'git statistics'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2008-05-08T15:51:35Z","receivedAt":"2008-05-08T15:51:35Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nI've been busy to write up some use cases for 'git statistics' (a new\ncommand that I will be implementing this summer during Google Summer\nof Code). For more details on my proposal please see\nhttp://alturin.googlepages.com/gsoc2008 (a pdf of the use cases is\nhosted there as well for those who prefer pdf). I would like to ask\nfor comments on the current use cases; is anything missing, or should\na particular use case be removed/merged? Please let me know.\n\nThank you for your time.\n\n\n\n== Terminology ==\n\nThere are four types of users: Maintainers, Developers, Bug-fixers,\nand regular Users. The first three are all Contributors.\n\nName: Maintainer (Contributor)\nDescription: The Maintainer reviews commits and branches from other\nContributors and decided which ones to integrate into a 'master'\nbranch.\n\nName: Developer (Contributor)\nDescription: The Developer contributes enhancements to the project,\ne.g. they add new content or improve existing content.\n\nName: Bug-fixer (Contributor)\nDescription: The Bug-fixer locates 'bugs' (as something unwanted that\nneeds to be corrected) in the content and 'fixes' them.\n\nName: User\nDescription: The User uses the content, be it in their daily work or\nevery now and then for a specific purpose.\n\n\n\n== Use cases ==\n\n\nA model where other Contributors review commits is assumed in all use\ncases. When referenced are made to a Contributor addressing another\nContributor to adjust their behavior as the result of data mined, it\nshould be kept in mind that the Contributor should foremost be the one\nto do this. Using this information to, say, spend more time checking\none's own commits for bugs when working on a specific part of the\ncontent on one's own accord is is often more effective then doing so\nonly after being asked. </disclaimer>? :P\n\n\nName: Finding a Contributor that is active in a specific bit of content.\nDescription:\n\tWhenever a Contributor needs to know about other Contributors that\nare active in a specific part of the content they query git for this\ninformation. This could be used to figure out whom to send a copy of a\ncommit (someone who has recently worked on the content a commit\nmodifies is likely to be interested in such a commit). This\ninformation may be easily gathered with, say, git blame. Aggregating\nit's output (in the background if need be to maintain speedy response\ntimes), it is trivial to determine whether a Contributor has more\ncommits/lines of change than a predefined amount. The main difference\nwith git blame is that it's output is aggregated over the history of\nthe content, for a specific Contributor, whereas git blame only shows\nthe latest changes.\n\n\nName: Finding which commits touches the parts of the content that a\ncommit touches.\nDescription:\n\tThere are several reasons that one might want to know which commit\ntouches the parts of the content that a commit touches. This may be\nimplemented similar to how git blame works only instead of 'stopping'\nafter having found the author of a line, the search continues up to a\ncertain date in the past.\n\n\nName: Integrating the found 'bug introducing' commit with the git\ncommit message system.\nDescription:\n\tWhen a Bug-fixer sends out a commit to fix a bug it might be useful\nfor them to find out where exactly the bug was introduced. Using the\n'which commit touched the content this commit touches' technique\noptional candidates may be retrieved. After picking which of the found\ncommits caused the bug, this information may then automatically added\nto the commit's description. This does not only allow the Bug-fixer to\nmake clear the origin of their commit, but also make it possible to\nlater unambiguously determine a bug/fix pair. Note that this is\nautomated, no user input is required to determine which commit caused\nthe bug, only the picking of 'cause' commits requires input from the\nuser.\n\n\nName: Finding the Author that introduce a lot of/almost no bugs to the content.\nDescription:\n\tContributors might be interested to know which of the Developers\nintroduce a lot of bugs, or the contrary, which introduce almost no\nbugs to the content. This information is highly relevant to the\nMaintainer as they may now focus the time they spend on reviewing\ncommits on those that stem from Developers that turn out to often\nintroduce bugs. On the other hand, Developers that usually do not\nintroduce bugs need less reviewing time. While such information is\nusually known to the experienced Maintainer (as they know their main\ncontributors well), it can be helpful to new maintainers, or as a\npointer that the opinion of the Maintainer about a specific Developer\nneeds to be adjusted. Bug-fixers on the other hand can use this\ninformation to address the Developer that introduces most of the bugs\nthey fix, perhaps with advice on how to prevent future bugs from being\nintroduced.\n\n\nName: Finding the Contributor that accepted a lot of/almost no bugs\ninto the content.\nDescription:\n\tSimilar to the finding Authors that write the bugs, there are other\nContributors that 'accept' the commit. Either passively, by not\ncommenting when the commit is sent out for review, or actively, by\n'acknowledging' (acked-by), 'signing off' (signed-off-by) or 'testing'\n(tested-by) a commit. When actively doing so, this can later be\ntraced, this information can then be used in the same ways as for\nAuthors.\n\n\nName: Finding parts of the content in which a lot of bugs are\nintroduced and fixed\nDescription:\n\tWhen a Developer decides to change part of the content, it would be\ninteresting for them to know that many before them introduced bugs\nwhen working on that part of the content. Knowing this the Developer\nmight ask for all such buggy commits to try and learn from the\nmistakes made by others and prevent making the same mistake. A\nMaintainer might use this information to spend extra time reviewing a\ncommit from a 'bug prone' part of the content.\n\n\t\nName: Finding parts of the content a particular Contributor introduces\na lot of/almost no\nbugs to.\nDescription:\n\tWhen trying to decide whether to ask a specific Contributor to work\non part of the content it might be useful to not only know how active\nthey work on that part of the content, but also if they introduced a\nlot of bugs to that part, or perhaps fixed many. Similar to the more\ngeneral case, this can be split out between modifying content and\n'accepting' modifications. This information may be used to decide to\nask a Contributor to spend more time on a specific part of the content\nbefore sending in a commit for review.\n\n\t\nName: Finding how many bugs were introduced/fixed in a period of time\nDescription:\n\tAs bugs are recognized by their fixes, it is always possible to match\na bug to it's fix. Both commits have a time stamp and with those the\ntime between bug and fix can be calculated. Aggregating this data over\nall known bug(fixes) the amount of unfixed bugs may be found over a\nspecified period of time. For example, finding the amount of fixed\nbugs between two releases, or how many bugs were not fixed within one\nrelease cycle. This number might then be calculated over several time\nframes (say, each release), after which it is possible to track\n'content quality' throughout releases. If this information is then\ngraphed one can find extremes in this figure (for example, a release\ncycle in which a lot of bugs were fixed, or one that introduced many).\nKnowing this the Contributors may then determine the cause of such and\nlearn from that.\n\n\t\nName: Finding how much work a contributor has done over a period of time\nDescription:\n\tWhen working in a team in which everybody is expected to do\napproximately the same amount of work it is interesting to see how\nmuch work each Contributor actually does. This allows the team to\ndiscuss any extremes and attempt to handle these as to distribute the\nwork more evenly.\n\tWhen work is being done by a large group of people it is interesting\nto know the most active Contributors since these usually are the ones\nwith most knowledge on the content. The other way around, it is\npossible to determine if a specific Contributor is 'active enough' for\na specific task (such as mentoring).\n\n\t\nName: Finding whether a Contributor is mostly a Developer or a Bug-fixer\nDescription:\n\tTo all Contributors it is interesting to know if they spend most of\ntheir time fixing bugs, or contributing enhancements to the content.\nThis information could also be queried over a specific time frame, for\nexample 'weekends vs. workdays' or 'holidays vs. non-holidays'.\n\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"76685","messageId":"bd6139dc0805120238n1f990b4dwcd0e133ff146ed1d@mail.gmail.com","threadId":"13436","inReplyTo":"bd6139dc0805080851y2065bedfsf0f388cfd6d85929@mail.gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2008-05-12T09:38:18Z","receivedAt":"2008-05-12T09:38:18Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, May 8, 2008 at 5:51 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> Heya,\n>\n> I've been busy to write up some use cases for 'git statistics' (a new\n> command that I will be implementing this summer during Google Summer\n> of Code). For more details on my proposal please see\n> http://alturin.googlepages.com/gsoc2008 (a pdf of the use cases is\n> hosted there as well for those who prefer pdf). I would like to ask\n> for comments on the current use cases; is anything missing, or should\n> a particular use case be removed/merged? Please let me know.\n>\n> Thank you for your time.\n>\n>\n>\n> == Terminology ==\n>\n> There are four types of users: Maintainers, Developers, Bug-fixers,\n> and regular Users. The first three are all Contributors.\n>\n> Name: Maintainer (Contributor)\n> Description: The Maintainer reviews commits and branches from other\n> Contributors and decided which ones to integrate into a 'master'\n> branch.\n>\n> Name: Developer (Contributor)\n> Description: The Developer contributes enhancements to the project,\n> e.g. they add new content or improve existing content.\n>\n> Name: Bug-fixer (Contributor)\n> Description: The Bug-fixer locates 'bugs' (as something unwanted that\n> needs to be corrected) in the content and 'fixes' them.\n>\n> Name: User\n> Description: The User uses the content, be it in their daily work or\n> every now and then for a specific purpose.\n>\n>\n>\n> == Use cases ==\n>\n>\n> A model where other Contributors review commits is assumed in all use\n> cases. When referenced are made to a Contributor addressing another\n> Contributor to adjust their behavior as the result of data mined, it\n> should be kept in mind that the Contributor should foremost be the one\n> to do this. Using this information to, say, spend more time checking\n> one's own commits for bugs when working on a specific part of the\n> content on one's own accord is is often more effective then doing so\n> only after being asked. </disclaimer>? :P\n>\n>\n> Name: Finding a Contributor that is active in a specific bit of content.\n> Description:\n>        Whenever a Contributor needs to know about other Contributors that\n> are active in a specific part of the content they query git for this\n> information. This could be used to figure out whom to send a copy of a\n> commit (someone who has recently worked on the content a commit\n> modifies is likely to be interested in such a commit). This\n> information may be easily gathered with, say, git blame. Aggregating\n> it's output (in the background if need be to maintain speedy response\n> times), it is trivial to determine whether a Contributor has more\n> commits/lines of change than a predefined amount. The main difference\n> with git blame is that it's output is aggregated over the history of\n> the content, for a specific Contributor, whereas git blame only shows\n> the latest changes.\n>\n>\n> Name: Finding which commits touches the parts of the content that a\n> commit touches.\n> Description:\n>        There are several reasons that one might want to know which commit\n> touches the parts of the content that a commit touches. This may be\n> implemented similar to how git blame works only instead of 'stopping'\n> after having found the author of a line, the search continues up to a\n> certain date in the past.\n>\n>\n> Name: Integrating the found 'bug introducing' commit with the git\n> commit message system.\n> Description:\n>        When a Bug-fixer sends out a commit to fix a bug it might be useful\n> for them to find out where exactly the bug was introduced. Using the\n> 'which commit touched the content this commit touches' technique\n> optional candidates may be retrieved. After picking which of the found\n> commits caused the bug, this information may then automatically added\n> to the commit's description. This does not only allow the Bug-fixer to\n> make clear the origin of their commit, but also make it possible to\n> later unambiguously determine a bug/fix pair. Note that this is\n> automated, no user input is required to determine which commit caused\n> the bug, only the picking of 'cause' commits requires input from the\n> user.\n>\n>\n> Name: Finding the Author that introduce a lot of/almost no bugs to the content.\n> Description:\n>        Contributors might be interested to know which of the Developers\n> introduce a lot of bugs, or the contrary, which introduce almost no\n> bugs to the content. This information is highly relevant to the\n> Maintainer as they may now focus the time they spend on reviewing\n> commits on those that stem from Developers that turn out to often\n> introduce bugs. On the other hand, Developers that usually do not\n> introduce bugs need less reviewing time. While such information is\n> usually known to the experienced Maintainer (as they know their main\n> contributors well), it can be helpful to new maintainers, or as a\n> pointer that the opinion of the Maintainer about a specific Developer\n> needs to be adjusted. Bug-fixers on the other hand can use this\n> information to address the Developer that introduces most of the bugs\n> they fix, perhaps with advice on how to prevent future bugs from being\n> introduced.\n>\n>\n> Name: Finding the Contributor that accepted a lot of/almost no bugs\n> into the content.\n> Description:\n>        Similar to the finding Authors that write the bugs, there are other\n> Contributors that 'accept' the commit. Either passively, by not\n> commenting when the commit is sent out for review, or actively, by\n> 'acknowledging' (acked-by), 'signing off' (signed-off-by) or 'testing'\n> (tested-by) a commit. When actively doing so, this can later be\n> traced, this information can then be used in the same ways as for\n> Authors.\n>\n>\n> Name: Finding parts of the content in which a lot of bugs are\n> introduced and fixed\n> Description:\n>        When a Developer decides to change part of the content, it would be\n> interesting for them to know that many before them introduced bugs\n> when working on that part of the content. Knowing this the Developer\n> might ask for all such buggy commits to try and learn from the\n> mistakes made by others and prevent making the same mistake. A\n> Maintainer might use this information to spend extra time reviewing a\n> commit from a 'bug prone' part of the content.\n>\n>\n> Name: Finding parts of the content a particular Contributor introduces\n> a lot of/almost no\n> bugs to.\n> Description:\n>        When trying to decide whether to ask a specific Contributor to work\n> on part of the content it might be useful to not only know how active\n> they work on that part of the content, but also if they introduced a\n> lot of bugs to that part, or perhaps fixed many. Similar to the more\n> general case, this can be split out between modifying content and\n> 'accepting' modifications. This information may be used to decide to\n> ask a Contributor to spend more time on a specific part of the content\n> before sending in a commit for review.\n>\n>\n> Name: Finding how many bugs were introduced/fixed in a period of time\n> Description:\n>        As bugs are recognized by their fixes, it is always possible to match\n> a bug to it's fix. Both commits have a time stamp and with those the\n> time between bug and fix can be calculated. Aggregating this data over\n> all known bug(fixes) the amount of unfixed bugs may be found over a\n> specified period of time. For example, finding the amount of fixed\n> bugs between two releases, or how many bugs were not fixed within one\n> release cycle. This number might then be calculated over several time\n> frames (say, each release), after which it is possible to track\n> 'content quality' throughout releases. If this information is then\n> graphed one can find extremes in this figure (for example, a release\n> cycle in which a lot of bugs were fixed, or one that introduced many).\n> Knowing this the Contributors may then determine the cause of such and\n> learn from that.\n>\n>\n> Name: Finding how much work a contributor has done over a period of time\n> Description:\n>        When working in a team in which everybody is expected to do\n> approximately the same amount of work it is interesting to see how\n> much work each Contributor actually does. This allows the team to\n> discuss any extremes and attempt to handle these as to distribute the\n> work more evenly.\n>        When work is being done by a large group of people it is interesting\n> to know the most active Contributors since these usually are the ones\n> with most knowledge on the content. The other way around, it is\n> possible to determine if a specific Contributor is 'active enough' for\n> a specific task (such as mentoring).\n>\n>\n> Name: Finding whether a Contributor is mostly a Developer or a Bug-fixer\n> Description:\n>        To all Contributors it is interesting to know if they spend most of\n> their time fixing bugs, or contributing enhancements to the content.\n> This information could also be queried over a specific time frame, for\n> example 'weekends vs. workdays' or 'holidays vs. non-holidays'.\n\nHeya,\n\nI haven't had replies to this e-mail so far, did it get lost in the list noise?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"76693","messageId":"m3d4nr4ykr.fsf@localhost.localdomain","threadId":"13436","inReplyTo":"bd6139dc0805120238n1f990b4dwcd0e133ff146ed1d@mail.gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-12T10:16:56Z","receivedAt":"2008-05-12T10:16:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Sverre Rabbelier\" <srabbelier@gmail.com> writes:\n\n> On Thu, May 8, 2008 at 5:51 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> > Heya,\n> >\n> > I've been busy to write up some use cases for 'git statistics' (a new\n> > command that I will be implementing this summer during Google Summer\n> > of Code). For more details on my proposal please see\n> > http://alturin.googlepages.com/gsoc2008 (a pdf of the use cases is\n> > hosted there as well for those who prefer pdf). I would like to ask\n> > for comments on the current use cases; is anything missing, or should\n> > a particular use case be removed/merged? Please let me know.\n> \n> Heya,\n> \n> I haven't had replies to this e-mail so far, did it get lost in the\n> list noise?\n\nOne comment: did you take a look at 'owners.sh' script posted some\ntime ago by (IIRC) spearce to check who \"owns\" egit/jgit and relevant\ngit code?  This is one interesting, and useful, statistics.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"76694","messageId":"bd6139dc0805120319s5ad37867k392eff88616b689e@mail.gmail.com","threadId":"13436","inReplyTo":"m3d4nr4ykr.fsf@localhost.localdomain","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-05-12T10:19:25Z","receivedAt":"2008-05-12T10:19:25Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, May 12, 2008 at 12:16 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n> One comment: did you take a look at 'owners.sh' script posted some\n> time ago by (IIRC) spearce to check who \"owns\" egit/jgit and relevant\n> git code?  This is one interesting, and useful, statistics.\n\nAh, yes, I did see it, and something similar to that I intend to\ninclude. I reckon his script would fall under the \"Finding a\nContributor that is active in a specific bit of content\" use case.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"76695","messageId":"200805121319.37512.jnareb@gmail.com","threadId":"13436","inReplyTo":"bd6139dc0805120319s5ad37867k392eff88616b689e@mail.gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-12T11:19:20Z","receivedAt":"2008-05-12T11:19:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 12 May 2008 12:19, Sverre Rabbelier wrote:\n> On Mon, May 12, 2008 at 12:16 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n>>\n>> One comment: did you take a look at 'owners.sh' script posted some\n>> time ago by (IIRC) spearce to check who \"owns\" egit/jgit and relevant\n>> git code?  This is one interesting, and useful, statistics.\n\nFirst I have to admit that I haven't read your email carefully.\nOne note: why not provide HTML version in addition to PDF?\n\n> Ah, yes, I did see it, and something similar to that I intend to\n> include. I reckon his script would fall under the \"Finding a\n> Contributor that is active in a specific bit of content\" use case.\n\nI don't agree.\n\nThis is \"Finding the owner of the code\" (i.e. something like\nnon-existent 'git blame --summary') with the goal of \"Find who\nneeds to be contact about changing (or adding) license / relicensing\".\n\nThis is similar, but not exactly the same as \"Find maintainer of given\nsubsystem\", or \"Who is responsible for this part of code\".\n\n\nA few use cases I thought about (perhaps repeating what you have wrote,\nsee note above):\n\n* Maintainer: how close should I examine provided patch?\n* Contributor: who is maintainer of the code / whom should I contact\n  and send copy of a patch?\n* Bug-fixer: who is responsible about this part of code? Who might have\n  introduced the bug?\n* Contributor: what happened with my code?\n* Searching where to contribute: what are oldest part of code dealing\n  with error messages (find ancient code)?\n\nHTH\n-- \nJakub Narebski\nPoland\n"},{"id":"76697","messageId":"bd6139dc0805120449j874e4b8j21b90f79230e45a7@mail.gmail.com","threadId":"13436","inReplyTo":"200805121319.37512.jnareb@gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-05-12T11:49:18Z","receivedAt":"2008-05-12T11:49:18Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, May 12, 2008 at 1:19 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n>  One note: why not provide HTML version in addition to PDF?\n\nHTML version is now available too: http://alturin.googlepages.com/Use_cases.html\n\n>  This is \"Finding the owner of the code\" (i.e. something like\n>  non-existent 'git blame --summary') with the goal of \"Find who\n>  needs to be contact about changing (or adding) license / relicensing\".\n\nAh, it is a simple aggregation of 'git blame' then, you are right,\nthat is not the same as what I had in mind for the mentioned use case.\n\n>  This is similar, but not exactly the same as \"Find maintainer of given\n>  subsystem\", or \"Who is responsible for this part of code\".\n\nAgreed, since those should look back in history too.\n\n>  * Maintainer: how close should I examine provided patch?\n\nI'm not sure I understand what you mean with this, perhaps related to\n\"Name: Finding parts of the content in which a lot of bugs are\nintroduced and fixed\" (e.g., patches to bug prone areas should be\nexamined more closely).\n\n>  * Contributor: who is maintainer of the code / whom should I contact\n>   and send copy of a patch?\n\nI think this -is- the \"Finding a Contributor that is active in a\nspecific bit of content\" use case this time.\n\n>  * Bug-fixer: who is responsible about this part of code? Who might have\n>   introduced the bug?\n\nHow would you define 'responsible'? \"Having a lot of signed-off-by\nlines in that part of the content\" would seem like a candidate, but\nthe \"activity\" use case seems applicable again here.\n\n>  * Contributor: what happened with my code?\n\nDo you mean a \"track my code\" like feature? Showing the movement of a\nparticular piece of code through the code? (Displaying information\nlike \"moved from foo.c to bar.c in commit 0123456789abcd\"?)\n\n>  * Searching where to contribute: what are oldest part of code dealing\n>   with error messages (find ancient code)?\n\nIn other words, find the lines with the oldest modification time stamp\nfrom 'git blame'?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"76700","messageId":"200805121440.12836.jnareb@gmail.com","threadId":"13436","inReplyTo":"bd6139dc0805120449j874e4b8j21b90f79230e45a7@mail.gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-12T12:40:11Z","receivedAt":"2008-05-12T12:40:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sverre Rabbelier wrote:\n> On Mon, May 12, 2008 at 1:19 PM, Jakub Narebski <jnareb@gmail.com> wrote: \n\n> >  * Maintainer: how close should I examine provided patch?\n> \n> I'm not sure I understand what you mean with this, perhaps related to\n> \"Name: Finding parts of the content in which a lot of bugs are\n> introduced and fixed\" (e.g., patches to bug prone areas should be\n> examined more closely).\n\nThis is, IMHO, the most complex example (at least to do properly).\nIt begins with: does given author have code touching given subsystem\n(i.e. is it for him/her new contribution wrt. subsystem)? How many\ncommits he/she has affecting given subsystem? How often he/she rewrites\ncode? How many bugs were introduced?\n\nDetails I think need to be provided by maintainer...\n\n> >  * Contributor: what happened with my code?\n> \n> Do you mean a \"track my code\" like feature? Showing the movement of a\n> particular piece of code through the code? (Displaying information\n> like \"moved from foo.c to bar.c in commit 0123456789abcd\"?)\n\nI was thinking there about \"git blame --reverse\".\n \n> >  * Searching where to contribute: what are oldest part of code dealing\n> >   with error messages (find ancient code)?\n> \n> In other words, find the lines with the oldest modification time stamp\n> from 'git blame'?\n\nOr find the lines with oldest modification stamp with \"die\" or \"warn\",\nor find which messages are oldest, even if wrapper have changed.\n\n\nP.S. I wonder how hard to be to plug-in such SCM statistic system\ninto something like project management, see\n  \"Joel On Software: Evidence based scheduling\" (of programming tasks)\n  http://www.joelonsoftware.com/items/2007/10/26.html\n\n-- \nJakub Narebski\nPoland\n"},{"id":"76701","messageId":"bd6139dc0805120601k45ab762eq78c7d6a4927059f6@mail.gmail.com","threadId":"13436","inReplyTo":"200805121440.12836.jnareb@gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2008-05-12T13:01:14Z","receivedAt":"2008-05-12T13:01:14Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Mon, May 12, 2008 at 2:40 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n>  This is, IMHO, the most complex example (at least to do properly).\n>  It begins with: does given author have code touching given subsystem\n>  (i.e. is it for him/her new contribution wrt. subsystem)? How many\n>  commits he/she has affecting given subsystem? How often he/she rewrites\n>  code? How many bugs were introduced?\n\nAh, there is a lot more to this example than I thought. Perhaps this\ndata could all be shown and then, using some \"importance\" metric per\nitem a \"grade\" can be calculated?\n\n>  Details I think need to be provided by maintainer...\n>\n>\n>  > >  * Contributor: what happened with my code?\n>  >\n>  > Do you mean a \"track my code\" like feature? Showing the movement of a\n>  > particular piece of code through the code? (Displaying information\n>  > like \"moved from foo.c to bar.c in commit 0123456789abcd\"?)\n>\n>  I was thinking there about \"git blame --reverse\".\n>\n>\n>  > >  * Searching where to contribute: what are oldest part of code dealing\n>  > >   with error messages (find ancient code)?\n>  >\n>  > In other words, find the lines with the oldest modification time stamp\n>  > from 'git blame'?\n>\n>  Or find the lines with oldest modification stamp with \"die\" or \"warn\",\n>  or find which messages are oldest, even if wrapper have changed.\n>\n>\n>  P.S. I wonder how hard to be to plug-in such SCM statistic system\n>  into something like project management, see\n>   \"Joel On Software: Evidence based scheduling\" (of programming tasks)\n>   http://www.joelonsoftware.com/items/2007/10/26.html\n>\n>  --\n>  Jakub Narebski\n>  Poland\n>\n\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"76869","messageId":"200805131507.04912.jnareb@gmail.com","threadId":"13436","inReplyTo":"bd6139dc0805120604m349b1fbbr39c6dcb8d893e771@mail.gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-13T13:07:04Z","receivedAt":"2008-05-13T13:07:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 12 May 2008, Sverre Rabbelier wrote:\n> [Sorry, I hit 'send' instead of 'save']\n\nAnd now you apparently forgot to add git mailing list to receipients...\n\n> On Mon, May 12, 2008 at 2:40 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n>>  This is, IMHO, the most complex example (at least to do properly).\n>>  It begins with: does given author have code touching given subsystem\n>>  (i.e. is it for him/her new contribution wrt. subsystem)? How many\n>>  commits he/she has affecting given subsystem? How often he/she rewrites\n>>  code? How many bugs were introduced?\n> \n> Ah, there is a lot more to this example than I thought. Perhaps this\n> data could all be shown and then, using some \"importance\" metric per\n> item a \"grade\" can be calculated?\n\nWeighting different statistics, bayesian hypotesis/filtering, expert\nsystem, machine learning... I guess that would be quite a work to do\nit well.  Probably would require to calculate and adjust scoring of code\n(difficulity) and authors (skill), and matching them...\n\nThis is certainly in the \"wishlist\" scope.\n\n>>  Details I think need to be provided by maintainer...\n> \n> Do you mean Junio, or the user of the program?\n\nI mean that all I can provide is speculation.  I'm not, and never was\na maintainer of OSS project, and I don't know what criteria one use\n(perhaps unvoiced criteria) to decide whether given patch needs to be\nexamined more closely, or the cursory browsing should be enough.\n\n>>>>  * Contributor: what happened with my code?\n>>>\n>>> Do you mean a \"track my code\" like feature? Showing the movement of a\n>>> particular piece of code through the code? (Displaying information\n>>> like \"moved from foo.c to bar.c in commit 0123456789abcd\"?)\n>>\n>>  I was thinking there about \"git blame --reverse\".\n> \n> Do you mean, filter it's output for a specific user?\n\nI mean, given the code at given version, what happened to this code?\nFiltering \"git blame --reverse\" by user might be one way of solving it.\n\n>>>>  * Searching where to contribute: what are oldest part of code dealing\n>>>>   with error messages (find ancient code)?\n>>>>\n>> Or find the lines with oldest modification stamp with \"die\" or \"warn\",\n>> or find which messages are oldest, even if wrapper have changed.\n> \n> In that case, perhaps a regexp would be more suitable, to allow the\n> user to search for any specific line, not just \"die\" or \"warn\"?\n\nWhat I had in mind here, but didn't explain clear enough, was an\nextension to pickaxe search.  You want to find when current error\nmessage was created, even if the way of handling it (fprintf vs. die)\nchanged, or if code was indented, or was moved.\n\nOr find all error messages, in the order they were created, for example\nin git case to find ancient error messages and replace it by something\nmore user-friendly (or less selective about choosing friends ;-).\n\n>>  P.S. I wonder how hard to be to plug-in such SCM statistic system\n>>  into something like project management, see\n>>   \"Joel On Software: Evidence based scheduling\" (of programming tasks)\n>>   http://www.joelonsoftware.com/items/2007/10/26.html\n> \n> Interesting article, I think integrating statistics\n> (http://www.statsvn.org/ for example) can be a very powerful tool for\n> project management.\n\nYou meant http://git.koha.org/gitstat/, didn't you? ;-P\n\nSiriously, what I had in mind was to integrate author dates and commit\ndates into project management system scheduling.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"76871","messageId":"bd6139dc0805130637saf704e1v2ab67c99da3078c3@mail.gmail.com","threadId":"13436","inReplyTo":"200805131507.04912.jnareb@gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2008-05-13T13:37:32Z","receivedAt":"2008-05-13T13:37:32Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Tue, May 13, 2008 at 3:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n>  And now you apparently forgot to add git mailing list to receipients...\n\nI guess mailinglists are not my thing huh?\n\n>  > On Mon, May 12, 2008 at 2:40 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n>  > Ah, there is a lot more to this example than I thought. Perhaps this\n>  > data could all be shown and then, using some \"importance\" metric per\n>  > item a \"grade\" can be calculated?\n>\n>  Weighting different statistics, bayesian hypotesis/filtering, expert\n>  system, machine learning... I guess that would be quite a work to do\n>  it well.  Probably would require to calculate and adjust scoring of code\n>  (difficulity) and authors (skill), and matching them...\n>\n>  This is certainly in the \"wishlist\" scope.\n\nYeah, I think it would go in the 'c' of 'MoSCoW', but it could be very\nuseful when done right.\n\n>  >>  Details I think need to be provided by maintainer...\n>  >\n>  > Do you mean Junio, or the user of the program?\n>\n>  I mean that all I can provide is speculation.  I'm not, and never was\n>  a maintainer of OSS project, and I don't know what criteria one use\n>  (perhaps unvoiced criteria) to decide whether given patch needs to be\n>  examined more closely, or the cursory browsing should be enough.\n\nI reckon more input from actual maintainers would be needed then.\nJunio: aside from the original list with suggestions you provided,\ncould you shine your light as git maintainer on this?\n\n>  I mean, given the code at given version, what happened to this code?\n>  Filtering \"git blame --reverse\" by user might be one way of solving it.\n\nIt sounds like it would not be too hard to implement' maybe another\n'C' in 'MoSCoW' (or perhaps that first 'C' should be a 'W'...)\n\n>  What I had in mind here, but didn't explain clear enough, was an\n>  extension to pickaxe search.  You want to find when current error\n>  message was created, even if the way of handling it (fprintf vs. die)\n>  changed, or if code was indented, or was moved.\n\nI'm not familiar with pickaxe, what you suggest sounds like grepping\nthe content also throughout history?\n\n>  Or find all error messages, in the order they were created, for example\n>  in git case to find ancient error messages and replace it by something\n>  more user-friendly (or less selective about choosing friends ;-).\n\nI understand what you want, a search for specific content, from old to\nnew, stopping when you have a match?\n\n>  > Interesting article, I think integrating statistics\n>  > (http://www.statsvn.org/ for example) can be a very powerful tool for\n>  > project management.\n>\n>  You meant http://git.koha.org/gitstat/, didn't you? ;-P\n\nI used the former, never tried the latter :).\n\n>  Seriously, what I had in mind was to integrate author dates and commit\n>  dates into project management system scheduling.\n\nI'm not sure what gain that would bring though, as it can only provide\nend dates, not 'starting work now' timestamps...\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"76988","messageId":"200805142234.54600.jnareb@gmail.com","threadId":"13436","inReplyTo":"bd6139dc0805130637saf704e1v2ab67c99da3078c3@mail.gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-14T20:34:54Z","receivedAt":"2008-05-14T20:34:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 13 May 2008, Sverre Rabbelier wrote:\n> On Tue, May 13, 2008 at 3:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n\n[on helping maintainer decide how closely patch should be examined]\n\n>>  Weighting different statistics, bayesian hypotesis/filtering, expert\n>>  system, machine learning... I guess that would be quite a work to do\n>>  it well.  Probably would require to calculate and adjust scoring of code\n>>  (difficulity) and authors (skill), and matching them...\n>>\n>>  This is certainly in the \"wishlist\" scope.\n> \n> Yeah, I think it would go in the 'c' of 'MoSCoW', but it could be very\n> useful when done right.\n\nErrr... what do you mean by 'MoSCoW'?\n\n[here I think you cut a bit too much]\n>>\n>>  What I had in mind here, but didn't explain clear enough, was an\n>>  extension to pickaxe search.  You want to find when current error\n>>  message was created, even if the way of handling it (fprintf vs. die)\n>>  changed, or if code was indented, or was moved.\n> \n> I'm not familiar with pickaxe, what you suggest sounds like grepping\n> the content also throughout history?\n\nDocumentation/glossary.txt (linked from git(7), in \"Git User's Manual\")\n\n   pickaxe::\n        The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore\n        routines that help select changes that add or delete a given text\n        string. With the `--pickaxe-all` option, it can be used to view the full\n        <<def_changeset,changeset>> that introduced or removed, say, a\n        particular line of text. See linkgit:git-diff[1].\n\ngit-diff(1):\n\n       -S<string>\n              Look for differences that contain the change in <string>.\n\n       --pickaxe-all\n              When -S finds a change, show all the changes in that changeset, not\n              just the files that contain the change in <string>.\n\n       --pickaxe-regex\n              Make the <string> not a plain string but an extended POSIX regex to\n              match.\n\n>>  Or find all error messages, in the order they were created, for example\n>>  in git case to find ancient error messages and replace it by something\n>>  more user-friendly (or less selective about choosing friends ;-).\n> \n> I understand what you want, a search for specific content, from old to\n> new, stopping when you have a match?\n\nBut let me elaborate a bit. What I wanted in my example is for each\ndie(\"<message>\") and error(\"<message>\") to have commit and date where\n<message> was introduced (even if it was in fprintf(stderr, ...) then).\n\n>>  Seriously, what I had in mind was to integrate author dates and commit\n>>  dates into project management system scheduling.\n> \n> I'm not sure what gain that would bring though, as it can only provide\n> end dates, not 'starting work now' timestamps...\n\nWell, if you use patch management system such like StGit, it could\ntrace when patch was created, when was refreshed, when was temporarily\nabandoned (push, pop, float, new), ans when was finalized (commit or\nclean).\n\nBut that is also in the realm of vague ideas, not concrete applications.\n-- \nJakub Narebski\nPoland\n"},{"id":"77044","messageId":"482C2AD7.3070808@op5.se","threadId":"13436","inReplyTo":"200805142234.54600.jnareb@gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-05-15T12:21:43Z","receivedAt":"2008-05-15T12:21:43Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> On Tue, 13 May 2008, Sverre Rabbelier wrote:\n>> On Tue, May 13, 2008 at 3:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n> \n> [on helping maintainer decide how closely patch should be examined]\n> \n>>>  Weighting different statistics, bayesian hypotesis/filtering, expert\n>>>  system, machine learning... I guess that would be quite a work to do\n>>>  it well.  Probably would require to calculate and adjust scoring of code\n>>>  (difficulity) and authors (skill), and matching them...\n>>>\n>>>  This is certainly in the \"wishlist\" scope.\n>> Yeah, I think it would go in the 'c' of 'MoSCoW', but it could be very\n>> useful when done right.\n> \n> Errr... what do you mean by 'MoSCoW'?\n> \n\nMust have\nShould have\nCould have\nWon't have\n\nIt's a priority scheme used in agile development techniques, where\ndevelopers, customers and users work close together. The customer\ndecides \"must have this, or we scrap this project\", \"should have this,\nor users will be unhappy\", \"could have this, many would appreciate it\"\nand \"won't have this, it's too expensive to develop\" after the devs\nhave estimated the time required to develop the individual components.\n\nAgile development is usually used to go under-feature instead of\nover-budget. Since opensource projects are more driven by whatever\npassing-by developers happen to find interesting (or annoying) at the\nmoment (nearly as predictable as Brownian motion), agile development\ntechniques are very rarely used successfully to develop oss in\nanything but extremely tight communities.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"77163","messageId":"7vlk29er1w.fsf@gitster.siamese.dyndns.org","threadId":"13436","inReplyTo":"bd6139dc0805130637saf704e1v2ab67c99da3078c3@mail.gmail.com","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-17T00:02:19Z","receivedAt":"2008-05-17T00:02:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Rabbelier\" <srabbelier@gmail.com> writes:\n\n>>  >>  Details I think need to be provided by maintainer...\n>>  >\n>>  > Do you mean Junio, or the user of the program?\n>>\n>>  I mean that all I can provide is speculation.  I'm not, and never was\n>>  a maintainer of OSS project, and I don't know what criteria one use\n>>  (perhaps unvoiced criteria) to decide whether given patch needs to be\n>>  examined more closely, or the cursory browsing should be enough.\n>\n> I reckon more input from actual maintainers would be needed then.\n> Junio: aside from the original list with suggestions you provided,\n> could you shine your light as git maintainer on this?\n\nA cursory browsing is enough only when you trust the contributor well.\nFor example, I read patches from Nico to code around the pack generation\nonly once or at most twice before I apply them, and the same thing can be\nsaid about git-svn patches from or acked-by Eric.  These come mostly from\nthe fact that (1) I know they know the area a lot better than myself do,\nand more importantly that (2) I know they care deeply about the subsystem\nthey are modifying, and they have good taste.\n\nProject maintainers and old timers become familiar with habits, strengths\nand weaknesses of known contributors over time, and that is the source of\nsuch trust.\n\nA clever enough automated way may be able to identify links between the\ncontributors and the areas they are familiar with, and using such a\nmechanism people might be able to decide that a patch falls into category\n(1) above.  I am not sure if any automated way could ever decide if a\npatch falls into category (2) above, though.\n"},{"id":"77214","messageId":"bd6139dc0805171801q1c07f902p1882f65a77345d71@mail.gmail.com","threadId":"13436","inReplyTo":"7vlk29er1w.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2008-05-18T01:01:53Z","receivedAt":"2008-05-18T01:01:53Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"[And once more with 'reply to all' instead. Wouldn't it be nice if\ngmail had an 'auto-reply-to-all' feature...]\n\nOn Sat, May 17, 2008 at 2:02 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> A cursory browsing is enough only when you trust the contributor well.\n> For example, I read patches from Nico to code around the pack generation\n> only once or at most twice before I apply them, and the same thing can be\n> said about git-svn patches from or acked-by Eric.  These come mostly from\n> the fact that (1) I know they know the area a lot better than myself do,\n> and more importantly that (2) I know they care deeply about the subsystem\n> they are modifying, and they have good taste.\n\nThis makes sense, patches only get a 'cursory browsing' when they come\nfrom a trusted author, which is defined mostly by how active and how\n'good' they are in the area they modify.\n\n> Project maintainers and old timers become familiar with habits, strengths\n> and weaknesses of known contributors over time, and that is the source of\n> such trust.\n\nThis could only partially be done by an algorithm, while git excels in\nthe 'over time' part, the definition of 'habits, strengths and\nweaknesses' is harder to make.\n\n> A clever enough automated way may be able to identify links between the\n> contributors and the areas they are familiar with, and using such a\n> mechanism people might be able to decide that a patch falls into category\n> (1) above.  I am not sure if any automated way could ever decide if a\n> patch falls into category (2) above, though.\n\nYes, your solution in determining patches from (1) is in the same\ndirection of what I have been thinking on myself. I don't think it is\npossible to determine (2) without having access to the review system\n(in git's case, the mailing list). When the review system would become\npart of the analysis it could provide information on what improvements\nhad to be made to a commit before it was accepted. If 'style\nimprovements' would be marked in such a system then people with 'good\ntaste' are people whose commits do not often need 'style\nimprovements'. Alas, implementing something like that would be beyond\nthe scope of 1 GSoC. Ah well, 't is a nice dream about to implement at\na later time perhaps. (Although such would be more suited in a team\ncollaboration suite than in a [D]VCS).\n\n\n--\nCheers,\n\nSverre Rabbelier\n"},{"id":"77400","messageId":"7vprrf4lar.fsf@gitster.siamese.dyndns.org","threadId":"13436","inReplyTo":"7vlk29er1w.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-21T17:30:20Z","receivedAt":"2008-05-21T17:30:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> \"Sverre Rabbelier\" <srabbelier@gmail.com> writes:\n>\n>>>  >>  Details I think need to be provided by maintainer...\n>>>  >\n>>>  > Do you mean Junio, or the user of the program?\n>>>\n>>>  I mean that all I can provide is speculation.  I'm not, and never was\n>>>  a maintainer of OSS project, and I don't know what criteria one use\n>>>  (perhaps unvoiced criteria) to decide whether given patch needs to be\n>>>  examined more closely, or the cursory browsing should be enough.\n>>\n>> I reckon more input from actual maintainers would be needed then.\n>> Junio: aside from the original list with suggestions you provided,\n>> could you shine your light as git maintainer on this?\n> ...\n> Project maintainers and old timers become familiar with habits, strengths\n> and weaknesses of known contributors over time, and that is the source of\n> such trust.\n\nI just realized another thing about \"the source of trust\".  The\n\"statistics\" would count _only_ what gets accepted, but maintainers and\nlist participants have much richer set of datapoints to judge the\nstrengths and weaknesses of contributors --- rejects.\n\nAn early round of contribution from somebody needs deeper review if the\ncontributor has a history of taking many rounds of refinements to get a\nrather trivial change into an acceptable shape.  IOW, over time people can\nlearn who are meticulous and who are careless from rejection counts, which\nis not recorded in the committed history.\n"},{"id":"77424","messageId":"bd6139dc0805211352r264e61aeva196dd5f3c0ff1ec@mail.gmail.com","threadId":"13436","inReplyTo":"7vprrf4lar.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Use cases for 'git statistics'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2008-05-21T20:52:16Z","receivedAt":"2008-05-21T20:52:16Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Wed, May 21, 2008 at 7:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n\n> I just realized another thing about \"the source of trust\".  The\n> \"statistics\" would count _only_ what gets accepted, but maintainers and\n> list participants have much richer set of datapoints to judge the\n> strengths and weaknesses of contributors --- rejects.\n\nI think I know where this is coming from and what you say makes sense.\n\n> An early round of contribution from somebody needs deeper review if the\n> contributor has a history of taking many rounds of refinements to get a\n> rather trivial change into an acceptable shape.  IOW, over time people can\n> learn who are meticulous and who are careless from rejection counts, which\n> is not recorded in the committed history.\n\nYup, in order to gather that kind of data a more elaborate tool (one\nthat is integrated with a review tool like Rietveld or such) together\nwith the VCS would be required. I'm confident that this project will\nresult in useful statistics. Perhaps they will not be enough to\ndetermine which patches to let in and which ones to reject without\nhuman interference (I'm actually quite sure that won't happen), but I\ndo think other useful statistics may be gathered and used\nnevertheless.\n\n-- \nCheers,\n\nSverre Rabbelier\n"}]}