Top helpers based on message length #446
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Zabuzard
added
enhance command
migration script adding the new column (default 1), existing data is untouched Default count to 1 for backwards support using count 1 ensures that the new system naturally outputs the same as the old system for old months (since all messages then just count 1, as they did before)
Zabuzard
force-pushed
the
feature/message_length_based_top_helpers
branch
from
490202a to
9634484
Compare
|
Kudos, SonarCloud Quality Gate passed! |
|
Merging this early since its low risk and I want to have it deployed at 1st of June (see PR description). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Since determining top helpers on message count is indeed quite unfair to helpers who prefer to type out their messages instead of posting multiple mini messages, this changes the metric to measure and determine them based on the length of the messages.
Not perfect, but gets the job done and is fairer.
Existing data stays untouched. We could revert back at any time. Also, for previous months, the new code can still output the same results as before (by defaulting to message length 1 for migrated content).
When to release
Note that this should ideally be released near the end or start of a month, to not mess up the metric for that month. It should definitely not be released in the middle of a month. Alternatively, it can of course still be manually retrieved from the database with the old query.