Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Review" recording status should show as DNR in public schedule #1727

Open
crablab opened this issue Jun 4, 2024 · 8 comments
Open

"Review" recording status should show as DNR in public schedule #1727

crablab opened this issue Jun 4, 2024 · 8 comments

Comments

@crablab
Copy link
Contributor

crablab commented Jun 4, 2024

Review talks should show as "not recorded" in the public interface. There is no certainty these will ever be published.

Screenshot 2024-06-04 at 10 55 10
Screenshot 2024-06-04 at 10 55 41

@marksteward
Copy link
Member

The icon is "won't be recorded", and the assumption is they'll be reviewed and approved.

@crablab
Copy link
Contributor Author

crablab commented Jun 4, 2024

Understood 🙂

Some of them may well be, but the speaker could decide not to agree to release.

For future events, I think we should fall back to displaying these as 'not recorded' as there is a significant chance they will not be released, and people make decisions on what to see based on the advertised status.

We tell speakers they have the absolute right to decline publication.

To use a tangential example, it's rare that a talk advertised as being recorded isn't published, but we already have one example of that this year.

@wlcx
Copy link
Member

wlcx commented Jun 6, 2024

I think probably streamed and recorded should be stored separately and independently - we had every combination of the two this event, but that's a tangental issue

The question is, what's the most useful thing to show on the schedule? I'm leaning towards:

  • This talk will/will not be livestreamed
  • This talk will/may/will not be available as a recording (with "may" being the case with review talks)

Perhaps this is too complicated, but I can't off the top of my head think of a simpler way to show it that doesn't mislead people - as it is currently:

  • People may have been confused by the lack of livestream for talks that were "review" as this was not visible on the schedule
  • People may have assumed that streamed == recorded, but we had one talk for which this wasn't the case

@crablab
Copy link
Contributor Author

crablab commented Jun 6, 2024

To some extent I think we do want to limit options, both for our own sanity but also to encourage recording & streaming wherever possible (it's an important part of the implicit 'contract' with volunteers).

This is mostly an expectation management problem I think, not a technical one.

People may have assumed that streamed == recorded, but we had one talk for which this wasn't the case

IMO this is an exception rather than a rule. In the case you're referring to the recording will never be published, but it wasn't intended to be that way and it's not something we'd routinely offer speakers.

People may have been confused by the lack of livestream for talks that were "review" as this was not visible on the schedule

Agreed. And it's important we correctly show talks that may not be released as recordings.

I would err towards showing anything that isn't public as "not recorded", then anything better than that is positive.

I think probably streamed and recorded should be stored separately and independently

Don't disagree. I'm not sure if we necessarily want to publicise that raw though - potential for information overload in the UI and there is a certain amount of speaker sensitivity. Some speakers want to review the recording and decide whether to publish - that's a recorded and not streamed talk, but we shouldn't be advertising it as such.

@wlcx
Copy link
Member

wlcx commented Jun 6, 2024

IMO this is an exception rather than a rule. In the case you're referring to the recording will never be published, but it wasn't intended to be that way and it's not something we'd routinely offer speakers.

Yeah, fair enough

I would err towards showing anything that isn't public as "not recorded", then anything better than that is positive.

yep- though this could result in confusion/paniced "should this have been released" feedback...

I'm not sure if we necessarily want to publicise that raw though - potential for information overload in the UI

Mm, agreed on the sensitivity of the review setting. though we'd need to make that decision for the .json - currently review is exposed there.

@lukegb
Copy link
Contributor

lukegb commented Jun 6, 2024

Bear in mind that we have had eager attendees interpret "will not be recorded" as "no photos will be taken during this talk", and confront people with event photography passes (not about their own images, which is obviously fine, but trying to be helpful about the talk as a whole).

We need to think carefully about the messaging of not-recorded talks to avoid exacerbating this if we're actually staffing people to point video cameras.

@wlcx
Copy link
Member

wlcx commented Jun 6, 2024

I wonder if we should switch to the implicit default being "no recording" and show an icon in the positive case for "this event will be recorded"?

This potentially solves two things:

  • It means that all the other scheduled stuff that doesn't have a "no record" icon on it but isn't in fact being recorded (e.g. workshops, performances etc) isn't confusing on the schedule
  • It allows for more ambiguity with talks set as "review" - we don't say that there won't be a recording (and then release one), we just say (implicityly) that there won't definitely be one

@crablab
Copy link
Contributor Author

crablab commented Jun 7, 2024

I wonder if we should switch to the implicit default being "no recording" and show an icon in the positive case for "this event will be recorded"?

This seems like a good option.

It also helps solve #1726

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants