BMO/UserProfiles: Difference between revisions

From MozillaWiki
< BMO
Jump to navigation Jump to search
m (added Category:BMO using HotCat)
 
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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.
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.  
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 (except for the Mozillians username field).


Bug filed at: https://bugzilla.mozilla.org/show_bug.cgi?id=859550
Bug filed at: {{bug|859550}}
[ateamtrack: p=bugzilla q=2 m=1]  
[ateamtrack: p=bugzilla q=2 m=1]  


Line 10: Line 10:
--------------------------------------------------
--------------------------------------------------
* URL: http://bugzilla.mozilla.org/userprofile.cgi?login=lhenry@mozilla.com   
* URL: http://bugzilla.mozilla.org/userprofile.cgi?login=lhenry@mozilla.com   


* Name: lizzard
* Name: lizzard
* Login: lhenry@mozilla.com
* Email: lhenry@mozilla.com
* Mozillians.org profile: [link ] (BMO) (Needs some complexity to implement)
* Mozillians.org profile: [link ]
 


* Last activity:          2013-03-26   
* Last activity:          2013-03-26   
* Bugs filed:            13   
* Bugs filed:            13   
* Comments made:          46
* Assigned to:            1
* Commented on:          53  
* Commented on:          53  
* Confirmed:              10  (confirmed meaning # of bugs you changed from unco to new)
* Confirmed:              10   
* QA-contact:            0 (info)
* QA-contact:            0  
* Patches submitted:      0 (info)   (# of attachments that have content type of patch)
* Patches submitted:      0   
* Patches reviewed:      0
* Patches reviewed:      0
* Assigned to:        1
* Bugs poked:             155   
* Bugs poked:           155   
 
* RESOLVED:  INVALID (3), VERIFIED (5), FIXED (5)
 
 
Activity:
 
Statuses changed: RESOLVED (20), INVALID (3), FIXED (5), VERIFIED (5)
 
By Product: 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)


* Firefox (23), Firefox for Android (2), FirefoxOS (1), Thunderbird (6), SeaMonkey (2) 
<small>[https://wiki.mozilla.org/BMO/User_profile_fields What do these fields mean?] </small>
-------------------------
-------------------------


Line 35: Line 43:
* The number should link to a bugzilla query.
* 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 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 pages will have to be able to be hosted by Bugzilla if the work is going upstream.
* 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 ===
=== 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 patches submitted be all the ones submitted? obsolete ones too?  
* Should we give a different stat for patches reviewed + accepted?  
* 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?)
* 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?)
* We can show a link to a Mozillians profile by checking the email address against the Mozillians API. However, Mozillian profiles are only visible to vouched Mozillians. So, to display the link, we would need to know which Bugzilla users are vouched Mozillians, and not show the link to others. Would that mess up performance?
** right now automatically linking from bmo to mozillians isn't viable as mozillians only allows for a single email address, and many people use different accounts on bmo vs mozillians.
** it would be much simpler to add a 'mozillians user' field to the user, add it to the account profile tab, and show that link if it's populated.  i don't think we need to validate that field in the first revision.


