Closed
Bug 997788
(mdn-contributor-bar-1)
Opened 10 years ago
Closed 8 years ago
Meta bug - Top contributors Prototype
Categories
(developer.mozilla.org Graveyard :: General, enhancement)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: aspivak, Unassigned)
References
Details
(Keywords: meta, Whiteboard: [specification][type:feature])
What problems would this solve? =============================== Reward current contributors and highlight to users that the doc is made by a community Who would use this? =================== users & contributors What would users see? ===================== icons of top contributors What would users do? What would happen as a result? =================================================== they will see a bar with icons of top contributors to the doc and be able to click on them to see the profile. Is there anything else we should know? ======================================
Updated•10 years ago
|
Comment 1•10 years ago
|
||
:habber - can we go ahead and release the contributor bar to more visitors now? Should we block on a new design? I'm eager to open it to non-beta users so we can better compare how the feature affects behavior.
Flags: needinfo?(hhabstritt.bugzilla)
Comment 2•10 years ago
|
||
Bug 961570 proposes a definition of "top" contributors.
Comment 3•10 years ago
|
||
Bug 1008982 describes placement and visual design for top contributors on article pages. :groovecoder , when you say "more visitors", how many do you mean?
Flags: needinfo?(hhabstritt.bugzilla)
Comment 4•10 years ago
|
||
:Habber - e.g., 50% of visitors. (Right now it's shown to just 4.5k beta testers)
Flags: needinfo?(hhabstritt.bugzilla)
Comment 5•10 years ago
|
||
I opened the feature to 20% of MDN visitors for the last few days. First data of "Sessions with Top Contributors shown" vs. "All Sessions" is promising ... Overall site engagement (These seem to be more susceptible to selection bias of the beta testers): * 2.91 pages/session (vs. 1.89) * 04:54 session duration (vs. 02:32) * 52.42% bounce rate (vs. 70.37%) Goal: Profile Edit * .10% conversion rate (vs. .04%) Goal: Register an account * .24% conversion rate (vs. .10%) Profile page engagement * 01:17 Avg. Time on Page (vs. 01:09) * 42.71% bounce rate (vs. 55.70%) * 17.89 exit rate (vs. 24.10%) Given everything looks positive - even on profile pages where users may have accidentally clicked the bar - I'm going to open the feature up to *more* visitors to get more data and to remove even more of the selection bias of the beta tester group.
Flags: needinfo?(hhabstritt.bugzilla)
Comment 6•10 years ago
|
||
Opened to 60% of users. Saw a slow-down on response time from ~225ms avg to ~275ms avg. :/ I'll keep an eye on it and turn it back down if its too much impact.
Comment 7•10 years ago
|
||
Ooo, make that ~300ms to ~380ms for document views: https://rpm.newrelic.com/accounts/263620/applications/3172075/deployments/1142871#tab-view_deployment=change_report&sort=4%2C1 So we might turn this back down, or try to optimize it.
Comment 8•10 years ago
|
||
What about the dependency bugs? I really, really want to get rid of the null contributors in the list. I don't consider this properly implemented with them in there. I'm open to other proposals than those bugs for how to do that.
Comment 9•10 years ago
|
||
Based on the estimates (2-6 weeks) for bug 997763 do we still want it to block the full release of the feature? Or can it be a post-release bug-fix?
Flags: needinfo?(jswisher)
Comment 10•10 years ago
|
||
I'm not sure this is my call to make, but I'm inclined to say that it should block the release of the feature. It's like implementing a dashboard that displays partially incorrect data, and making display of correct data a post-release bug-fix. The bad data undermines the purpose of the feature.
Flags: needinfo?(jswisher)
Comment 11•10 years ago
|
||
Janet - will we make decisions based on the incorrect data in this feature? I've been considering it more of a vanity feature than a critical feature.
Flags: needinfo?(jswisher)
Comment 12•10 years ago
|
||
No, as admins of MDN, we won't make decisions based on this feature or its data. (Awarding badges is another story, and another bug.) But this feature is providing feedback to contributors about contributions. If it provides inaccurate data, it can undermine its own credibility with the substantive contributors we most want to recognize. It might also lead to "vanity" contributions by those who get an ego boost from gaming the system: I can get my name in the list of contributors (and my avatar at the top of the page) by doing nothing other than clicking Edit and clicking Save. We should strive to implement features that encourage desirable behavior, and don't reward undesirable behavior.
Flags: needinfo?(jswisher)
Comment 13•10 years ago
|
||
+1 to Janet's take on this. Promoting and inviting bad data is a bug. Launching with the bug will add urgency to the fix -- i.e. we'll be more inclined to fix it soon. If we're actually inclined to fix it soon we should do that and then launch, and if we're not inclined to fix it soon we shouldn't make doing so more urgent by launching with the bug.
Comment 14•10 years ago
|
||
With that in mind, this bug should block on bug 797845, so that the undesirable behavior is not possible. Bug 997763 could be fixed post-release, since it's only about displaying old empty revisions, and not about creating new ones.
Comment 15•10 years ago
|
||
I've heard from a few people now that this shouldn't ship while the code displays empty edits. Allowing empty edits in MDN blocks the badges project, too. Bug 1018206 tracks the empty revisions problem, so I'm blocking on that for now.
Depends on: 1018206
Comment 16•9 years ago
|
||
Changing bug title to be a "first prototype" tracking bug. Removing duplicate blocker.
Alias: mdn-contributor-bar-1
No longer depends on: 1018206
Summary: Meta bug - Top contributors → Meta bug - Top contributors Prototype
Comment 17•9 years ago
|
||
Removing 2 XL bugs from blocking the prototype.
Comment 18•9 years ago
|
||
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/976650d4cea26c38090db6575b65752e95cd6d99 bug 997788 - fix ga event label to track position clicked https://github.com/mozilla/kuma/commit/709b683f9eb35c039af4277fb8c526107793db92 Merge pull request #3335 from mozilla/fix-contributor-event-label-997788 bug 997788 - fix ga event label to track position clicked
Comment 19•8 years ago
|
||
We've had the contributor bar in production for some time now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Updated•4 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•