Closed
Bug 951503
Opened 11 years ago
Closed 10 years ago
Add inactive field to profiles
Categories
(Mozilla Reps Graveyard :: reps.mozilla.org, task)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: williamr, Assigned: nemo-yiannis)
References
Details
(Whiteboard: [kb=1218994] [qa-])
Attachments
(2 files)
To help the program managers tell at a glance who is inactive with the Reps program, let's add an inactive field on profiles. The value of this field does *not* change how a Rep can use the site. For now the value is simply used to indicate that a Rep is not currently active. There is already an 'active' field for users in the admin panel that we may be able to use. We would need to research if that field's value is currently used in any logic on the site. = User stories = Edit Profile - As a user, I want to mark a checkbox when editing my profile, so I can indicate that I am inactive. - As an admin, I want to mark a checkbox when editing any Rep's profile, so I can indicate that Rep is inactive. View Profile - As a user, I want to see an 'Inactive' label on a Rep's profile, so I can tell that the Rep is currently inactive.
Reporter | ||
Comment 1•11 years ago
|
||
> Edit Profile
> - As a user, I want to mark a checkbox when editing my profile, so I can
> indicate that I am inactive.
Here's a mockup of the checkbox field to appear on the Edit Profile view.
Reporter | ||
Comment 2•11 years ago
|
||
> View Profile
> - As a user, I want to see an 'Inactive' label on a Rep's profile, so I can
> tell that the Rep is currently inactive.
Here's a mockup of how the Inactive label would appear on Profile view. Applying some color (yellow or red, perhaps) would make it easy to tell that a Rep is inactive.
Reporter | ||
Updated•11 years ago
|
Whiteboard: [kb=1218994]
Comment 3•11 years ago
|
||
Hi William, There is also a relevant bug [1]. Although those two bugs are not the same, maybe we could tackle them together with a unified solution. Thoughts? https://bugzilla.mozilla.org/show_bug.cgi?id=743712
Reporter | ||
Comment 4•11 years ago
|
||
Thanks Tasos for pointing out the other bug - I had forgotten about it. I commented there, and we can close this bug as a duplicate if we reach a unified solution in bug 743712.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → jgiannelos
Comment 5•10 years ago
|
||
For this bug, let's build the possibility of inactive profiles, and some automation around inactivity (which will come from bug 967026, which speaks to notification about inactivity). Bug 743712 has some great ideas that would be enhancements to this bug, but this bug can be completed without them, right?
Comment 6•10 years ago
|
||
Just to share a few ideas about this bug: We could have two kinds of inactive field. To be more specific: - A field in user's profile (editable by the user) in which the user could set the period that would be unavailable. This could be accompanied with a short description for the reason of unavailability. Also, the reason could be visible only to the mentor. Shared with other reps could be only the date of unavailability and an emergency contact to another rep. - A (hidden - editable by admin/mentor) field which will automatically disable user's profile after a long period of time, only and only if the user has not defined an unavailability period during that time. For example, if the period for the deactivation is three months, this would happen if the user hasn't any activities for that period and has not declared that would be unavailable. Another reason could be if the mentor manually activates this option (require Council's approval?). - Both suggestions would be supplemented with automated notifications both to the user and mentor.
Assignee | ||
Comment 7•10 years ago
|
||
PR opened here: https://github.com/mozilla/remo/pull/637 Here are some thoughts about that bug in connection with the discussion made here: https://bugzilla.mozilla.org/show_bug.cgi?id=743712 These 2 bugs introduce the concept of user inactivity/availability. I think that even if they seem very similar, each one tackles a different problem. It makes sense to me, to keep the functionality of this bug as is with only a change in the permissions of the inactive field (maybe allow access only to the user's mentor and the admin group?). After that we can implement the user unavailability described in bug 743712 that indicated that user is not available for a period of time but active in general.
Comment 8•10 years ago
|
||
We hacked on a spec for inactivity here: https://remo.etherpad.mozilla.org/inactive-rep-specs-2014-02-18 Comment 0 raises the possibility that reps and mentors could manage the activity flag, but we can't allow that if our goal is to use activity metrics to measure program health. Bug 743712 addresses that request. I suggest we refer to that feature as "unavailability" and tackle it independently of this bug. For this bug, we will build an inactive flag that is set automatically based on activity. Automation will use a 6 week timespan, 3 weeks in the past and 3 weeks in the future. Events attended or organized during that timespan will constitute activity. The inactive flag will be available for things like metrics or UI display, which are or will be addressed in separate bugs.
Comment 9•10 years ago
|
||
:williamr, based on the definition of inactivity in comment 8, and considering that we may one day implement unavailability as described in bug 743712, do you think inactivity is valuable to show publicly on rep profiles? If not publicly, should it be displayed to mentors? In either case we should file a new bug dependent on this one for that display. And mockups!
Flags: needinfo?(williamr)
Reporter | ||
Comment 10•10 years ago
|
||
(In reply to Justin Crawford [:hoosteeno] from comment #9) > :williamr, based on the definition of inactivity in comment 8, and > considering that we may one day implement unavailability as described in bug > 743712, do you think inactivity is valuable to show publicly on rep > profiles? If not publicly, should it be displayed to mentors? In either case > we should file a new bug dependent on this one for that display. And mockups! Yes, I think we should show the inactivity publicly. Users search for Reps for opportunities, and those users will mainly be interested in contacting active Reps. I have filed new bugs dependent on this one and included mockups. Thanks Justin!
Flags: needinfo?(williamr)
Comment 11•10 years ago
|
||
In meeting we discussed and decided: This bug's scope is about "Add the inactive field to profiles". It blocks bug 984571, which is a tracker for the entire feature of flagging and displaying reps who don't have recent activity. That being said, the above discussion is useful and we may wish to reference it from the tracking bug. I'll make a note there.
Blocks: 984571
Reporter | ||
Comment 12•10 years ago
|
||
(In reply to Justin Crawford [:hoosteeno] from comment #11) > This bug's scope is about "Add the inactive field to profiles". It blocks > bug 984571, which is a tracker for the entire feature of flagging and > displaying reps who don't have recent activity. This original idea in this bug evolved into identifying three related issues around activity: 1) how to re-engage with Reps who have not reported activities recently (bug 984571) 2) create a way for Council to review Reps (bug 984627) 3) create the concept of unavailability (bug 987265). The three tracker bugs above do not explicitly require an inactive field, so I'm wondering if this bug for an inactive field is still useful. For example, the display and metrics for Reps with no recent activities over different time periods may not require an inactive field on profiles and might be better handled a differently way, such as using queries on the activities reported. I recommend some additional discussion before we implement this bug.
Comment 13•10 years ago
|
||
> The three tracker bugs above do not explicitly require an inactive field,
This is an implementation decision.
We will be displaying a rep's status vis-a-vis recent activities (they either have some or they don't, so it's a boolean flag) on several pages. We'll display it on mentor dashboards. We'll display it in a statistical rollup.
Computing whether or not a particular rep has any recent activity will likely be more computationally intense than, say, getting and displaying their name. It might be OK to do it once on page load, for example on the rep's own profile. Doing it multiple times on a page -- as on the mentor's page -- or hundreds of times -- as on the stats dashboard -- will probably be too expensive to do in realtime. :nemo, what do you think?
The alternative to doing it in realtime is to do it on a schedule and cache it. We can cache it in a field on the rep's profile (as suggested by this bug) or somewhere else (though we'd probably want a good reason not to store it on the rep's profile).
Reporter | ||
Comment 14•10 years ago
|
||
(In reply to Justin Crawford [:hoosteeno] from comment #13) > This is an implementation decision. Absolutely. I defer to Nemo and the engineers on how to best do that. I just want to clarify the display and measurement of status below. > We will be displaying a rep's status vis-a-vis recent activities (they > either have some or they don't, so it's a boolean flag) on several pages. > We'll display it on mentor dashboards. We'll display it in a statistical > rollup. The colors on the mentor dashboard (bug 984573) and statistical rollup (bug 984588) imply more than just a boolean flag. Both of those places have a way of displaying or measuring if a Rep has reported activities in the last 4 weeks, 4-8 weeks or 8+ weeks. So there are 3 possible states for displaying information in those bugs. It may be that a 'last active' date field is more useful than a boolean, and Justin suggests some great ideas in comment 13. Again, the engineers are the ones to decide on implementation. Happy to clarify or discuss more if it's helpful.
Comment 15•10 years ago
|
||
We earlier built a feature for emailing the mentors of inactive reps (bug 970395) when they have no activity 3 weeks in the past or 3 weeks upcoming. I think an optimal first pass at this will use that earlier logic. If change is needed we'll need to consider that earlier feature as part of the change.
Assignee | ||
Comment 16•10 years ago
|
||
I think that the best way to implement this if we want to show 2 different levels of inactivity (eg. inactive user for 4 weeks and for 8 weeks) is to save the last report date in UserProfile model. Still, in that case, we need to figure out what we are doing with the inactivity notification emails we already have. :williamr Any thoughts?
Flags: needinfo?(williamr)
Reporter | ||
Comment 17•10 years ago
|
||
(In reply to John Giannelos [:nemo] from comment #16) > Still, in that case, we need to figure out what we are doing with the > inactivity notification emails we already have. I chatted separately with with nemo and kinger about this, and we think it is good to be consistent with how we show inactivity on the Portal and also the email notifications we send. Since updating the email notification is pretty easy, let's change the email to send if a mentee has not had activities in the past 4+ weeks. We will no longer consider future activities in the email trigger. Similarly for the display of Reps with no recent activities, we will only look at past activities. We will use the 4 weeks and 8 weeks marks as described in bug 984573 comment 0.
Flags: needinfo?(williamr)
Assignee | ||
Comment 18•10 years ago
|
||
Final inactivity specs: https://remo.etherpad.mozilla.org/inactive-rep-specs-v2-2014-04-03
Updated•10 years ago
|
Version: unspecified → next
Assignee | ||
Comment 19•10 years ago
|
||
Resolved here: https://github.com/johngian/remo/commit/4f6951210e33621cf1c6ad52579c967a6d1c3424
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 22•10 years ago
|
||
Oops wrong bug.
Status: VERIFIED → RESOLVED
Closed: 10 years ago → 10 years ago
Updated•10 years ago
|
Whiteboard: [kb=1218994] → [kb=1218994] [qa-]
Updated•10 years ago
|
Version: next → 430
Updated•4 years ago
|
Product: Mozilla Reps → Mozilla Reps Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•