BMO/UserProfiles

This is a project to add a user profile page into Bugzilla. It would show a few stats summing up particular actions or contributions by the user, and would be visible to all logged in users.

In this version of the profile, the user does not have to upload or fill in any fields, as the entire profile is generated from data within Bugzilla.

Bug filed at: bug 859550 [ateamtrack: p=bugzilla q=2 m=1]

How a simple user profile might look

---

• URL: http://bugzilla.mozilla.org/userprofile.cgi?login=lhenry@mozilla.com

• Name: lizzard
• Login: lhenry@mozilla.com
• Mozillians.org profile: [link ]

• Last activity: 2013-03-26
• Bugs filed: 13
• Commented on: 53
• Confirmed: 10
• QA-contact: 0
• Patches submitted: 0
• Patches reviewed: 0
• Assigned to: 1
• Bugs poked: 155

• RESOLVED (20), INVALID (3), FIXED (5), VERIFIED (5)

Bugzilla activity in:

Core(2), Firefox(5), FirefoxOS(0), Firefox for Android(1), Firefox for Metro(0), Toolkit(1), Marketplace(1), Thunderbird(1), SeaMonkey(1), Mozilla Localizations(3), Mozilla Services(1), Other Products(10)

---

Explanation of these stats

• Each stat has a number associated with it, a description, and a more info link.
• Stats that don't have any activity should still show on the page with a zero for the #.
• The number should link to a bugzilla query.
• The field names should each have a tooltip short description. Each field name could also either be links themselves, or could have a "more info" long description which might be either an explanation or a link to an external page. (In this case probably a WMO page.)
• The Mozillians link is simply a link to the user-provided Mozillians profile page. There will be no API level integration with mozillians.org at this stage.

Questions

• Should we include private bugs, comments, and attachments?
  • Having different counts depending on what the viewing user can see is not viable
  • Will assume public-only data unless told otherwise
• Should patches submitted be all the ones submitted? obsolete ones too?
• Should we give a different stat for patches reviewed + accepted?
• Bugs assigned would be all of them ever for this user, not just open ones. Would only the current assignee "count"? If the assignee changes, do they both increment?)

Strings

(bug 862441 and bug 859550)

Mousing over a field name would pop up a tooltip with the field name description.

Clicking on the field names in the profile would take the user to that term (anchor text) on a page with descriptions of all the user profile field names.

user profile field descriptions

Last activity

The date and time a user last reported, changed or commented on a bug in bugzilla. Link to user activity report for the last 30 days.

Bugs filed

The total number of bugs reported by the user. More info: <a href="https://wiki.mozilla.org/How_to_File_a_Bug">How to File a Bug</a>

Commented on

The total number of bugs that the user has commented on. More info: <a href="https://bugzilla.mozilla.org/page.cgi?id=etiquette.html">Bugzilla etiquette</a>

Confirmed

The number of bugs the user has changed from UNCONFIRMED to NEW. More info: <a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Confirming_unconfirmed_bugs">Confirming unconfirmed bugs</a>

QA-contact

QA-contacts work as part of the QA team to help developers with regression testing, steps to reproduce bugs, and bug verification. More info: <a href="https://quality.mozilla.org/docs/misc/how-can-i-help-test/">How can I help test?</a>

Patches submitted

The number of patches a user has submitted to help fix a bug. More info: <a href="https://developer.mozilla.org/en-US/docs/Introduction">Contributing to the Mozilla Codebase</a>, <a href="https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch">How to Submit a Patch</a>, and <a href="https://wiki.mozilla.org/Bugzilla:Review">Bugzilla:Review</a>.

Patches reviewed

Shows how many patches a user has reviewed. More info: <a href="https://developer.mozilla.org/en-US/docs/Code_Review_FAQ">Code Review FAQ</a> including how to become a reviewer.

Assigned to Bugs assigned to a user.

Bugs poked Total number of bugs a user has interacted with: filed, commented on, changed status, added whiteboard or keyword tags, changed product or component; anything done to the bug that results in saving changes.

RESOLVED Bugs a user has changed from NEW, UNCONFIRMED, or REOPENED to RESOLVED. More info: <a href="https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla#Resolving_bugs">Resolving bugs</a>.

DUPLICATE Bugs a user has resolved as a duplicate of an existing bug More info: <a href="https://developer.mozilla.org/en-US/docs/Screening_duplicate_bugs ">Screening DUPLICATE bugs</a>.

INVALID Bugs a user has resolved as INVALID; these may be issues that aren't Mozilla bugs, or are features rather than unexpected behavior. More info: <a href="https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla#Resolving_bugs">Resolving bugs as INVALID</a>.

WORKSFORME Bugs a user was unable to reproduce on the reported hardware and OS. More info: <a href="https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla#Resolving_bugs">Resolving bugs</a>.

FIXED Bugs a user has resolved as FIXED. Only verify FIXED if the bug's resolution can be tied to a specific code checkin in a Mozilla repository. More info: <a href="https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla#Resolving_bugs">Resolving bugs as FIXED</a>.

VERIFIED Resolved bugs that a user has made sure have been resolved correctly. More info: <a href="https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla#Verifying_bugs">Verifying bugs</a>.

For the products listed on the user page, use the same strings as are in https://bugzilla.mozilla.org/describecomponents.cgi .

• Core
• Firefox
• FirefoxOS
• Firefox for Android
• Firefox for Metro
• Toolkit
• Marketplace
• Thunderbird
• SeaMonkey
• Mozilla Localizations
• Mozilla Services
• Other Products

Implementation Notes

Add a field to the profiles table which is used to track if a user's statistics need to be updated (triggered when the user file/updates/comments on a bug). Schedule a cron job to run at an off-peak time which updates the statistics for users. Expose those statistics via a package which monkey patches a getter into the User package.

Schema

profiles_statistics

• id identity
• user_id fk profile.userid
• name varchar30
• value varchar30

profiles_statistics_status

• id identity
• user_id fk profile.userid
• status varchar30
• count int

profiles_statistics_products

• id identity
• user_id fk profile.userid
• product_id fk products.id
• count int

new fields:

• profiles.mozillians_id varchar64 (mozillians.org username)
• profiles.last_activity_ts datetime timestamp of most recent update, comment, etc
• profiles.last_statistics_ts datetime timestamp of last time the statistics were generated for this user

Data Points

• last_activity : from profiles.last_activity_ts
• bugs_filed : simple count from bugs table (public bugs only)
• comments : simple count from long_descs table (public comments only)
• confirmed : bugs_activity where field=status and removed='UNCONFIRMED' (public bugs only)
• qa_contact : simple count from bugs table (public bugs only)
• patches : simple count from attachments table (public bugs and attachments only)
• reviews : review+ flags count (public bugs and attachments only)
• assigned : simple count from bugs table (public bugs only)
• touched : simple count from bugs_activity + long_descs table (public bugs, comments and attachments only)
• by-status counters : simple count from bugs table (public bugs only)
• by-product counters : simple count from bugs table (public bugs only)