coding.md

code	quote
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, obs.jim@gmail.com 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.