=== Strings ===
=== Strings ===
([https://bugzilla.mozilla.org/show_bug.cgi?id=862441 862441] and [https://bugzilla.mozilla.org/show_bug.cgi?id=859550 859550])
({{bug|862441}} and {{bug|859550}})


(TODO: list the strings that would go with the short descriptions - liz)
The user profiles will have a link "What do these fields mean?" that leads to [https://wiki.mozilla.org/BMO/User_profile_fields User profile fields] rather than the original idea of descriptions in tooltips for each field.


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.  
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.  
Line 58: Line 65:
'''Last activity'''
'''Last activity'''


The date and time a user last logged in.  
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'''
'''Bugs filed'''
Line 67: Line 74:


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>
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>
'''Comments made'''
The total number of comments that the user has added. More info: <a href="https://bugzilla.mozilla.org/page.cgi?id=etiquette.html">Bugzilla etiquette</a>


'''Confirmed'''
'''Confirmed'''
Line 78: Line 89:
'''Patches submitted'''
'''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> and <a href="https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch">How to Submit a Patch</a>
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'''
'''Patches reviewed'''
Line 85: Line 96:


'''Assigned to'''
'''Assigned to'''
Bugs assigned to a user.


'''Bugs poked'''
'''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'''
'''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'''
'''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'''
'''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.
Administrative actions, such as editing a user, group, product, etc, should also trigger the statistics to be updated.
''note'' This "dirty-only" approach may not be viable, as changing a bug's visibility will changes bug counts for everyone who has interacted with the patch (assuming only public bug data is displayed).
=== Schema ===
'''profiles_statistics'''
* id ''identity''
* user_id ''fk profile.userid''
* name ''varchar30''
* count ''int''
'''profiles_statistics_status'''
* id ''identity''
* user_id ''fk profile.userid''
* status ''varchar64''
* count ''int''


'''FIXED'''


'''Firefox'''
'''profiles_statistics_products'''
* id ''identity''
* user_id ''fk profile.userid''
* product_id ''fk products.id'' (when 0, refers to 'other' products)
* count ''int''


'''Firefox for Android'''


'''FirefoxOS'''
new fields:


'''Thunderbird'''
* profiles.mozillians_id ''varchar30'' (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


'''SeaMonkey'''
=== Data Points ===


=== Prior Code ===
* '''last_activity''' : from ''profiles.last_activity_ts''
* '''bugs_filed''' : simple count from bugs table (public bugs only)
* '''comments''' : simple count from longdescs table (public comments only on public bugs)
* '''commented_on''' : simple count from longdescs table (public comments only on public bugs)
* '''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 + longdescs table (public bugs, comments and attachments only)
* '''by-status activity counters''' : simple count from bugs_activity table (public bugs only)
* '''by-product activity counters''' : simple count from bugs_activity + longdescs table (public bugs, comments and attachments only)


* https://bugs.gnome.org has a describe user page that has similar statistics
[[Category:BMO]]
** Sample: https://bugzilla.gnome.org/page.cgi?id=describeuser.html&login=danielle%40madeley.id.au
* Code hosted here: http://bazaar.launchpad.net/~bgo-maintainers/bugzilla.gnome.org/3.4/files/head:/extensions/describe-user/
* Based on Bugzilla 3.4 and may need significant changes to bring up to date

Latest revision as of 03:12, 13 January 2015

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 (except for the Mozillians username field).

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

How a simple user profile might look


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


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


Activity:

Statuses changed: RESOLVED (20), INVALID (3), FIXED (5), VERIFIED (5)

By Product: 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)

What do these fields mean?

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)

The user profiles will have a link "What do these fields mean?" that leads to User profile fields rather than the original idea of descriptions in tooltips for each field.


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>

Comments made

The total number of comments that the user has added. 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.

Administrative actions, such as editing a user, group, product, etc, should also trigger the statistics to be updated.

note This "dirty-only" approach may not be viable, as changing a bug's visibility will changes bug counts for everyone who has interacted with the patch (assuming only public bug data is displayed).

Schema

profiles_statistics

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


profiles_statistics_status

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


profiles_statistics_products

  • id identity
  • user_id fk profile.userid
  • product_id fk products.id (when 0, refers to 'other' products)
  • count int


new fields:

  • profiles.mozillians_id varchar30 (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 longdescs table (public comments only on public bugs)
  • commented_on : simple count from longdescs table (public comments only on public bugs)
  • 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 + longdescs table (public bugs, comments and attachments only)
  • by-status activity counters : simple count from bugs_activity table (public bugs only)
  • by-product activity counters : simple count from bugs_activity + longdescs table (public bugs, comments and attachments only)
Retrieved from "https://wiki.mozilla.org/index.php?title=BMO/UserProfiles&oldid=1047242"