Assign journalists to specific sources

[garrettr]

It would be useful to be able to assign a specific source to a given journalist, so that journalist (and the other journalists) know who is handling them.

In the ORM, it's trivial to create a foreign key between Source and Journalist. It's also easy to display the assigned Journalist in the Sources and Source views on the Document Interface.

Since journalists may be assigned, then re-assigned, it might be useful to track and display the history of assignments in the Source view (similar to how GitHub displays assignees to issues, for example).

In the simplest implementation of this feature, any Document Interface user would be able to assign (or re-assign) a journalist to a source. It would be more complicated, but do-able, to base this capability on some kind of permissions system (e.g. only "admins" or "editors" can assign/re-assign sources or journalists). I am not sure if permissions for assignment would be useful, so I am inclined to implement the simplest version of this first, and implement/track permissions in a follow-up issue if that feature is requested.

It's an open question whether it would be useful to let Sources know who is assigned to them. My inclination is to say that this would not be useful, and could potentially be used to target or harm specific journalists, so I would prefer not to implement this unless somebody can make a strong case for doing so.

[psivesely]

It's an open question whether it would be useful to let Sources know who is assigned to them. My inclination is to say that this would not be useful, and could potentially be used to target or harm specific journalists, so I would prefer not to implement this unless somebody can make a strong case for doing so.

This should certainly not be the default. Hesistant to even add it as an optional setting. A journalist can always choose to reveal their identity in a message to the source.

[heartsucker]

A source who frequently checks also might see themselves repeatedly
reassigned which could be off putting or might give the impression of a
lack of organization among the news org. Not to mention if they know this
feature exists and see none, this will know they are unassigned which could
be even worse.

I agree that sources should not know what journalist they are assigned to.
Am 11.07.2016 8:59 nachm. schrieb "Noah Vesely" [email protected]:

It's an open question whether it would be useful to let Sources know who
is assigned to them. My inclination is to say that this would not be
useful, and could potentially be used to target or harm specific
journalists, so I would prefer not to implement this unless somebody can
make a strong case for doing so.

This should certainly not be the default. Hesistant to even add it as an
optional setting. A journalist can always choose to reveal their identity
in a message to the source.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1355 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AD0DAKwJCHWvUK11uwD5NXdPTMjgkYTiks5qUpKfgaJpZM4JFrCZ
.

[psivesely]

This is not the exact perfect place for this thought, but when considering adding more and more {meta,}data that will be stored to the app server, I think we might want to consider how we could leverage a journalist client to deprivilege this information from the app server. A solution might include some multi-party computation scheme where state such as which journalist is assigned to which source can be synced across journalist clients through the app server, without the app server being able to gain knowledge. I'm not suggesting this is how we should first implement this feature--a straightforward implementation might be best at first--just that this may be a way to help preserve the security of our system, while continuing to provide more rich functionality in our application.

[redshiftzero]

This was implemented in #1491

[heartsucker]

Reopening in relation to #2841 and #1355

[heartsucker]

Open questions about how assignment should work:

• Who is authorized to assign sources? Only admins?
• What happens to a source who is unassigned?
• How does this relate to a non-shared inbox? (i.e., on inbox per journalist)
  • What happens to past messages when someone is reassigned?
• Should assignment be 1:1 or 1:N? What does the inbox look like by default?
• What if an org doesn't want source assignment and only one shared inbox? What if an org doesn't want a shared inbox at all? Do we have any use research about this?

[redshiftzero]

I think the implementation in #1491 is a reasonable approach (though see 1:N comment below) considering how people are currently using SecureDrop. For the interested observer, that is a situation where organizations have from 1 to a small team of people in the organization checking submissions, deciding who sources should be handled by, and ferrying documents back and forth to people not onboarded to SecureDrop. This process may require some discussions (these currently do not happen on SecureDrop, although in the model where we have a client program that can pre-encrypt comments and notes, this discussion could eventually occur through SecureDrop, where the notes are stored encrypted on the server). Critically, the journalists that eventually work on the documents may not be onboarded to SecureDrop's journalist interface at all.

Who is authorized to assign sources? Only admins?

