How to review a video segment

[rrrutledge]

No description provided.

[Ludmila-N]

The new line makes sense to me, but it's not enough to explain what is expected of video reviewer, if that's what you wanted to address with this PR.
Questions that I have if I were to start reviewing other videos are:

1. Do we cross reference corresponding articles while viewing, not for verbatim match but for the content alignment? What's expected if we find a mismatch? A comment on the video, or a PR on the article? I assume the former.
2. What's our baseline for "how the good video should look like"? I read your comments on the intro video, and you refer a few times to the finished Trusted Committer videos - but they are not yet available to the public. Will we not have them available until after everything is done?
3. Assuming we can figure out the access, would you say we want to use Trusted Committer videos as a reference point, for the sake of uniformity?
4. What happens after the comments have been made? Are we discussing what to do with the video (a) inside the git issue? or (b) right there with comments?
5. (Not immediate but important)

• How are we tracking the comments that were addressed (or not) in the new version?
• Screenlight link points to the folder, so we need to decide how we name next versions when/if the next version of the video is posted. We don't want to lose prior versions with comments, and also for comparison, so - do we rename old videos with replacement date, or do we create new videos with post date or _V01 suffix?

[lenucksi]

The new line makes sense to me, but it's not enough to explain what is expected of video reviewer, if that's what you wanted to address with this PR.

I tend to agree here, although it catches quite much of what I've been doing to review.

Questions that I have if I were to start reviewing other videos are:

1. Do we cross reference corresponding articles while viewing, not for verbatim match but for the content alignment?

What do you understand as cross-reference here? Check that article and video match content-wise while checking the video?
If that's the case:

• The articles are a longer, more detailed version of the videos. The order of creation has been outline -(extension)> article -(shortening)> video. Hence the levels of detail. Checking for strong contradictions between video and article would help I guess.
• We will need to check for alignment of the videos with the workbook Check videos against workbook after creation #122.
• I would check for contradictions and mismatches in a second pass.

What's expected if we find a mismatch? A comment on the video, or a PR on the article? I assume the former.

I would do the former, too. We can generally correct audio that's over slides, slides or text.
Once everything is reviewed I'd collect everything that ended up as slide correction and text correction into tickets and PRs and start from there.

2. What's our baseline for "how the good video should look like"? I read your comments on the intro video, and you refer a few times to the finished Trusted Committer videos - but they are not yet available to the public.

They are indeed available for everyone with access to the GDrive and on O'Reilly Safari as part of the Learning Path products.

Will we not have them available until after everything is done?

Take a look at links above.

3. Assuming we can figure out the access, would you say we want to use Trusted Committer videos as a reference point, for the sake of uniformity?

I do like the Introduction videos too from that standpoint. We should probably triangulate between those two regarding the uniformity.

4. What happens after the comments have been made? Are we discussing what to do with the video (a) inside the git issue? or (b) right there with comments?

I remember that slide updates ended up in GitHub tickets from what I got to see, Audio fixes will likely be handled inside Screenlight. What does @rrrutledge say to this once he's back from vacation?

5. (Not immediate but important)

• How are we tracking the comments that were addressed (or not) in the new version?

If there's a "mark resolved" in Screenlight then that, otherwise maybe add a RESOLVED comment or something like that. Google Docs does "mark resolved". GitHub does what GitHub does.

• Screenlight link points to the folder, so we need to decide how we name next versions when/if the next version of the video is posted. We don't want to lose prior versions with comments, and also for comparison, so - do we rename old videos with replacement date, or do we create new videos with post date or _V01 suffix?

From what I remember from e.g. the Product Owner Screenlight old parts were moved into folders and there were some cases of suffixes going on too. Keeping the old/original versions is important too, I agree. I guess it will organically evolve like every versioning outside a versioning system always does.

[lenucksi]

Looks good to me, do we want to add more text with regards to @Ludmila-N's comment?

[Ludmila-N]

@lenucksi - thanks for the details! The workbook comparison is a new consideration to me - I need to review where #122 goes, i.e., find the workbook pieces and match them to the right segments.
I do have access to the Google drive with videos that you pasted here - perfect!

Looks good to me, do we want to add more text with regards to @Ludmila-N's comment?

I think it will be super helpful - somewhere if not in the readme itself. OR add a reference to this issue, so someone else can read your comments here.

Thank you!

[rrrutledge]

Trusted Committer is also available at learning.oreilly.com.

[rrrutledge]

Thanks for the feedback. Added a detailed section on how to review a video in the CONTRIBUTING.md. Take a look and see what you think?

[lenucksi]

LGTM, thanks!

[rrrutledge]

Thanks for this review, Johannes! Will wait to see if Ludmila has comment as well.

[Ludmila-N]

Russ,

I'm cool - there's no approve button since Johannes already approved, so I did not do anything else - sorry if I delayed this PR by not commenting. Please merge!

[rrrutledge]

Great, thanks!

[rrrutledge]

there's no approve button

You should still be able to add your review by clicking Files changes > Review changes > Approve

[Ludmila-N]

Thank you Russ - I believe I have only seen "Submit review" with no radio buttons, and was thinking it's because one reviewer has already approved; next time I will specifically pay attention to this.