I was reviewing this action run and its a lot more clear to me when looking at the clean JSON logs exactly whats going on here. I realized that the scoring is implemented incorrectly. The primary crediting strategy is supposed to be based on the amount of elements. The word counter is a separate scoring mechanism. This was added as an after thought in version one, but it seems that you prioritized word count over element count.
The problem is that the original emphasis on element count allows us to easily target and credit special and useful elements such as <a>, <img>, and <code>. Helpful comments generally have links, images and code samples.
With the following example, I would expect only one <p>
The comment word count is 7
We also need the ability to ignore words inside of specific tags. For example, <code>
Now you are keeping track of word count PER element which is more complex than it needs to be. Remember, the word count scoring strategy was added as an after thought for version one. Version one simply counts all the words in the comment (but also ignores words in specific elements, like code.) at the end of all the complex calculations.
Aside from the ignore capability, it doesn't care which element contains the words.
{
"id": 2014495969,
"content": "Wouldn't solve scenarios requiring keys or credentials",
"url": "https://github.com/ubiquity/cloudflare-deploy-action/issues/6#issuecomment-2014495969",
"type": "ISSUE_ASSIGNEE",
"score": {
"formatting": {
"content": {
"p": {
"count": 7, // should be changed to `wordCount` and you should correctly count the amount of `p` tags to be `elementCount`
"score": 1
}
},
"wordValue": 0,
"formattingMultiplier": 0
},
"reward": 0,
"relevance": 0.3
}
}
I would expect our p scoring to be 0 but our word scoring to be 0.1 for a grand total of 0.7.
Because this is the assignee writing on the issue (not the pull) we can provide credit; so the multiplier should not be 0.
Perhaps we could do a 4x multiplier, which yields 2.8 but then multiply by relevance to yield a sum of 0.84 for the comment.
I was reviewing this action run and its a lot more clear to me when looking at the clean JSON logs exactly whats going on here. I realized that the scoring is implemented incorrectly. The primary crediting strategy is supposed to be based on the amount of elements. The word counter is a separate scoring mechanism. This was added as an after thought in version one, but it seems that you prioritized word count over element count.
The problem is that the original emphasis on element count allows us to easily target and credit special and useful elements such as
<a>
,<img>
, and<code>
. Helpful comments generally have links, images and code samples.<p>
7
<code>
Now you are keeping track of word count PER element which is more complex than it needs to be. Remember, the word count scoring strategy was added as an after thought for version one. Version one simply counts all the words in the comment (but also ignores words in specific elements, like
code
.) at the end of all the complex calculations.Aside from the ignore capability, it doesn't care which element contains the words.
p
scoring to be0
but our word scoring to be0.1
for a grand total of0.7
.0
.2.8
but then multiply by relevance to yield a sum of0.84
for the comment.Source