Any user can assign/unassign journalists to sources. For example, a journalist onboarded to SecureDrop can self-assign themselves if they or another journalist they have connected with are working on a source's documents (I think the GitHub issue assignment UI is a nice example here, we use it to denote "hey I'm working on this one").

What happens to a source who is unassigned?

Nothing, they stick around until they are deleted.

How does this relate to a non-shared inbox? (i.e., on inbox per journalist)
What happens to past messages when someone is reassigned?

I advocate for us to implement journalist assignment before retiring the not-shared inbox, since the former is a useful but not disruptive feature but the latter requires much more careful consideration (and likely some more user research). Discussion of that can happen over in #1550.

Should assignment be 1:1 or 1:N? What does the inbox look like by default?

Right now it's 1:1, that said, you make a good point - imho I do think it's better - and would be a nice extension - if multiple journalists could be assigned to the same source.

[eloquence]

Judging by the screenshots in #1359, I agree this implementation would already address significant pain points. I would propose some slight modifications:

• as noted above, support 1:N source:journalist relationships
• limit assignment actions to "(un-)assign yourself" to address most common concern established through user research (lack of tracking of which member of the team has looked at a given submission) while keeping UI impact minimal
• display date of the assignment(s), since it's useful for orgs (they often track this information in spreadsheets right now).

Before implementation, I would suggest building an interactive wireframe of the proposed UI, and working with the UX team on some light validation with users who are willing to participate.

If we do implement such a simple workflow improvement, I do see it as decoupled from #2841. If per-daughter-organization inboxes were implemented, each would still potentially be available to multiple users, and each would retain the assignment feature in its organizational context, so I see no conflict in a staged deployment.

[huertanix]

@heartsucker Some answers to your Qs below:

Who is authorized to assign sources? Only admins?

An admin's role in my experience has been less editorial and more IT, so I don't think admins are the folks who would create those assignments. My hunch is that journalists would know each other's assignment desks enough to know how to assign themselves or each other. Without a built-in means of communicating that assignment (my brief glance at #1359 does not include any kind of notification system), there's a risk a journalist might manually let their colleague know of their assignment through a less secure medium (email or Facebook Messenger). That workflow can be addressed as part of the SecureDrop training and documentation, but leaves wiggle room for mistakes.

What happens to a source who is unassigned?

This is a good question; My understanding of this feature's need is more tagging/labeling than access control, so I'd imagine basically nothing beyond the label changing.

How does this relate to a non-shared inbox? (i.e., on inbox per journalist)

Echoing my previous thoughts, I figure this wouldn't need to separate inboxes to meet the need of organizing/labeling drops.

What happens to past messages when someone is reassigned?

I figure nothing beyond the changing of the label.

Should assignment be 1:1 or 1:N? What does the inbox look like by default?

It's definitely possible to see multiple people assigned to one source in larger newsrooms, I tend to lean towards 1:N.

What if an org doesn't want source assignment and only one shared inbox? What if an org doesn't want a shared inbox at all? Do we have any use research about this?

The feedback I've heard during training has generally been less of a concern about who can see what or getting scooped so much as having to remember which source a journalist was talking to. There's been more formal user research around this recently; some of the researchers may have good feedback on the needs surfaced in their discussions.

[eloquence]

there's a risk a journalist might manually let their colleague know of their assignment through a less secure medium

That might be another reason to stick to self-assignment, at least initially.

[heartsucker]

I have a branch pushed with a draft of this. Can I get a UI/UX check before I write all the tests and polish this?

[eloquence]

@heartsucker @freedomofpress/securedrop-ux

What happens if, in the first screenshot, I click on "dellsberg" or "unassigned" -- does it take me to the assignment screen?

What happens in the per-source view if the source is not assigned yet?

A few observations, looking forward to input from UX team members:

• We have an existing problem in the UI where it's not always clear if something is an indicator or a button. We should be careful to not add to that confusion.
• There is a cognitive clash in the second screenshot between "dellsberg" and "(unassigned)" -- because the dropdown stands out, it would be easy to misinterpret the status as being unassigned.
• We should avoid adding a lot of verbiage if only a subset of users are expected to use this feature, so we may want to opt for a more compact view until/unless an assignment has been made.
• I would suggest quoting the codename ("progressive shindig") and perhaps the username in the output message, because dictionary words can lead to otherwise confusing results.

