Closed Bug 951503 Opened 11 years ago Closed 10 years ago

Add inactive field to profiles

Categories

(Mozilla Reps Graveyard :: reps.mozilla.org, task)

task
Not set
normal

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.
> 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.
> 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.
Whiteboard: [kb=1218994]
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
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: nobody → jgiannelos
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?
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.
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.
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.
Blocks: 967026, 970395, 970400
No longer blocks: 743712
No longer depends on: 967026
: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)
Blocks: 975078
Blocks: 975080
Blocks: 975083
(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)
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
(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.
> 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).
(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.
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.
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)
(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)
Version: unspecified → next
Resolved here: https://github.com/johngian/remo/commit/4f6951210e33621cf1c6ad52579c967a6d1c3424
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Verified fixed on stage.
Status: RESOLVED → VERIFIED
Oops wrong bug.
Status: VERIFIED → RESOLVED
Closed: 10 years ago10 years ago
Whiteboard: [kb=1218994] → [kb=1218994] [qa-]
Version: next → 430
Product: Mozilla Reps → Mozilla Reps Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: