Define mismatches between DOI levels and log levels

[khatchad]

How do we relate these two concepts of "interest?" The hypothesis we have is that there should be a correlation between the concept of DOI in general to the interestness of the log statement, i.e., it's level.

┆Issue is synchronized with this Asana task

[khatchad]

Can you make some kind of table here?

DOI range	Log Level
Less than 10	CRITICAL
5 < x < 10	WARNING

[khatchad]

Another approach would be to use a machine learning technique where you learn how the developer changes the log levels manually. When they change it manually, you examine what the DOI value is at that time.

[yiming-tang-cs]

Can you make some kind of table here?

I've thought about this problem. Because different developers have different programming styles/ways /levels, the same DOI value could mean the different interests for different developers. The transformation depends on how the developers programming and how they activate the tasks. In this case, I think I should have a general solution. My idea is to get the highest and lowest DOI value, then divide the DOI range into 7 partitions (because of 7 logging levels). How do you think?

[khatchad]

➤ Raffi Khatchadourian commented:

Let me think about this. In the meantime, could you have a boolean returning method that returns true if there is a mismatch and false otherwise? Right now, it can just return false. Based on the return value of this method, which we will fill in later, you should be able to action.

[khatchad]

➤ Raffi Khatchadourian commented:

I think it is a great idea. Please proceed.

[khatchad]

Please remember to document this decision in the paper draft if you decide to stick with it.

[yiming-tang-cs]

If all DOI values are same, what should I do? Can I tell the developers that I cannot get enough data to analyze?

[khatchad]

Hm. That is making me think twice about this strategy. Please make it very modular so that the logic is in one place and we can change it very easily. The comparison should be to the logging level. I don't think it really is relative to all logging statements. Do you agree?

[khatchad]

I think you may need to go with the machine learning approach I mentioned earlier, or need to examine some history of DOI values. Using the ML approach, you probably won't have DOI information in the training set, which would mean that you would need some other way of determining DOI (like git history), which we don't have yet. So, I'd say go with the original plan of hard coding until we can figure it out.

[yiming-tang-cs]

Hm. That is making me think twice about this strategy. Please make it very modular so that the logic is in one place and we can change it very easily. The comparison should be to the logging level. I don't think it really is relative to all logging statements. Do you agree?

What do you mean " I don't think it really is relative to all logging statements"? So do you think I do not need to get MAX and MIN DOI from all logging statements?

[yiming-tang-cs]

I think you may need to go with the machine learning approach I mentioned earlier, or need to examine some history of DOI values. Using the ML approach, you probably won't have DOI information in the training set, which would mean that you would need some other way of determining DOI (like git history), which we don't have yet. So, I'd say go with the original plan of hard coding until we can figure it out.

I agree. I've also thought about git history. I think I cannot get DOI value from git history because one commit in the git history is not equal to one event in the DOI model. One commit could be generated by several events. We may need other ways to get training set.

[khatchad]

I'd say hard code for now and let's figure it out later. Let's get the transformation going.

On Fri, 2018-06-29 at 08:30 -0700, Grace Tang wrote:

I think you may need to go with the machine learning approach I mentioned earlier, or need to examine some history of DOI values. Using the ML approach, you probably won't have DOI information in the training set, which would mean that you would need some other way of determining DOI (like git history), which we don't have yet. So, I'd say go with the original plan of hard coding until we can figure it out.

I agree. I've also thought about git history. I think I cannot get DOI value from git history because one commit in the git history is not equal to one event in the DOI model. One commit could be generated by several events. We may need other ways to get training set.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/ponder-lab/Logging-Level-Evolution-Plugin/issues/40#issuecomment-401390058, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB9DP2JB8lmfJMVQSm-I0Uad3rR5z2K3ks5uBkgugaJpZM4UvyaK.

[khatchad]

I mean that, for example, all the logging statements could have very low DOI but all have a level of, say, CRITICAL. In such case, all should down graded in some way. In other words, DOI relative to other logging statements may not be relevant.

On Fri, 2018-06-29 at 08:24 -0700, Grace Tang wrote:

Hm. That is making me think twice about this strategy. Please make it very modular so that the logic is in one place and we can change it very easily. The comparison should be to the logging level. I don't think it really is relative to all logging statements. Do you agree?

What do you mean " I don't think it really is relative to all logging statements"? So do you think I do not need to get MAX and MIN DOI from all logging statements?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/ponder-lab/Logging-Level-Evolution-Plugin/issues/40#issuecomment-401388132, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB9DP89eV-xRHEuxzZuvn_HluA_E1zw3ks5uBkangaJpZM4UvyaK.

[khatchad]

Looks like we have an issue here.