As we get more systematic about UX research, I do think we should attempt to get some evidence from users that this would help them to manage submissions before merging an iteration of this feature. Nonetheless, glad to see progress on this front!

[heartsucker]

What happens if, in the first screenshot, I click on "dellsberg" or "unassigned" -- does it take me to the assignment screen?

Nothing happens. Since the docs/messages buttons don't do anything, neither does this.

What happens in the per-source view if the source is not assigned yet?

Text says "this source is unassigned."

There is a cognitive clash in the second screenshot between "dellsberg" and "(unassigned)" -- because the dropdown stands out, it would be easy to misinterpret the status as being unassigned.

Yeah, I was going to clean that up later. Getting it to correctly display the already-assigned journalist was annoying, so I left it for prototyping.

We should avoid adding a lot of verbiage if only a subset of users are expected to use this feature, so we may want to opt for a more compact view until/unless an assignment has been made.

Fair. I can tighten it down and post a new screenshot.

I would suggest quoting the codename ("progressive shindig") and perhaps the username in the output message, because dictionary words can lead to otherwise confusing results.

Right.

[heartsucker]

Minor update.

[eloquence]

Much cleaner already, thanks; look forward to any follow-up screenshots. I still think this is pretty heavy on the source view and suspect it would be less cluttered if we can somehow come up with a nice progressive disclosure pattern that works without JS. Will also ask Nina to weigh in.

[ninavizz]

Off the bat, it seems like Notifications would be a highly desirable (if not a dependent) parallel functionality... but otherwise, this sounds like a great idea!

[ninavizz]

@heartsucker I'd be happy to work with ya on how this might fit into the rest of the UI. It seems like it'd be nice to see in the list of all Sources, who's been assigned to whom. Without notifications, that also seems like it'd be the only way for this functionality to really deliver value wrt influencing behavior.

Delighted to see this in development, on an aside. :)

[heartsucker]

@ninavizz here for the list of all source: #1355 (comment)

I think we shouldn't do notifications for this since for a first pass. I think it's enough to have the basic overview on the homepage.

[ninavizz]

@heartsucker Agreed re: Notifications. That's how I'd split-up the feature for Beta on the Journalist Workstation, actually. Notifications are their own problem to nicely solve for.

I've conferred with Erik, and tomorrow afternoon we'll run some quick wireframes I'll do today, by a user for feedback. Will post those here for team feedback, this afternoon PST. w00t! Thank you for reminding me in today's standup call!

[ninavizz]

Hasty prototype. Click anywhere on the screen to see hot-spots. Invision sucks at hover states, so you have to click to view the hover in the dropdown. There's also a little grid in the lower-right, and if you click on that it shows all screens. https://invis.io/NSOD4U8TCQB#/323206873_All_Sources

Thoughts, feedback?

[eloquence]

Thanks for the quick sketch!

If I understand correctly, you're intentionally omitting the information about assignments in the list view. Personally, I'm not sure that's a good idea -- while I worry about cluttering the list view as well, the fact that something has already been assigned is important information because it could enable some triage of incoming submissions (either via self-assignment or through a person on staff managing the assignments).

[ninavizz]

Thank you, Erik! No, that was not intentional—my bad! I'll go ahead and update that at some point today...

[heartsucker]

Yeah, agree that it's kinda important to have on there if for no other reason than to be able to say "Steve is on vacation; I better respond to his sources."

[heartsucker]

But yeah, I can get at this tomorrow. Today is a holiday in Germany (and yet here I am on Github).

[ninavizz]

Did some testing with @eloquence today and had one user look at this feature. Have yet to sync with him on any thoughts following our testing, but to close the loop on this concept at least, I'll do the outstanding mockup on this tomorrow PM PST. Go enjoy the DE holiday! :)

[eloquence]

We'll consider this in the context of feature work on the SecureDrop Workstation, keeping open for now.