-
Couldn't load subscription status.
- Fork 721
telemetry(amazonq): calculate % of non-generated (user-written) code #5991
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
⛔️ Not planned for tomorrow's release. |
packages/amazonq/test/unit/codewhisperer/tracker/userWrittenCodeTracker.test.ts
Outdated
Show resolved
Hide resolved
…deTracker.test.ts Co-authored-by: Justin M. Keyes <jmkeyes@amazon.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving with the expectation that this followup work with land soon:
Our expectation is to completely get rid of the old CodeCoverageTracker.ts in a few weeks.
packages/core/src/codewhisperer/tracker/userWrittenCodeTracker.ts
Outdated
Show resolved
Hide resolved
packages/core/src/codewhisperer/tracker/userWrittenCodeTracker.ts
Outdated
Show resolved
Hide resolved
packages/core/src/codewhisperer/tracker/userWrittenCodeTracker.ts
Outdated
Show resolved
Hide resolved
packages/core/src/codewhisperer/tracker/userWrittenCodeTracker.ts
Outdated
Show resolved
Hide resolved
…ws#5991 ## Problem With the release of many Q features(Inline Suggestion, chat, inline chat, /dev, /test, /doc, /review, /transform), we need to know the % code written by all Q features. This requires calculating and reporting the user written code. The reporting of the code contribution of each Q features was already implemented. ## Solution Calculate and report the user written code for each language by listening to document change events while Q is not making changes to the editor. We add flags to know whether Q is making temporary changes for suggestion rendering or Q suggestion is accepted, by doing so, the document change events are coming from the user. We ignore certain document changes when their length of new characters exceeds 50. Previous data driven research has shown that user tend to copy a huge file from one place to another, making the user written code count skyrocketing but that is actually some existing code not written by the user. We plan to first collect data from IDEs and let it run in the background in shadow mode before we finish the service side aggregation, fix possible bugs and eventually present the AI code written % to the customers. Note: The JB PR aws/aws-toolkit-jetbrains#5215. The JB implementation depends on a reliable JB internal message bus to pass information. Using VSC event listener might mess up the boolean state of Q editing or not.
With the release of many Q features(Inline Suggestion, chat, inline chat, /dev, /test, /doc, /review, /transform), we need to know the % code written by all Q features. This requires calculating and reporting the user written code. The reporting of the code contribution of each Q features was already implemented. % Code Written by Q = Code Written by Q / ( Code Written by Q + Code Written by User) Ref: aws/aws-toolkit-vscode#5991 Calculate and report the user written code for each language by listening to document change events while Q is not making changes to the editor. We add flags to know whether Q is making temporary changes for suggestion rendering or Q suggestion is accepted, by doing so, the document change events are coming from the user. We ignore certain document changes when their length of new characters exceeds 50. Previous data driven research has shown that user tend to copy a huge file from one place to another, making the user written code count skyrocketing but that is actually some existing code not written by the user. We plan to first collect data from IDEs and let it run in the background in shadow mode before we finish the service side aggregation, fix possible bugs and eventually present the AI code written % to the customers.
…ws#5991 ## Problem With the release of many Q features(Inline Suggestion, chat, inline chat, /dev, /test, /doc, /review, /transform), we need to know the % code written by all Q features. This requires calculating and reporting the user written code. The reporting of the code contribution of each Q features was already implemented. ## Solution Calculate and report the user written code for each language by listening to document change events while Q is not making changes to the editor. We add flags to know whether Q is making temporary changes for suggestion rendering or Q suggestion is accepted, by doing so, the document change events are coming from the user. We ignore certain document changes when their length of new characters exceeds 50. Previous data driven research has shown that user tend to copy a huge file from one place to another, making the user written code count skyrocketing but that is actually some existing code not written by the user. We plan to first collect data from IDEs and let it run in the background in shadow mode before we finish the service side aggregation, fix possible bugs and eventually present the AI code written % to the customers. Note: The JB PR aws/aws-toolkit-jetbrains#5215. The JB implementation depends on a reliable JB internal message bus to pass information. Using VSC event listener might mess up the boolean state of Q editing or not.
…ws#5991 ## Problem With the release of many Q features(Inline Suggestion, chat, inline chat, /dev, /test, /doc, /review, /transform), we need to know the % code written by all Q features. This requires calculating and reporting the user written code. The reporting of the code contribution of each Q features was already implemented. ## Solution Calculate and report the user written code for each language by listening to document change events while Q is not making changes to the editor. We add flags to know whether Q is making temporary changes for suggestion rendering or Q suggestion is accepted, by doing so, the document change events are coming from the user. We ignore certain document changes when their length of new characters exceeds 50. Previous data driven research has shown that user tend to copy a huge file from one place to another, making the user written code count skyrocketing but that is actually some existing code not written by the user. We plan to first collect data from IDEs and let it run in the background in shadow mode before we finish the service side aggregation, fix possible bugs and eventually present the AI code written % to the customers. Note: The JB PR aws/aws-toolkit-jetbrains#5215. The JB implementation depends on a reliable JB internal message bus to pass information. Using VSC event listener might mess up the boolean state of Q editing or not.
…ws#5991 ## Problem With the release of many Q features(Inline Suggestion, chat, inline chat, /dev, /test, /doc, /review, /transform), we need to know the % code written by all Q features. This requires calculating and reporting the user written code. The reporting of the code contribution of each Q features was already implemented. ## Solution Calculate and report the user written code for each language by listening to document change events while Q is not making changes to the editor. We add flags to know whether Q is making temporary changes for suggestion rendering or Q suggestion is accepted, by doing so, the document change events are coming from the user. We ignore certain document changes when their length of new characters exceeds 50. Previous data driven research has shown that user tend to copy a huge file from one place to another, making the user written code count skyrocketing but that is actually some existing code not written by the user. We plan to first collect data from IDEs and let it run in the background in shadow mode before we finish the service side aggregation, fix possible bugs and eventually present the AI code written % to the customers. Note: The JB PR aws/aws-toolkit-jetbrains#5215. The JB implementation depends on a reliable JB internal message bus to pass information. Using VSC event listener might mess up the boolean state of Q editing or not.
Problem
With the release of many Q features(Inline Suggestion, chat, inline chat, /dev, /test, /doc, /review, /transform), we need to know the % code written by all Q features. This requires calculating and reporting the user written code. The reporting of the code contribution of each Q features was already implemented.
Solution
Calculate and report the user written code for each language by listening to document change events while Q is not making changes to the editor.
We add flags to know whether Q is making temporary changes for suggestion rendering or Q suggestion is accepted, by doing so, the document change events are coming from the user.
We ignore certain document changes when their length of new characters exceeds 50. Previous data driven research has shown that user tend to copy a huge file from one place to another, making the user written code count skyrocketing but that is actually some existing code not written by the user.
We plan to first collect data from IDEs and let it run in the background in shadow mode before we finish the service side aggregation, fix possible bugs and eventually present the AI code written % to the customers.
Note: The JB PR aws/aws-toolkit-jetbrains#5215. The JB implementation depends on a reliable JB internal message bus to pass information. Using VSC event listener might mess up the boolean state of Q editing or not.
License: I confirm that my contribution is made under the terms of the Apache 2.0 license.