| additional context required |
LOC changed is meaningless without context - some of those lines could have just been style changes. In this case it was just moving things around. |
| additional context required |
LOC does not indicate the risk or level of improvement. If it is the LOC for a central source file that is critical to the project and has a large area of effect then its useful. |
| additional context required |
translation files usually have this sort of characteristics. creation of large JSON files |
| additional context required |
Its doesnt telling anything about issue |
| additional context required |
Pull request can be very different just like the people creating them. I think there are too many non deterministic factors in order to have reliable information from these numbers if the pull request is typical and/or difficult. |
| churn is an important metric |
Churn can be useful for detecting areas worth refactoring, but I dont know what the value is in the information about the author. |
| churn is an important metric |
Churn is a useful metric. |
| churn is an important metric |
It is useful because it can specify the amount the code that is modified, and might even help spot the problem if anything goes wrong in the future. |
| code change that only affects documentation is not useful |
Raw numbers arent useful! I need to see them in context. Adding 100 lines of documentation probably doesnt need as much attention as adding 100 New functions. |
| code change that only affects documentation is not useful |
Theres not much practical use for knowing this information. Its just an unusual change to some docs |
| code change that only affects documentation is not useful |
This is a change to meeting notes stored on the website |
| code change that only affects documentation is not useful |
this PR is not typical because its code formatting change only; not including any functional changes so its not difficult |
| code change that only affects documentation is not useful |
This commit was all about improving documentation, not making any real code changes, so we expect the LOC stats to be very different. |
| code change that only affects documentation is not useful |
It is a change in text. Not code. So there are no changes. |
| code change that only affects documentation is not useful |
Its all in the documentation not the code |
| code change that only affects documentation is not useful |
The issue is not typical becasue it was a minor documentation url fix, not a code change. |
| code change that only affects documentation is not useful |
A really large commit is definitely unusual (and annoying). In this case, though, its only a whitespace change, which might be something you can check for. |
| code change that only affects documentation is not useful |
Commits to this file (requirements.txt) can sit a few days before being merged. |
| commits are outliers because they were auto-generated |
Mostly small config changes in Xcode generated files |
| commits are outliers because they were auto-generated |
Mostly Xcode-generated config files |
| commits are outliers because they were auto-generated |
its a commit made by an automated system. Not interested in getting statistics for these events. |
| commits are outliers because they were auto-generated |
This is just .gitignore |
| didn't answer the question on why it's (not) useful |
All metrics are relevant this time |
| didn't answer the question on why it's (not) useful |
Because it is wrong. That pull request has a lot more than 2 comments, and we dont average 0.0 comments per pull request. |
| didn't answer the question on why it's (not) useful |
Deleting code is always good, but need to understand why. |
| didn't answer the question on why it's (not) useful |
Duplicate facts: days between open and closed for merge status true , days between open and merged |
| didn't answer the question on why it's (not) useful |
How are any of these useful? It looks like youre generating random Top Trumps without having spoken to any programmers about their utility. |
| didn't answer the question on why it's (not) useful |
I believe there is some duplication in these statements. Other than that this is useful info. |
| didn't answer the question on why it's (not) useful |
I did not recognize features in Github such as Label and Assignee. |
| didn't answer the question on why it's (not) useful |
I didnt understand it |
| didn't answer the question on why it's (not) useful |
I dont care if these numbers |
| didn't answer the question on why it's (not) useful |
I dont know what you are trying to say. |
| didn't answer the question on why it's (not) useful |
I dont really understand what that means. |
| didn't answer the question on why it's (not) useful |
I dont think this is useful. |
| didn't answer the question on why it's (not) useful |
I dont understand what it means... values between 3.0 and 3.0 with a median of 3.0. seems like bad statistics |
| didn't answer the question on why it's (not) useful |
Im not sure what this statement means. |
| didn't answer the question on why it's (not) useful |
Im not sure your stats for number of code review comments are working quite right: Most pull requests with these characteristics have values between 0.0 and 0.0 with a median of 0.0. for all of these seems wrong - we do comment on pull requests |
| didn't answer the question on why it's (not) useful |
Its just not useful at all |
| didn't answer the question on why it's (not) useful |
Just funny statistic |
| didn't answer the question on why it's (not) useful |
no |
| didn't answer the question on why it's (not) useful |
No |
| didn't answer the question on why it's (not) useful |
No |
| didn't answer the question on why it's (not) useful |
none of those is usefull |
| didn't answer the question on why it's (not) useful |
None useful. |
| didn't answer the question on why it's (not) useful |
None useful. |
| didn't answer the question on why it's (not) useful |
None useful. |
| didn't answer the question on why it's (not) useful |
Not useful |
| didn't answer the question on why it's (not) useful |
Not Useful |
| didn't answer the question on why it's (not) useful |
Not useful |
| didn't answer the question on why it's (not) useful |
Not useful |
| didn't answer the question on why it's (not) useful |
Not useful |
| didn't answer the question on why it's (not) useful |
not useful info |
| didn't answer the question on why it's (not) useful |
not useful, imho |
| didn't answer the question on why it's (not) useful |
Typo error |
| didn't answer the question on why it's (not) useful |
Useful |
| didn't answer the question on why it's (not) useful |
Useful |
| didn't answer the question on why it's (not) useful |
yes |
| didn't answer the question on why it's (not) useful |
Yes |
| didn't answer the question on why it's (not) useful |
it doesnt match, there are no 986 characters in the body |
| didn't answer the question on why it's (not) useful |
Maybe, some files are not touch almost ever so its hard to judge. |
| didn't answer the question on why it's (not) useful |
meh, this is actually a fairly small paste. |
| didn't answer the question on why it's (not) useful |
Most pull requests are reviewed and merged more quickly. Not sure why this one was different. |
| didn't answer the question on why it's (not) useful |
No new bugs reported/fixed - no need for a new release. |
| didn't answer the question on why it's (not) useful |
none of it tells me anything very useful to me. |
| didn't answer the question on why it's (not) useful |
none of the is useful |
| didn't answer the question on why it's (not) useful |
See above. |
| didn't answer the question on why it's (not) useful |
So long term task |
| didn't answer the question on why it's (not) useful |
This is a typical changelog. |
| didn't answer the question on why it's (not) useful |
What an unfathomable question! Did you not test this survey with native English speakers? Ive no idea what information youre trying to convey. |
| didn't answer the question on why it's (not) useful |
What the heck does this even mean? |
| didn't answer the question on why it's (not) useful |
What the value? |
| didn't answer the question on why it's (not) useful |
Your statements arme mathematically right, but People Need Clear statements and no additional Math to debug. |
| didn't answer the question on why it's (not) useful |
I dont think its unusual to have add a file, or have a parent-commit. (Prehaps these fields havent yet been populated in the comparison database?) |
| didn't answer the question on why it's (not) useful |
It doesnt seem unusual to me, so the information isnt useful in this case |
| didn't answer the question on why it's (not) useful |
None of the options above represent the actual situation :) The number of comments is different and can vary. There is no defined pattern. |
| didn't answer the question on why it's (not) useful |
None of these statements reflect anything about how typical/unusual this commit was |
| didn't answer the question on why it's (not) useful |
Not sure what it would be illustrative of. |
| didn't answer the question on why it's (not) useful |
Not sure what number of master branch commits means, especially in relation to an issue. |
| didn't answer the question on why it's (not) useful |
Not useful as values provided doesnt seem to be ok... |
| didn't answer the question on why it's (not) useful |
Nothing too useful here, a rather usual issue |
| didn't answer the question on why it's (not) useful |
owner has a small number of pull requests on this project, I dont think you can really make much of a judgement on what is unusual |
| didn't answer the question on why it's (not) useful |
Same as the obove. So I am not really sure yet what useful is meant to be in this context. Useful in which way? |
| didn't answer the question on why it's (not) useful |
The metric needs more explanation - days between commits - is that for this file, the repo as a whole, from that particular developer or what? Without knowing exactly what it means, it isnt a useful thing. |
| didn't answer the question on why it's (not) useful |
So, because the owner tehnick isnt very active, but now that he does something, this is an outlier? He didnt do anything interesting in this pull request. |
| didn't answer the question on why it's (not) useful |
This is a pretty usually PR in that several code standard issues needed to be addressed. Identifying those as frequent would potentially be helpful to avoiding them in the future. Your metrics are skewed because so many commits have 0 reviews/comm |
| didn't answer the question on why it's (not) useful |
Would be a useful measure as to who is responsible. |
| didn't answer the question on why it's (not) useful |
Raise awareness for potential issues |
| didn't answer the question on why it's (not) useful |
Considering the history of this project, none of these numbers indicate anything useful about the code being merged; also merge status false is interesting, considering that the code was added in https://github.com/jp9000/obs-studio/commit/f6a940c |
| difference too small to be useful |
0.4 days between open and merged/closed is normal |
| difference too small to be useful |
1 commit to fix a bug is normal |
| difference too small to be useful |
1 instead of true isnt so unusual or interesting. |
| difference too small to be useful |
A value of 1 is very normal because we have a policy to squash rebase before merging. It only looks odd compared to the zeros which are due to many of the issues I put in not getting prioritized. |
| difference too small to be useful |
Difference between 1 and 2 seems trivial, not a true outlier |
| difference too small to be useful |
Generally it would be useful, but in this case its a difference of 1. Insignificant. |
| difference too small to be useful |
I dont personally think the number of lines deleted for a user matters if its relatively small. |
| difference too small to be useful |
Were introducing the use of labels. An increase of 1 label is just categorizing, not interesting. |
| difference too small to be useful |
None of this information is particularly surprising. Adding 1 file is a normal occurance and, in the context of our project, not modifying .scss files for a long time is normal. |
| explanation of outlier rather than information on usefulness |
pull requests like this are nothing more than the committers preferred workflow - fork the main repository to develop a feature/fix, implement, PR to officially commit the change |
| explanation of outlier rather than information on usefulness |
A false positive Fall. I wrote the Code and Cleaned it Up here. |
| explanation of outlier rather than information on usefulness |
A new file was added, that is something not too common for a mature project. |
| explanation of outlier rather than information on usefulness |
A refactor is basically being difficult. |
| explanation of outlier rather than information on usefulness |
A strange issue which only occurs onder some specific configurations. I dont think this implies anything about the general health of the project. |
| explanation of outlier rather than information on usefulness |
Big contributor to project |
| explanation of outlier rather than information on usefulness |
Commits to this file (requirements.txt) are normally < 2 LOC |
| explanation of outlier rather than information on usefulness |
Don?t think any of this is useful. There are plenty of config files that doesn?t often get updated. |
| explanation of outlier rather than information on usefulness |
Just a comment update |
| explanation of outlier rather than information on usefulness |
Most commits with such characteristics have zero values. |
| explanation of outlier rather than information on usefulness |
Spread out team means commit times can vary. |
| explanation of outlier rather than information on usefulness |
The information is mostly stack traces |
| explanation of outlier rather than information on usefulness |
This is a merge commit nothing more |
| explanation of outlier rather than information on usefulness |
This is my commit, and i just like leaving large elaborate commit messages :). |
| explanation of outlier rather than information on usefulness |
This repo uses labels inconsistently (most issues do not have any labels) |
| explanation of outlier rather than information on usefulness |
this was a software library upgrade |
| explanation of outlier rather than information on usefulness |
We dont use labels very consistently anyway |
| explanation of outlier rather than information on usefulness |
We implemented an issue template that made for longer issues. |
| explanation of outlier rather than information on usefulness |
Shows that the maintainers, for some reason, did not respond to this commit quickly. |
| explanation of outlier rather than information on usefulness |
Shows the speed of the project. |
| explanation of outlier rather than information on usefulness |
There is a commit addressing the issue (61609a934439ec7b41ea45f3ddd2d8588a9f7031), but its not directly linked into the ticket |
| explanation of outlier rather than information on usefulness |
this is not our main project, so its OK for us to have sparse commits |
| explanation of outlier rather than information on usefulness |
This issue contains an error message in its body, but that doesnt necessarily indicate a harder issue. |
| explanation of outlier rather than information on usefulness |
This pull reqeust is unusual in that it didnt target the master branch (and was quickly superseded by one targeting master that also included other changes). |
| explanation of outlier rather than information on usefulness |
This seems like a minor issue that someone forgot to close after it was fixed with a config change. |
| explanation of outlier rather than information on usefulness |
This was a fairly major improvement so its not surprising that its an outlier compared to typical small patches. |
| explanation of outlier rather than information on usefulness |
This was a revert operation, and thats whats interesting about it - but the rest doesnt seem particularly abnormal to me. |
| explanation of outlier rather than information on usefulness |
This was an edge case bug; no-one else cared so I had to figure out a solution myself. I dont know why it would be relevant that most other issues dont require commits. I guess most issues are questions/duplicates then? |
| explanation of outlier rather than information on usefulness |
usually the changes dont look like that, the data in this file is special though. |
| explanation of outlier rather than information on usefulness |
Not useful - I suspect the statistics are biased by the fact that stumpwm was only recently added to github and previously patches were submitted by mailing list |
| explanation of outlier rather than information on usefulness |
Thats a fairly typical package addition commit. |
| explanation of outlier rather than information on usefulness |
The body length is because of multiple examples. Some issues only require one line to showcase the error, some more. |
| explanation of outlier rather than information on usefulness |
The body length is not unusually long for a descriptive issue. |
| explanation of outlier rather than information on usefulness |
The PR in question is a regression-fixing PR by the same author who introduced the regression. The long merge time is most likely because of my vacation around that time. |
| explanation of outlier rather than information on usefulness |
The project doesnt seem to assign issues to people that often. |
| explanation of outlier rather than information on usefulness |
It was a really very very minor change the changes made in the code dont harm it any manner, so I personally feel that it need to be focussed on. |
| explanation of outlier rather than information on usefulness |
It was just a small improvement to run samples |
| explanation of outlier rather than information on usefulness |
Its a good commit, I dont need to know any more than that |
| explanation of outlier rather than information on usefulness |
Its a merge commit. Depending on the project workflow, these shouldnt hold any significant meaning. |
| explanation of outlier rather than information on usefulness |
Its an outlier because of the code it touches. (Typical commits for this project only touch the .mk files.) |
| explanation of outlier rather than information on usefulness |
Its interesting, but the project was just being ported over, so its not like alerts for a project at that stage are particularly useful. |
| explanation of outlier rather than information on usefulness |
large formatting changes with little content changes will make the history of the file hard to follow |
| explanation of outlier rather than information on usefulness |
the information is not useful but the commit is typical because this commit 7efc40016ad81e07d365c33c72f8d4bc44d6a399 include functional changes and unittests, but not very difficult because it refers one file (and its unit test) change only |
| explanation of outlier rather than information on usefulness |
The interesting part is that this commit imports a third party library, rather than referencing a remote URL for it. |
| explanation of outlier rather than information on usefulness |
The issue body contains build logs which made the length much higher than the median. |
| explanation of outlier rather than information on usefulness |
There was a PR open where discussion about not moving forward happened. It just didnt make it back to the original issue. |
| explanation of outlier rather than information on usefulness |
This commit is part of a series of unit tests that got introduced by Flamefire in order to increase the overall test coverage (by more than 15%!) - theres a lot of work attached to it with not that much immediate benefit |
| explanation of outlier rather than information on usefulness |
None of this was helpful, the PR was difficult due to its content being in a rarely-changed area and involved a discussion about compiler versions |
| explanation of outlier rather than information on usefulness |
Number of days between commits is not an interesting signal in this repo. Number of LOC modified is as expected for commits like this which add a new page to the dashboard. |
| explanation of outlier rather than information on usefulness |
Submodule updates are quite common and a pain and it might be worth noting which submodules are updated infrequently (and whether they ought to be updated more often) |
| explanation of outlier rather than information on usefulness |
Such issues are hard to reproduce. Sometimes only remote access to users machine could help. |
| explanation of outlier rather than information on usefulness |
The body length is an outlier because of the stack trace, which is actually something we typically receive with bug reports but usually with a link to the stack trace instead of pasting it in the issue body |
| explanation of outlier rather than information on usefulness |
The description for this is long because the author describes the bug and wants to hold back merging the changes into master because the changes would break the saved games of users, and he has more changes like this in the pipeline that would also |
| explanation of outlier rather than information on usefulness |
The first one shows a developers recent trend. I dont understand what the second is for. |
| explanation of outlier rather than information on usefulness |
The information I checked indicates its an issue that had some discussion to come to be closed. Reading over the history its because the proposed solution had conflicts with the intended behavior the submitter (me) didnt know ahead of time. |
| explanation of outlier rather than information on usefulness |
This information does nto tell me why this commit is unusual - it is removing build server configuration, which is updated/changed rarely. |
| explanation of outlier rather than information on usefulness |
None of this was useful - the ticket was closed because it was transferred, not because it was actually resolved. |
| explanation of outlier rather than information on usefulness |
For this particular PR I deleted old files that were never used but created when the application skeleton was created. This PR is generally a bad example to run statistics against, as it is not a normal PR. |
| explanation of outlier rather than information on usefulness |
Doesnt matter that it might be an outlier, it is still a necessary pull request |
| explanation of outlier rather than information on usefulness |
It indicates a refactor. |
| explanation of outlier rather than information on usefulness |
These all indicate a big change or a change to something that has not been altered in a while. |
| explanation of outlier rather than information on usefulness |
This was a bigger pull request which required a bit of back and forth, to get to the desired result. |
| explanation of outlier rather than information on usefulness |
Again, being a community website with blog posts commits will be sporatic (only when something worth saying comes up) and have many contributors, meaning rare commits/commit sizes are not a concern. |
| explanation of outlier rather than information on usefulness |
Again: that part of the project is in maintenance mode, so low activity is expected. This committer is an intern and was away at school for four months, making a four-month delay between commits actually show a high level of activity. |
| explanation of outlier rather than information on usefulness |
Here you actually manage to detect some unusual behaviour. However I am not sure if it matters, since sometimes things are outside the normal distribution for valid reasons. |
| explanation of outlier rather than information on usefulness |
This is just a weird PR. The feature was eventually done in a different series of pull requests |
| explanation of outlier rather than information on usefulness |
This is a weird commit mainly because it?s introducing a new way of doing stuff. None of your metrics are really capturing that. |
| explanation of outlier rather than information on usefulness |
This is actually a bad commit which includes a merge conflict and all the other changes are small. |
| explanation of outlier rather than information on usefulness |
This was a tough issue; it was an edge use case others didnt care for, so I had to delve into the internals of their compiler logic myself. I didnt know enough of what I was doing, and I guess they were unsure about it as well -- and shortly after |
| explanation of outlier rather than information on usefulness |
This one is manually merged and thus having closed status. |
| explanation of outlier rather than information on usefulness |
just a misuse (arguably) of github issue tracker to brainstorm features for lack of a better project management tool |
| explanation of outlier rather than information on usefulness |
The number of people involved in the review explains the length of time between merge status. |
| explanation of outlier rather than information on usefulness |
First external user contribution to this project - usually it takes longer for new developers who have not been working on this project before to get into everything, and there is more need for communication with the other team members |
| explanation of outlier rather than information on usefulness |
Its not useful, as this particular commit adds a minor API enhnacement that is of low impact and low relevance to the overall project |
| explanation of outlier rather than information on usefulness |
Its not useful, as this particular commit adds a minor API enhnacement that is of low impact and low relevance to the overall project |
| explanation of outlier rather than information on usefulness |
Quite often Jos� will take the idea of a pull request and merge a different change which addresses the problem, so the lack of merge isnt a big deal to me. |
| explanation of outlier rather than information on usefulness |
It took Time for all to Test the complex improvement. |
| explanation of outlier rather than information on usefulness |
This commit is just a merge, so the number of LOC is fairly irrelevant. |
| gap in commit activity for external reasons |
I dont think this info is useful. Team was busy those days in some other stuff (might be a google.io). |
| gap in commit activity for external reasons |
I think Jose Valim just took a few days off, not sure if it is a useful information. |
| gap in commit activity for external reasons |
In this particular case, this project is mostly in maintenance mode and this committer has tasks tracked not in github. Long periods between commits are normal for this project, and long periods between commits for that committer might be indicative |
| gap in commit activity for external reasons |
Generally the space between commits is not related to the code, but something else. i.e. Discussion, waiting on feedback, commiters schedule and outside responsibilities, etc. |
| gap in commit activity for external reasons |
Happens more often due to delays Clausen by vacation, business duties,.... |
| gap in commit activity for external reasons |
I think that a couple of days between commits is not a big deal, could be travelling, illness, any number of things. If someone who committed daily vanished for six months and then re-appeared that would be more interesting. |
| gap in commit activity for external reasons |
This particular project is updated less frequently than some of our other projects, so its not really uncommon to have such a long span of time between contributions. |
| gap in commit activity for external reasons |
The only problem with this kind of metric at medium lengths of time like a few weeks is that open source projects are side-time for most of us. |
| information not useful in a practical sense |
Because number of master branch commits for assignee doesnt improve code quality |
| information not useful in a practical sense |
Because those numbers wont provide actionable data |
| information not useful in a practical sense |
Dont know what to do with that information |
| information not useful in a practical sense |
Dont see much practical use for it |
| information not useful in a practical sense |
Dont see much practical use for it |
| information not useful in a practical sense |
I am not sure of the utility of those numbers |
| information not useful in a practical sense |
I dont know what I would do with this information. |
| information not useful in a practical sense |
I dont know what I would do with this information. Additionally the wording is a little hard to parse. |
| information not useful in a practical sense |
I dont know what to do with this info |
| information not useful in a practical sense |
I dont know what to do with this info |
| information not useful in a practical sense |
I dont know what to do with this info |
| information not useful in a practical sense |
I dont know what to do with this info |
| information not useful in a practical sense |
I dont see the point |
| information not useful in a practical sense |
Neither tell me anything relevant to my usual concerns as a maintainer |
| information not useful in a practical sense |
This is a perfunctory commit. Im not aware of circumstances in which any of these statistics would be useful to know. |
| information not useful in a practical sense |
I dont understand what actions Id take as a result of this data |
| information not useful in a practical sense |
It does not give immediate Information about the real issue behind your metrics. |
| information not useful in a practical sense |
it was an outlier here, but Id respond by asking what one would try to infer from this. in this case they obviously just forgot to close the issue after resolving. |
| information not useful in a practical sense |
Its interesting but not useful as a contributor |
| information not useful in a practical sense |
personally I do not consider those mere numbers useful. A completely licit pull request can easily have them out of average. |
| information not useful in a practical sense |
This information would not have helped triage the issue. |
| information not useful in a practical sense |
This is the first thing I actually understand. You have detected an unusual amounts of deletes in md files. Still not very useful however. |
| information not useful in a practical sense |
Again, interesting stats about Daniels contributions but not particularly useful as a contributor |
| information not useful in a practical sense |
Again, interesting stats about Didier contributions but not particularly useful as a contributor |
| information not useful in a practical sense |
not useful. I have no interest in how many commits it took to get a job done. |
| information not useful in a practical sense |
Dont think metrics on individual commits are especially useful (and especially on merge commits). |
| insights allow for reflection/gamification |
Not sure. Maybe the typical number of commits a user usually has would be useful for encouraging developers to commit more often. |
| insights allow for reflection/gamification |
The code review is always useful and make the contributor know what should they do to contribute more. |
| insights allow for reflection/gamification |
I realized that code review comments rarely happened. |
| insights allow for reflection/gamification |
Some files should be updated but can be easily forgotten about (CHANGELOGs, README, LICENSE) |
| insights allow for reflection/gamification |
It would allow better reflection on the management of the project. |
| knowing about comments is not useful |
Comments are not really a good indicator of much in and of them selves. |
| knowing about comments is not useful |
Im not sure why I would care to analyze the distribution of comments on closed pull requests. |
| knowing about comments is useful |
I would consider this information useful in this terms: having a code review comment means that the pull request was careful checked, so it is less likely that this can cause problems in the future |
| knowing about comments is useful |
Number of code review comments is probably more helpful by itself than by author/assignee/label. |
| knowing about comments is useful |
The information can show that this issue is long-term and mainly discussion-based. |
| knowing about comments is useful |
High number of comments indicates disagreements or a commit of bad quality. Maybe both. |
| knowing about comments is useful |
These indicate a lot of discussion around the issue, and discussion after it was merged, both of which could indicate a conflict or disagreement. The length of the initial commit message is not relevant since we use a template that makes them consis |
| knowing about comments is useful |
It was an unusual PR with some discussion beyond the ordinary, which the comments are helpful to identify |
| knowing about comments is useful |
Big Number of review comments might indicate good review |
| knowing about comments is useful |
code review comments in a short patch mean something |
| knowing about comments is useful |
Comments pior to commit suggest the PR couldnt be immediately merged, which is unusual for this repo |
| knowing about comments is useful |
Comments with empty assignee are unusual. |
| knowing about comments is useful |
When reviewing project history, reviews with a lot of comments could be more interesting in terms of decisions (not really in this case, but generally). Lingering open pull requests are bad news, so its useful to know about PRs that were open for l |
| knowing about comments is useful |
It shows that there was an unusual amount of discussion around how to approach the issue |
| knowing about comments is useful |
It indicates the issue may be non-trivial and required extra thought and review than normal |
| knowing about comments is useful |
It indicates there was significant changes made that are with extra review |
| knowing about comments is useful |
In this case it indicates an interesting discussion that spans beyond the concrete issue |
| knowing about comments is useful |
It would indicate that this issue has discussion with additional review |
| knowing about unusual deletions is not useful |
core developer deleting one file isnt unusual |
| knowing about unusual deletions is useful |
Usually pull requests add more stuff than delete them. Also, usually pull requests are more substantial than this one, so its a bit small anyway. |
| knowing about unusual deletions is useful |
LOC deleted relative to owner can be a good measure of difficulty of the pull request. |
| knowing about unusual deletions is useful |
Merged pull requests (and, to a lesser extent, pull requests in general) typically add more code than they remove. Usually feels pretty good to put in a pull request that rips out a bunch of outdated shit. |
| long commit message or issue/pull request body is useful |
A very long issue description indicates something complicated that requires lots of supporting info. |
| long commit message or issue/pull request body is useful |
The length of the explanation might indicate that the problem is either hard to characterize or to justify. |
| long commit message or issue/pull request body is useful |
Looks like this was for a race condition which I imagine dont happen often. The message length being significantly longer flags to me that there was worth saying. |
| long commit message or issue/pull request body is useful |
A longer message can indicate the why for the change is not immediately obvious. |
| long commit message or issue/pull request body not useful |
Commit comment length isnt a useful metric unless its unusually short. |
| long commit message or issue/pull request body not useful |
why should it be useful? What is wrong with a long commit message? |
| long commit message or issue/pull request body not useful |
I dont understand what the metric days between commits for file / commit parent count app/templates/viewsupplierusers.html / 1 means, so it doesnt feel like a useful thing to be told. Particularly long commit messages are worth knowing abo |
| long commit message or issue/pull request body not useful |
Not useful, because its mostly just an (uninteresting) copy-pasted shell session. |
| long commit message or issue/pull request body not useful |
Message length is not a valid metric |
| long commit message or issue/pull request body not useful |
I wouldnt care much about message length. Yeah, I added a test, which added dozens of LOC. |
| long commit message or issue/pull request body not useful |
A long description doesnt indicate correctedness. It may just contain logspam. Looking for headers, or a well defined structure may be more useful. |
| long commit message or issue/pull request body not useful |
body length doesnt matter anything |
| long commit message or issue/pull request body not useful |
I dont think itd be useful to pay attention to message length. |
| long time between commits can be useful |
The LOC changes is not that useful, the more useful is the content inside whats changes. The days between commits is quite useful that telling is the contributor active or not. |
| long time between commits can be useful |
It demonstrates what parts of the software are unusually non-updated. This can demonstrate stability or neglect. |
| long time between commits can be useful |
Your rules seem to assume all files get updated very frequently. Some of this code is very stable and hasnt needed much modification. Were also pretty bad at updating ACKNOWLEDGEMENTS, but I doubt were the only project who does that. |
| long time between commits can be useful |
Days between commits for filetypes would be good to determine what kinds of things are being worked on (code vs. assets vs. buiild scripts) |
| long time for an issue or pull request can indicate low priority |
I think this PR was of very low priority (code cleaning) and thus the high time it took to be closed and merged. |
| long time for an issue or pull request can indicate low priority |
Im well aware of the large number of long-open bugs in this project, and Im also aware that most long-open bugs are considered low priority by the developers. |
| long time for an issue or pull request can indicate low priority |
It was a very low priority feature request that took us ages to finally get around to doing |
| long time for an issue or pull request can indicate low priority |
Its useful to see we have a long outstanding documentation issue, as they tend to be neglected unless we are reminded accordingly |
| long time for an issue or pull request can indicate low priority |
This was a minor, low priority test fix so it taking time is not surprising |
| long time for an issue or pull request can indicate low priority or difficulty |
the open-closed time usually means low priority, improper issue statement or something very difficult to fix. |
| long time-to-close can be useful |
Six months is a long time, and to me it could indicate there was some question about design or intended outcome. |
| long time-to-close can be useful |
This PR was left blocked because of a refactoring that was taking placed and finally it was rejected as not longer necessary. Really took to long for he whole process. |
| long time-to-close can be useful |
Useful and important to understand why issues age |
| long time-to-close can be useful |
I think the info is really useful actually, having a long standing issue could either be an indicator of a difficult issue. |
| long time-to-close can be useful |
I think youre asking this has taken a long time to close - is that information useful? in which case, yes, seeing which issues have been open the longest can be vital. |
| long time-to-close can be useful |
Issues becoming stale could be interesting. |
| long time-to-close can be useful |
This information is useful. Knowing Jose is closes issues quickly makes it appear that this was a difficult problem. |
| long time-to-close can be useful |
This bug was easy to fix but hard to find ? the long time between open and close is a good indicator of that. |
| long time-to-close can be useful |
Issue might be to complex |
| long time-to-close is not useful afterwards |
It would be good to know which issues have been outstanding for a long time but once the issue has been address/closed, this information becomes irrelevant. |
| more advanced code metrics would be useful |
I think youre trying to say is this a complex patch? the answer is yes. Displaying a raw complexity score may be useful. |
| more advanced code metrics would be useful |
the number of lines show the complexity of patch |
| more advanced code metrics would be useful |
The number of merges with master doesnt really indicate anything at all. |
| number of commits on pull request is useful |
Detect unusual PRs to have more people check it |
| outlier type is too granular |
I think splitting LOC metrics by file and label is probably too granular. |
| outlier type is too granular |
Too granular; includes general-purpose status labels; number of pulls is strange terminology (number of commits would be better) |
| outlier type is too granular |
Not sure if if comments vs assignee is interesting. |
| outlier type is too granular |
Per-file outlier statistics are not that interesting to me. |
| outlier type is too granular |
Separation by filetype isnt super interesting considering all of it is C code; and Im not sure what the number of pulls means, [email protected] is one of the project owners email addresses |
| outlier type is too granular |
We dont generally assign PRs very much, so number of LOC deleted for assignee is pretty much equivalent to number of LOC deleted so not useful as a separate thing. For number of LOC deleted for merge status true - probably too la |
| outlier type is too granular |
I find general information about a projects progress more interesting than the statistics on a single file (which might not need changes that often). |
| outliers on labels are not useful |
Different projects use Github labels for different purposes. Some of them are not using label at all. Its not significant |
| outliers on labels are not useful |
labels might not mean anything. The amount of conversation and lack of action is what makes it atypical for me. |
| outliers on labels are not useful |
This is not a a typical software repo, as it is the source of the projects website including a blog. Although it is unusual that this issue is labled, I dont think labeling and assignees are very important here as issues will generally not stay o |
| outliers on labels are not useful |
not useful. All this tells me is that the project has a custom labeling scheme and that this particular label is not applied often. |
| response time to pull requests is an important metric |
The responsiveness of the repo owner is valuable when evaluating using/contributing to an open source project. Knowing the average response time for issues/PRs is interesting. |
| response time to pull requests is an important metric |
Useful as it would help reach novice people in the open source community for help, which would inturn increase the quality of coding that the people would provide. |
| response time to pull requests is an important metric |
It would help sort out the problem with the pull request if it takes too long to close. |
| response time to pull requests is an important metric |
This could be useful as an alert that a PR is awaiting action. |
| response time to pull requests is an important metric |
slow responses on pull requests are good information to have on a project. pull requests should not go that long without being answered. |
| response time to pull requests is an important metric |
slow responses on pull requests are good information to have on a project. pull requests should not go that long without being answered. |
| response time to pull requests is an important metric |
Would be super cool to know how long pull requests stay open, especially on a per-team-member basis. |
| response time to pull requests is an important metric |
Yes, it would show whose PRs are getting ignored. |
| response time to pull requests is an important metric |
Useful, so that the admin can figure out what all issues have not yet been resolved and take some action on it. |